The problem is that ResourceBundle is kindof broken. Like many other
java APIs ( JAXP, JNDI, URL, etc ), early versions are not capable
of using the application class loader.
This is ( IMHO ) a bug, and for some APIs it is fixed ( JAXP and JNDI for
sure, unfortunately not for URL ).
The solution - for JDK1.2+ - is to use the 3 parameter getBundle, with
Thread.currentThread().getContextClassLoader() as the third param.
For JDK1.1 there's nothing you can do.
Let me know if it doesn't work - I tried this before and I had no
problems. The resources could be in WEB-INF/classes, a jar in
WEB-INF/lib or any jar in the app.classloader.
Costin
On Mon, 26 Nov 2001, Keith Wannamaker wrote:
> I think there may be a problem with resource loading in TC3.3.
> If I add a property file to the app class path by setting
> org.apache.tomcat.apps.classpath, then the call to
> ResourceBundle.getBundle("foo") doesn't find it. Nor does
> it get located if I place the said property file in tomcat/lib/apps.
> In fact, the only way I have been able to find it is to
> override the classpath in the tomcat script.
>
> The good news is that, by setting org.apache.tomcat.apps.classpath,
> initClassLoaders() does set the AppsLoader class to a ClassLoader
> which contains my properties file.
>
> The bad news is this doesn't seem to be the deafult loader used
> in the call to ResourceBundle.getBundle("foo").
>
> The only thing I can think of trying is
> ResourceBundle.getBundle("foo", Locale.getDefault(),
> magic.ContextManager.getAppsLoader());
> but that binds the code to the Tomcat container.
>
> My next step is to rebuild the jdk with debugging info to see which
> loader is actually being used in ResourceBundle.getBundle, but
> I appreciate any insight in the interim.
>
> Keith
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
