[
http://issues.apache.org/jira/browse/JDO-178?page=comments#action_12332295 ]
Michael Bouschen commented on JDO-178:
--------------------------------------
The patch calls ResourceBundle.getBundle(bundleName, locale) if the specified
class loader is null. This calls getBundle with the caller's class loader, in
this case the class loader that loaded I18NHelper.
I'm not sure whether this is the right class loader. Instead we could use the
system class loader, if the specified class loader is null:
if (loader == null) {
loader = ClassLoader.getSysytemClassLoader();
}
messages = ResourceBundle.getBundle(bundleName, locale, loader);
> javax.jdo.spi.I18NHelper causes NullPointerException
> ----------------------------------------------------
>
> Key: JDO-178
> URL: http://issues.apache.org/jira/browse/JDO-178
> Project: JDO
> Type: Bug
> Components: api11, api20
> Environment: Debian GNU/Linux sid
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
> Jakarta-Tomcat 5.5.9
> KODO JDO 3.3.4
> Reporter: Marcin Owsiany
> Priority: Minor
> Attachments: i18nhelper.patch
>
> In the above environment, I encountered exception being thrown on
> JDOHelper.getPersistenceManagerFactory(p) invocation. The exception was a
> tricky one, because .printStackTrace() called on it caused another exception
> to be thrown, forcing me to manually inspect it by iterating on result of
> .getStackTrace().
> Anyway, here is what I found after a loooong battle:
> On JDOHelper class init, an I18NHelper instance is instantiated. On that
> instantiation, an attempt is made to load a resource bundle, using
> ResourceBundle.getBundle(s, locale, classloader). The classloader is obtained
> by calling (javax.jdo.spi.I18NHelper.class).getClassLoader(). However in my
> case, this getClassLoader() call returned null, which, to my surprise, is
> fine according to J2SE API.
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getClassLoader()
> says that:
> Some implementations may use null to represent the bootstrap class
> loader. This
> method will return null in such implementations if this class was loaded
> by the
> bootstrap class loader.
> Anyway, when that null is passed to ResourceBundle.getBundle, it throws a
> NullPointerException.
> Furthermore, that exception is wrapped in another exception,
> JDOFatalInternalException if I recall correctly, whose superclass' toString()
> uses (surprise, surprise) an I18NHelper instance to get the exception
> description. This makes it impossible to investigate such exception using
> toString() (for example via log4j).
> OK, in truth, the above is a simplified version :-) In fact the exception is
> saved for later use by I18NHelper, and makes it to the JDO user only when the
> JDO implementation being used throws another, possibly unrelated, exception
> during its PersistenceManagerFactory instantiation (in my case it was a trial
> kodo version throwing a LicenseException). But the exception thrown by the
> JDO implementation gets lost, and the user only gets a quite unexpected JDO
> exception, which is hard to debug because of the aforementioned attachment of
> the exception to I18NHelper.
> Fortunately, the fix is quite easy:
> --- javax/jdo/spi/I18NHelper.java 2005-10-06 21:26:17.000000000 +0200
> +++ javax/jdo/spi/I18NHelper.java 2005-10-06 21:26:11.000000000 +0200
> @@ -114,7 +114,10 @@
> ResourceBundle resourcebundle = (ResourceBundle)bundles.get(s);
> if(resourcebundle == null)
> {
> + if(classloader != null)
> resourcebundle = ResourceBundle.getBundle(s, locale,
> classloader);
> + else
> + resourcebundle = ResourceBundle.getBundle(s, locale);
> bundles.put(s, resourcebundle);
> }
> return resourcebundle;
> This uses another ResourceBundle method if bootstrap classloader is to be
> used. Another way could possibly be to use a thread context classloader
> before trying the system classloader, but that's just my guess (I didn't try
> if the other classloader turns out non-null).
> I hope that my convoluted description can be understood. The above patch
> fixes the problem for me.
> regards,
> Marcin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
