This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 70779 - I18N - web samples setup only for en encoding/charset
Summary: I18N - web samples setup only for en encoding/charset
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 5.x
Hardware: Sun All
: P2 blocker (vote)
Assignee: Marek Fukala
URL: http://issues.apache.org/bugzilla/sho...
Keywords: I18N, RELNOTE, TOMCAT
Depends on:
Blocks:
 
Reported: 2005-12-23 21:40 UTC by Ken Frank
Modified: 2006-08-31 12:44 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2005-12-23 21:40:53 UTC
I know that samples are not localized, but can they be setup so that
they can be more easily run by user in other locales ? 
(its not just users of localized bits who run in other locales)

the jstl example does not have charset or encoding tag in the jsps,
so according to spec, it means iso-8859-1.
User would need to add these to each of the many jsp files, and cant even
do it via properties since the encoding prop is readonly.

So it means if they add mbyte, and try to save the file, they get a popup
saying that character will not be saved correctly since using iso-8859-1,
and when run of course the character does not show ok, even if change
browser encoding.

But if you create a web application, the index.jsp is seeded with the 
pageEncoding value of UTF-8 so couldn't the samples do at least that ?

I realize users might need to set encoding/charset themself in some
real apps, but since these are samples, if jsp pages seeded with UTF-8
as encoding and assuming user uses chars of the locale they are running
in, won't the sample still then work ?

The other 2 samples might need this also. and also the charset/encoding for the
index.html of jstl.
Comment 1 Radko Najman 2006-01-02 17:00:59 UTC
If I understand you mean to add <%@page pageEncoding="UTF-8"%> to each jsp file.
There is more than 100 jsp files in web examples and we are in high resistance
period now. I think this issue is not so critical to fix it in 5.0 so I propose
to decrease the priority to P3 and fix it in 5.1 release. Do you agree? The user
can easily add <%@page pageEncoding="UTF-8"%> to the edited file so I think this
issue is not a big limitation.
Comment 2 Ken Frank 2006-01-02 20:32:12 UTC
I'd agree if it can be noted clearly in release notes that the user might
need to add this line to the sample apps. Can this be done ?

And if so, can you waive it instead of changing to p3, as I do think
p2 is valid and will let it be viewed that way for next release.

ken.frank@sun.com

Comment 3 Patrick Keegan 2006-01-03 17:19:04 UTC
Adding Talley to cc, since he owns release notes.

Devil's advocate: does this really need to be release noted? The issue certainly
existed in 4.1 and nobody reported it. 

I agree that bugs in samples are high priority because the samples are
potentially the first thing a user encounters.
Comment 4 Radko Najman 2006-01-05 16:51:32 UTC
Waiver approved.
Comment 5 Tomasz Slota 2006-04-26 09:45:08 UTC
encoding should be read from the web.xml descriptor, but it is not.. reassigning
the issue to Marek upon his request
Comment 6 Marek Fukala 2006-05-03 15:15:22 UTC
fixed - I have added the encoding specification in deployment descriptor for the
sample projects.

Checking in jsp/web/WEB-INF/web.xml;
/cvs/web/examples/jsp/web/WEB-INF/web.xml,v  <--  web.xml
new revision: 1.1.62.1.2.1; previous revision: 1.1.62.1
done
Checking in jstl/web/WEB-INF/web.xml;
/cvs/web/examples/jstl/web/WEB-INF/web.xml,v  <--  web.xml
new revision: 1.1.62.1.2.1; previous revision: 1.1.62.1
done
Checking in servlets/web/WEB-INF/web.xml;
/cvs/web/examples/servlets/web/WEB-INF/web.xml,v  <--  web.xml
new revision: 1.1.62.1.2.1; previous revision: 1.1.62.1
done
Comment 7 Dan Kolar 2006-08-31 12:44:58 UTC
v.