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.
Summary: | I18N - encoding of file->new->soa xml files to use feq and be seeded with project encoding. | ||
---|---|---|---|
Product: | soa | Reporter: | Ken Frank <kfrank> |
Component: | BPEL Project | Assignee: | Vladimir Yaroslavskiy <yaroslavskiy> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | kaa, lativ |
Priority: | P2 | Keywords: | I18N |
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
wsdl_from_db
utf image where mbyte is ok where bpel mbyte is not ok in euc proj enc square boxes square boxes (correct MIME type) |
Description
Ken Frank
2007-09-14 01:09:54 UTC
please let us know if this will be done soon; this will require retesting due to this change compared to how it is now. ken.frank@sun.com This is an umbrella issue for modules in new->file->soa. we will fix this for fcs. sergey, can you start with bpel and xslt and move the ticket to venkats for sql Vladimir, please look at this. Done for BPEL in trunk and sierra: 1. org\netbeans\modules\bpel\core\resources\templates\EmptyBPEL.template: removed /encoding="UTF-8"/ from first line. 2. org\netbeans\modules\bpel\core\wizard\NewBpelFileIterator.java: added in method instantiate: ... encoding = EncodingUtil.getProjectEncoding(df.getPrimaryFile()); if(!EncodingUtil.isValidEncoding(encoding)) { encoding = "UTF-8"; //NOI18N } EditCookie edit = dobj.getCookie(EditCookie.class); if (edit != null) { EditorCookie editorCookie = dobj.getCookie(EditorCookie.class); Document doc = (Document)editorCookie.openDocument(); fixEncoding(doc, encoding); SaveCookie save = dobj.getCookie(SaveCookie.class); if (save != null) { save.save(); } } Vitaly, please do changes for XSLT and after that please reassign issue for sql. For SQL team: SQL File and WSDL from Database Done for xslt, fixed in trunk: /cvs/enterprise/xslt/tmap/src/org/netbeans/modules/xslt/tmap/resources/TMapTemplate.xml,v <-- TMapTemplate.xml new revision: 1.5; previous revision: 1.4 /cvs/enterprise/xslt/tmap/src/org/netbeans/modules/xslt/tmap/util/Util.java,v <-- Util.java new revision: 1.5; previous revision: 1.4 /cvs/enterprise/xslt/tmap/nbproject/project.xml,v <-- project.xml new revision: 1.8; previous revision: 1.7 /cvs/enterprise/xslt/project/src/org/netbeans/modules/xslt/project/wizard/element/Iterator.java,v <-- Iterator.java new revision: 1.27; previous revision: 1.26 /cvs/enterprise/xslt/project/src/org/netbeans/modules/xslt/project/XsltproProjectGenerator.java,v <-- XsltproProjectGenerator.java new revision: 1.17; previous revision: 1.16 /cvs/enterprise/xslt/project/src/org/netbeans/modules/xslt/project/wizard/NewXsltproProjectWizardIterator.java,v <-- NewXsltproProjectWizardIterator.java new revision: 1.5; previous revision: 1.4 /cvs/enterprise/xslt/project/src/org/netbeans/modules/xslt/project/resources/empty_xslt_service.xsl,v <-- empty_xslt_service.xsl new revision: 1.3; previous revision: 1.2 vchellasamy please do changes for SQL File and WSDL from Database. Pls look into this. I am not clear of this issue to proceed with ? Can you please give more clarification to proceed further. I tried to verify parts of this issue (build 1016 XP.ja_JP, project encodings: UTF-8 and Win31j) with Bpel Module. Results: xml, xsl, xsd, wsdl files have thier encodings the same as the project encoding. Couldn't check: 1. Using win31j encoding: Couldn't create BPEL process, source is empty (exactly 111955, see its description: it was seen time to time ). 2. wsdl from db has square boxes (see image, but there was an exception 118769) Also was created table_code.xsd file with UTF-8 in it. Created attachment 51256 [details]
wsdl_from_db
3. encoding property was not implemented in 1016. item 3 from above is about sql files Andrey, thanks for confirming about the fixed parts; we will verify others after that part is done 2 questions: in the image, what kind of item does the thing with square boxes represent ? is it some item added to the wsdl from a pallette ? I think that is something separate from this issue; please file a separate issue. (and I think its separate from 118769 ) and if 111955 is still seen, even please reopen it since last comment in issue says its ok now. ken.frank@sun.com Completed for SQL File and WSDL from Database for the sql file, since it does not have encoding tag like the xml based files, do you know how it could be checked to see that its using encoding of the project, and not that of just utf-8 ? ken.frank@sun.com I don't see encoding tag at all in bpel and xslt files so am reopening this. and that might be why the multibyte in bpel file is not ok if project encoding is not utf-8. this looks like an issue from a long time ago when there were encoding problems, before this issue of seeding with encoding was done. and when manually add the encoding to bpel file of euc-jp, for ja solaris locale, then save and close - it wipes out most of the file and when reopen most of the file is not there. since the xslt template file does not have encoding value either, am assuming there would be problems with it too - please use other locale and project encodings to emulate this. attached are 2 gifs showing how the mbyte in project/file name looks when project in utf-8 project encoding and euc-jp encoding (in both cases user is in ja locale ) Created attachment 51962 [details]
utf image where mbyte is ok
Created attachment 51963 [details]
where bpel mbyte is not ok in euc proj enc
Ken, Could you please provide *detailed* steps to reproduce? As for me, I can't understand what is wrong and how to reproduce it. From my point of view, I've fixed the BPEL part of issue: when user creates bpel process in bpel modules, encoding in bpel file must be taken from project. Now I can see: create bpel module, change encoding from default utf-8 to e.g. x-euc-jp-linux, create bpel process, open it in source view, see that the file has encoding="x-euc-jp-linux". Ok. What doesn't work? Please also provide the name of operating system to reproduce. Setting INCOMPLETE... answers 1. assumption is that new wsdl and new xslt need to have encoding tag seeded in it - that was what was supposed to happen with this issue. 2. but open the templates for these files - there is no indication of encoding tag that would be put into real file based on users project encoding prop. 3. create real wsdl and xslt there is no encoding tag that is why this was reopened. ken.frank@sun.com Vladimir, this issue was done in parts it seems so that the bpel part was not the only part done; it was handed to others to do those parts and its some other parts that dont have the encoding value in their xml files of that file type, as I mentioned in prev comment below. ken.frank@sun.com Ken I've added for bpel and xslt files notification in case if there is problem with setting encoding. Could you try the last build and in case any error notifications place it here. lativ, for comments Ken I've added for bpel and xslt files notification in case if there is problem with setting encoding. Could you try the last build and in case any error notifications place it here. --> for the xslt, there is no encoding tag in new xslt or in its template; and its true for wsdl and thats why this issue was reopened. is the notiifcation you mention related that ? or is it about user changing encoding tag to one that might not be valid ? ken.frank@sun.com Ken, Did you use XSLT or Bpel project for new XSLT service ? There is an error - XSLT service should be available just in context of XSLT project. Could you please provide detailed steps to reproduce. (i.e. What kind of project, what build e.c. did you use.) Ken could you give a tip where one can get the latest multylanguage build ? Set INCOMPLETE and waiting link to the latest multilanguage build. Vladimir and Lativ, The actual ml build is in progress; we use pseudo localized build which I can send you. But since this is just about seeding of new wsdl and xslt files, that is not related to ml build; that can affect any user in any locale. you can try it yourself on nb, even in en locale - just change the project encoding prop to something else than utf-8 -then create a new project and then create a new file and you can see that encoding is not seeded with the encoding you chose. but create a new jsp file or html file, and you will see that it is seeded with the encoding value you chose. ken.frank@sun.com or is there something in some bundle file of pseudo translated that Hi Ken, is the issue reproducible when you create XSLTservice from XSLT project ? Not from BPEL project, not from any other project. Hi Ken, is the issue reproducible when you create XSLTservice from XSLT project ? Not from BPEL project, not from any other project. I realized that I must have been doing the other xslt, since I don't know how to create the xslt service (person who normally tests it out of town) But as per my other comments, its easy for those on your team to test; it does not need pseudo localized. and if I look in the templates->soa section, I don't see encoding notation in any of those template files in any case. QUESTION - isnt having the files created with encoding tag part of this issue ? Maybe I am mistaken here. ALSO, if that is part of this, its very late in cycle for this and am concerned about any possible instability, but also want to make sure that soa things are compatible with other parts of product as to feq and encoding. Thanks - Ken Hi Ken, I took the latest NetBeans autobuild (>= #4245), created BPEL module, changed encoding from UTF-8 to EUC-JP, created BPEL process: the encoding of the process is "EUC-JP". The same with XSLT module: changed encoding to EUC-JP, created XSLT service, the encoding of the service is "EUC-JP". Please, do the same with the *latest* NetBeans build (>= *2007-11-02*) and verify that the behaviour is ok. Ken, one more comment. If it doesn't work for you please provide exact steps how to reproduce it. Looks like you use different scenario. bpel files and xslt files (created from xslt project and using wsdl files) and wsdl files appear to have encoding in them based on project encoding. 1. next steps as per 121004 is to verify these and other xml based files using non ascii, since even though encoding tag is that of the project, need to make sure it really works. 2. new xslt in xslt project, at least in pseudo localized locale, and based on wsdl created in that project, shows in design area Unable to show mapper: Cannot resolve input type for transformation (newXSLFile2.xsl) even in en locale - i created the xslt svc using a wsdl file created in the same proejct as the web svc needed for the xslt svc -- is this known issue or pilot error ? ken.frank@sun.com answer about square boxes: Square boxes are representing the name of wsdl_from_db document. I specified it using wizard. I checked on XP usng SQL Module, build 1106, ja locale, UTF-8 project encoding Created attachment 52754 [details]
square boxes
Created attachment 52755 [details]
square boxes (correct MIME type)
I've filed separate issue 121622 on square boxes in wsdl_from_db doc Case 2 about Xslt service is reproducible with 1123 build, XP. ja_JP The problem with case 2 is not encoding problem. It's known issue - 96237. checked the following files (build 1123, XP, ja_JP/win-31j): xsl, xml, xsd, dtd, wsdl, bpel, wsdl_from_db |