The updated class can be found here
CoreModule.java.
You can apply the following patch to the old version to fix the bug
CoreModule.java.patch
patch CoreModule.java < CoreModule.java.patch
Hope someone with write access to CVS can fix the bug as soon as possible.
View the original po
Sorry the proposed fix still has subtle bugs.
What we really want is the following order of lookup resource bundles
baseName+"_"+language1+"_"+country1+"_"+variant1
baseName+"_"+language1+"_"+country1
baseName+"_"+language1
baseName+"_"+language2+"_"+country2+"_"+variant2
baseName+"_"+language2+
Code in previous post was incomplete, here is the complete one.
377 // If nothing is right we will endup with en_US locale.
378 Locale preferedLocale = Locale.US;
379 for (Enumeration e = req.getLocales();e.hasMoreElements();)
380 {
There is another problem, according to java API, the resource bundle is is loaded in
following order (language1, country1 is the specified locale; language2 and country 2
is the default locale of the Java Virtual Machine).
baseName + "_" + language1 + "_" + country1 + "_" + variant1
baseName +
The following code in nukes/src/main/org/jboss/nukes/core/modules/core/CoreModule.java
do not work properly if the client's first preference is US locale and second
preference is another locale and the server support both locale. In the described
scenario, the server will choose the second prefer
