Yes, the problem is a null value in the locale instance var of java.util.ResourceBundle, I did a debugging session and can confirm this problem.
Do you have a possiblity to initialze this instance variable with the default locale (Sun sdk does it, ibm sdk not) ? Afterwards, can you send me an url to get the source code ? christian Martin Desruisseaux writes: > Hello Christian > > Thanks for your encouragement with java.util.concurrent. I'm quite pleased > with it. It took me a few hours to get used to think in terms of > "putIfAbsent" or "replace" instead of the usual "get" and "put", but once > I get used it was really a charm. > > Christian Müller a écrit : >> Did you look at the stack traces I sent you ? (Testing geotidy on an IBM >> sdk) > > Yes and I applied a patch right away, but got an other failure quicky > after that. The problem is a bit a mystery to me; its look like that when > we ask for a java.util.ResourceBundle, its "locale" field is not set (i.e. > is left to its null value). For now I don't know why we get a different > behavior with IBM sdk compared with Sun SDK in this regards - with Sun > JDK, the "locale" field is set to the expected value. I would need to > investigate more. > > The usage of Locale.getDisplayName() that you pointed should not be in > cause since it is used only for formatting a logging message, not for > decision logic. > > Regards, > > Martin ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
