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 117834

Summary:	I18N - fixes related to 116767 and 100178 not all working
Product:	obsolete	Reporter:	Ken Frank <kfrank>
Component:	visualweb	Assignee:	_ sandipchitale <sandipchitale>
Status:	VERIFIED FIXED
Severity:	blocker	CC:	kaa, quynguyen
Priority:	P2	Keywords:	I18N
Version:	6.x
Hardware:	Sun
OS:	All
Issue Type:	DEFECT	Exception Reporter:

Description Ken Frank 2007-10-04 19:17:57 UTC

have discussed this with Quy; he is aware of the problems - here is 
from our mail:

Ken Frank wrote:
> I'm not sure that 100178 is fixed then.  some observations:
> 
> 1. when i change the encoding inthe xml header and there is non ascii in 
> the file,
> I do get a warning sometimes, but then when adding a new component, and 
> then going
> back to the jsp file, the UTF-8 is back - even before i save it - is the 
> file being
> rewritten by some other mechanism on adding of a component ?
> 
> (or if project is in euc-jp encoding for example, and change the xml 
> encoding
> value, and add new component - same scenarios - the page1.jsp is rewritten
> to use the euc-jp encoding.)
> 
> thus even though there is the warning,  the encoding value is rewritten next
> time component is dropped, even without saving.
> 
> ---> could this be what 116767 is doing ?

 1a. also, if use non existing encoding value, it still allows change; 
> maybe this is ok
> since we need to assume user knows what they are doing but i think
> jsp/html and/or xml files do check for this; not sure - see #3 below.
> 
> 
> 
> 2. also, when changing the encoding values for content type and page 
> encoding
> in the jsp part, there is no warnings. should there be ?



I think this had to do with my original inability to verify my changes, since there is 
something in visual web that rewrites the JSP encoding every time there is a designer 
change.  This can probably be filed as a separate issue.

Comment 1 Ken Frank 2007-10-04 19:19:29 UTC

other comments perhaps related, perhaps not to this issue, see also
106473.

 3. for regular jsp,  and xml files there are warnings although the 
> behavior is
> different for jsp/html vs xml unfortunately - see 106473 for discussion 
> about this.

Comment 2 _ sandipchitale 2007-10-08 18:04:23 UTC

I am able to reproduce it. Investigating. The issue may be that said encoding is not recognized by Insync (MarkupUnit).

Comment 3 Ken Frank 2007-10-08 18:29:06 UTC

see also 115278 and 117778 - both related to feq and encodings; dont know if related to this one.

ken.frank@sun.com

Comment 4 _ sandipchitale 2007-10-08 23:04:20 UTC

Sent insync jar with possible fix to Ken for testing.

Comment 5 Ken Frank 2007-10-08 23:41:09 UTC

Sandip,

can test it but need some answers to below first:

1. need specific user scenarios

2. does it matter if nb build used is like 1003 or does it need to be later ?

3. what about 115278, which was fixed today; does this one relate at all to that one; if so
then we can wait til build with that one.

Thanks - Ken

ken.frank@sun.com

Comment 6 _ sandipchitale 2007-10-09 00:05:06 UTC

Ken,

Actually I was following the same user scenario as described in the bug i.e. change the encoding of the project and then
the page and make sure it sticks around. I thought you may know other scenarios. That is why I sent the jar to you. In
any case I will also talk to Quy what scenarios he was using.

Using a build from 1008 may be better.

I think the fix for 115278 is unrelated to this issue. But you may want to try with that fix also. I have updated my
workspace and built a jar which I will send you.

Sandip

Comment 7 _ sandipchitale 2007-10-09 17:53:30 UTC

Use the encoding returned by FileEncodingQuery instead of manageing it in Insync.

Checking in src/org/netbeans/modules/visualweb/insync/faces/FacesPageUnit.java;
/cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/FacesPageUnit.java,v  <--  FacesPageUnit.java
new revision: 1.14; previous revision: 1.13
done
Checking in src/org/netbeans/modules/visualweb/insync/markup/MarkupUnit.java;
/cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/markup/MarkupUnit.java,v  <--  MarkupUnit.java
new revision: 1.8; previous revision: 1.7
done

Comment 8 Ken Frank 2007-10-16 18:52:20 UTC

the verification is only about the following:

a. case 1
1. create visuaweb project and the Page1.jsp encoding values are the same as the project encoding
2. add a component to design area
3. go back to jsp file, the encoding values should be the same as project encoding

4. use a different encoding than utf-8 or encoding of the locale user is in to test this

b. case 2 

1. change the project encoding to something else
2. the encoding values in the jsp file should stay the same, even after adding more components.

c. case 3 

1. change the encoding values of the jsp file to something different than project encoding
and not utf-8
2. the encoding values in the jsp file should stay the same, even after adding more components
NOTE - the changed encoding value was a legal one, so did not run into the parts of 100178.

---> in a brief test, all of above cases passed, so am verifying this issue.

ken.frank@sun.com

Comment 9 kaa 2007-11-29 15:34:55 UTC

re-verified, build 1123