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.
tested ML binary: both ja_zh_CN & ru version. /net/smetiste.czech.sun.com/space/builds/netbeans/4.0/daily_ml/200412132030/netbeans-4_0-daily_ml-bin-200412132030-solaris-sparc-ru-13_De\c_2004_2030.bin /net/smetiste.czech.sun.com/space/builds/netbeans/4.0/daily_ml/200412132030/netbeans-4_0-daily_ml-bin-200412132030-solaris-sparc-ml_ja_zh\_CN-13_Dec_2004_2030.bin to reproduce: 1. install daily_ml_ja_zh_CN version of netbeans 4.0. 2. start netbeans in ja locale. 3. Create "Web Application" by "New Project" wizard. 4. Select created Project on Properties and press "F5" 5. build for this application failed by the following exception. /home/hatake/WebApplication12/nbproject/build-impl.xml:295: java.lang.NullPointerException I can reproduce this problem on zh_CN.UTF-8 locale as well as ja, also ru_RU.UTF-8 localel with ml build for ru.
Created attachment 19280 [details] build failed
I didn't see this exception in latest ml build running in zh locale in windows or in 1206 on solaris using pseudo localized, but if Hatake is reporting this as an issue I think it is. I am trying now on solaris with latest ml build. ken.frank@sun.com
It seems problem on non Windows platform. I checked today's, 200412132030 ML build for ja/zh_CN on several platforms. Here is the results: Solaris/SPARC, ja locale : cannot debug Solaris/SPARC, zh_CN.UTF-8 locale: cannot debug Linux, ja_JP.eucJP locale: cannot debug Win XP, japanese locale : *can* debug So, Please check this on non XP platform.
it is an i18n issue. the messages SEL_debuggingType_socket=Socket SEL_debuggingType_shared=Shared Memory in the translatedfiles/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/nodes/Bundle_<locale>.properties are not translatable. i will restore chinese file, and hatake can fix ja file. ken, please mark the two messages with NOI18N. thanks, jack
Can dev team - for short term, mark the 2 messages mentioned below with NOI18N (the issue does not show on all platforms and in all ja/zh locales but its safer to mark these not to translate for now - for the real fix, can you see if these 2 msgs are used programatically or passed to other module or tomcat or jpda -- and thus, if translated, incorrect information might be received and thus thats why the exception happens - the exception error message links to line in build-impl.xml at debugging section transport=jpda.transport ; I separated the jpda arguments on the line to a separate line for each arg and that was the one that was where error was. if the bundle words are used progamatically, can it be changed so that the labels are still available to be translated but the programattic use is done just in the code. ken.frank@sun.com 12/15/2004
this is just my guess - that the 2 messages noted below are used programatically - but only a guess just from grepping in tomcat5 module code -- org.netbeans.modules.tomcat5.nodes.DebuggingTypeEditor.java getTags() that gets the values of those 2 properties, and also TomcatManager.java gets those values in /** default value for property debugging type*/ public static final String DEFAULT_DEBUG_TYPE_UNIX = NbBundle.getMessage (DebuggingTypeEditor.class, "SEL_debuggingTyp e_socket"); /** default value for property debugging type*/ public static final String DEFAULT_DEBUG_TYPE_WINDOWS = NbBundle.getMessage (DebuggingTypeEditor.class, "SEL_debuggingTyp e_shared"); then uses them at getDebugType, getSharedMemory in same file and then those functions are used by other functions there or other places to perhaps set up tomcat or debuggin under it PS also, another string needs NOI18N: LBL_Tomcat_shared_memory_id=tomcat_shared_memory_id this is in TomcatInstanceNode.java with //NOI18N but in bundle file can all tomcat and debug related bundle files be reviewed to see if there are other messages/labels that are used programtically and to either remove them if they are not to be translated (why keep them in bundle at all ?) or if they are words to be translated, make sure their programattice use is in code only and not based on what is in bundle. ken.frank@sun,com
SEL_debuggingType_* strings are indeed used programatically and thus cause problems when translated. I will examine usages of those strings more closely and try to find a proper solution to this.
Strings from bundle are now only displayed in property sheets and are not used programmatically. "SEL_debuggingType_socket" and "SEL_debuggingType_shared" are used internally as keys, their localized display names are presented to users. "LBL_Tomcat_shared_memory_id=tomcat_shared_memory_id" mapping was removed from bundle and only non-localized version is used. There is no need to translate names of shared memory blocks. /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/nodes/DebuggingTypeEditor.java,v <-- DebuggingTypeEditor.java new revision: 1.6; previous revision: 1.5 /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/nodes/TomcatInstanceNode.java,v <-- TomcatInstanceNode.java new revision: 1.41; previous revision: 1.40 /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/Bundle.properties,v <-- Bundle.properties new revision: 1.24; previous revision: 1.23 /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/TomcatManager.java,v <-- TomcatManager.java new revision: 1.68; previous revision: 1.67
verified