On Fri, 30 Aug 2002, Cox, Charlie wrote:
> Date: Fri, 30 Aug 2002 11:24:14 -0400
> From: "Cox, Charlie" <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> Subject: RE: RE: RE: Problems with class loader
>
> I guess I wouldn't consider it a bug, but rather a consequence of how
> classes are loaded and which class loader holds the files in question.
> But I see your point in that you don't want Hashtable(and more) in all your
> webapps...
>
I'd consider it an unavoidable limitation of the class loading
architecture of Java -- class loaders can look "up" but not "down" the
hierarchy.
However, there is hope for developers who want to put shared classes into
something like common/lib, but still make it possible for those shared
classes to load things from the webapp class loader. Your shared code has
to be specifically programmed to do this, but at least it's possible.
Consider the case where a shared code class wants to load class "foo.Bar"
from the webapp class loader, and then create a new instance of that
class. Modulo exception handling, do something like this:
ClassLoader webappCL = Thread.currentThread().getContextClassLoader();
Class webappClass = webappCL.loadClass("foo.Bar");
Bar bar = webappClass.newInstance();
The reason this works is that the servlet container always copies a
reference to the webapp's class loader to the "context class loader"
property of the request processing thread, immediately before calling your
servlet. This is done precisely to support this kind of access.
Of course, the class you load this way from webapp A will *not* be visible
to webapp B (which uses a different class loader), so you can't use this
mechanism to share classes from /WEB-INF/classes or /WEB-INF/lib across
web applications. But you *can* access webapp classes from shared code.
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
