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.
this issue has come and gone over many months, as the project encoding handling has changed it has appeared fixed and then it has returned. Now it has returned again. 1. solaris, ja locale, pseudo localized nb 2. project encoding euc-jp 3. create new bpel project, multibyte in name and path to it 4. new bpel process - mbyte in its name 5. mbyte does not show ok in the xml or design area and other places like the navigator but does show ok in project explorer. see attached gifs. 6. if project encoding is utf-8, and all above in 1-4 happen, things show ok. 7. if the mbyte does not show ok it also means that project wont run ok since its encoding situation. 8. now bpel files are seeded with encoding of the project, and this is true for bpel process; but perhaps something is still assuming utf-8 when reading/writing the bpel file ? this is a regression from past behavior. ken.frank@sun.com
Created attachment 52485 [details] image
Created attachment 52486 [details] image
Vladimir, please look at this.
even though we are at HR now, I do believe this needs to be fixed, esp since a regression; let me know if it needs to be put at p1, as per HR process rules. ken.frank@sun.com
Ken, if it's regression then raise the priority and please add "REGRESSION" word to the summary field.
as per Sergey mail, raising to p1 and adding regression keyword. happens on windows also when the project encoding is win31j; note that windows does not have a utf-8 locale so there could be more users who need to use this project encoding on windows, besides similar bad multibyte in attached gifs, is an error notation in display window see attached new gifs. finally, since there has been various late changes in some encoding things in soa/bpel/xslt areas recently, can other code that does encoding handling in those areas be checked in context of the code for this case ? ken.frank@sun.com
there was what seemed to be important fix to encoding handling related to feq today (I don't think it impacts this) but suggest to use a 11/6 build in working on this one.
Created attachment 52566 [details] image
Created attachment 52567 [details] imae
Created attachment 52568 [details] image
ignore attachment bpelprops.gif - its not related at all to this issue.
Vitaly is working on it...
Fixed in sierra_jcaps: /cvs/enterprise/bpel/core/src/org/netbeans/modules/bpel/core/wizard/NewBpelFileIterator.java,v <-- NewBpelFileIterator.java new revision: 1.5.6.7.2.1; previous revision: 1.5.6.7
Fixed in trunk: /cvs/enterprise/bpel/core/src/org/netbeans/modules/bpel/core/wizard/NewBpelFileIterator.java,v <-- NewBpelFileIterator.java new revision: 1.13; previous revision: 1.12
http://enterprise.netbeans.org/source/browse/enterprise/bpel/core/src/org/netbeans/modules/bpel/core/wizard/NewBpelFileIterator.java?r1=1.12&r2=1.13 diff: import org.netbeans.api.project.SourceGroup; import org.netbeans.modules.bpel.project.BpelproProject; import org.openide.ErrorManager; -import org.netbeans.api.queries.FileEncodingQuery; +import org.openide.cookies.SaveCookie; +import javax.swing.text.BadLocationException; +import org.openide.cookies.EditorCookie; +import org.netbeans.modules.xml.api.EncodingUtil; +import javax.swing.text.Document; import org.netbeans.modules.soa.ui.SoaUiUtil; /** @@ -193,12 +197,12 @@ public final void addChangeListener(ChangeListener l) {} public final void removeChangeListener(ChangeListener l) {} - private DataObject createBpelFile(String bpelFileName, FileObject srcFolder, + private DataObject createBpelFile(String bpelFileName, FileObject srcFolder, String namespace) throws IOException { DataFolder df = DataFolder.findFolder( srcFolder ); FileObject template = Templates.getTemplate( wiz ); - + boolean importSchemas=false; DataObject dTemplate = DataObject.find( template ); @@ -235,10 +239,9 @@ } finally { reader.close(); } - + Writer writer = new BufferedWriter(new OutputStreamWriter( - fileObject.getOutputStream(), - FileEncodingQuery.getDefaultEncoding())); //NOI18N + fileObject.getOutputStream(), "UTF-8")); //NOI18N try { writer.write(buffer.toString()); } finally {
Review: the patch looks like ok.
Ken, Please verify this issue with trunk and put comments here.(HR mode requires these steps see http://wiki.netbeans.org/wiki/view/NB6HighResistance).
Lativ, We will do this; please let us know specific location/path of the specific trunk build to use on smetiste.czech; since there are now fcs (release60) builds happening, and locations might have changed, we want to make sure we use a specific trunk build that has this fix. Thanks. ken.frank@sun.com
the (Build 200711080000) contains fix.
I dont see a bld with that id on smetiste in daily builds - I need a specific and definite path on smetiste to an installer build with that fix in it. ken.frank@sun.com
http://smetiste.czech.sun.com/builds/netbeans/6.0/daily/2007-11-08_01-16-45/
I tried the build on Solaris 10, ja locale and x-eucJP-Open for the project encoding. Source code of bpel process has bad mbyte. Also Design view is unable to show diagram. Problem does not exist with UTF-8 project encoding.
I've just tried with your parameters on Solaris 10 developer edition, and all works for me. Did you try with the new userdir ? Could you attach screenshots and build number from netbeans -> help -> about
build: RC1 200711080000. I downloaded it using the url from above. I tried with a new userdir.
Created attachment 52748 [details] source view
Created attachment 52749 [details] design view
Strange but design view is now able to show diagram. Ja chars were not shown properly.
I confirm Andrey's observations. to developers, if you have not changed project encoding to other than utf-8 like euc-jp for solaris or win31j for windows, default, and then done new project and new bpel, then its not emulating this case. ken.frank@sun.com
Now looks ok with NetBeans 6.0 Build 200711090000, ja_JP: Solaris 10, utf8/x-eucjp: BPEL process was created ok. Source and Design tabs are ok. Windows XP, utf8/win-31j: BPEL process was created ok. Source and Design tabs are ok.
Fixed
it does not look ok using 11091200 daily rc1 build on solaris. NetBeans IDE 6.0 RC1 (Build 200711091200) is what about box says and from http://smetiste.czech.sun.com/builds/netbeans/6.0/daily/2007-11-09_13-16-45/ to dev, can you provide specific url of specific build/installer on smetiste so can make sure was using correct one; or is this fix only in the trunk now, as part of the p1 process ? if so that could explain discrepancy. I know that when Andrey runs on solaris, he is in solaris ja locale, and he uses both utf-8 and euc-jp project encodings and those are the same steps I followed, so that is why thinking it might be situation of which build it is in. Will put back to unresolved until can find out more info.
developers - are you running in ja locale completely on solaris and using euc-jp project encoding when you are verifying the fix ? (not starting netbeans with --locale option ?) ken.frank@sun.com
Ken, I think Andrey verified it on correct environment. The only question maybe that Vitaly didn't integrated the fix into RC1 branch.
am putting back to resolved state since it was verified using from Sergey's comments, in trunk and not release60 branch. if fix however is in rc1 branch and in the build I mentioned, please reopen it. if fix not integrated yet into rc1 branch, please let me know specific url of rc1 build that the integrated fix is in so I can try it over the weekend. ken.frank@sun.com
please let us know when its been put back to release60 branch and specific url of installer/build on smetiste or bit.netbeans (not deadlock) that has the fix. We will then do final verif since its already been verified in trunk build. ken.frank@sun.com
Fixed in release60: /cvs/enterprise/bpel/core/src/org/netbeans/modules/bpel/core/wizard/NewBpelFileIterator.java,v <-- NewBpelFileIterator.java new revision: 1.12.2.1; previous revision: 1.12
please provide specific url for the rc1 build that has this fix. there is a lot of changing of build locations now and we need to verify this issue but need to have the definite correct url for the build that has it (release60/rc1 branch) Note that location of rc1 builds have changed based on recent mail bits.netbeans.org/download/6.0/nightly/latest_rc1 but the locations seem to be changing often so suggest tracking latest mail from BE to see where the build is that has this fix in it. ken.frank@sun.com
The http://smetiste.czech.sun.com/builds/netbeans/6.0/daily/2007-11-12_13-16-45/ contains fix.
verified: build 1112 RC1 http://smetiste.czech.sun.com/builds/netbeans/6.0/daily/2007-11-12_13-16-45/