tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Problem with loading classes dynamically, new objects can't " see" things in webapp.
Date Tue, 11 Sep 2001 22:17:30 GMT


On Wed, 12 Sep 2001, Dmitri Colebatch wrote:

> Date: Wed, 12 Sep 2001 08:02:47 +1000
> From: Dmitri Colebatch <dim@bigpond.net.au>
> Reply-To: tomcat-user@jakarta.apache.org
> To: "'tomcat-user@jakarta.apache.org'" <tomcat-user@jakarta.apache.org>
> Subject: RE: Problem with loading classes dynamically,
>      new objects can't " see"  things in webapp.
>
> On Tue, 11 Sep 2001, Craig R. McClanahan wrote:
>
> > If ProsumerTestTag is being loaded from the class path, it's being loaded
> > by the system class loader.
> >
> > If CustomTag is being loaded from the web app, it is being loaded from the
> > webapp class loader.
> >
> > Classes loaded from the system class loader CANNOT see classes loaded from
> > the webapp class loader -- therefore, Tomcat is telling you the truth.
> > These restrictions are based on the way class loaders work in Java, so
> > there's nothing Tomcat can do about it.
> >
> > Note that any of the following should work:
> > * Put CustomTag and ProsumerTestTag both on the classpath
> > * Put CustomTag and ProsumerTestTag both in the webapp
> > * Put CustomTag on the classpath and ProsumerTestTag in the webapp
> >   (webapp class loaders can look "up" the class loader hierarchy)
>
> ok - this is highlighting my lack of knowledge on classloaders - so
> hopefully I can learn something here.  This is the same thing that causes
> an issue with struts:
>
>   using struts, and jboss with embedded tomcat.  if the struts.jar is
>   in the jboss/lib/ext (command classpath) then it cannot find form or
>   action classes that are in the web application.
>

Exactly the same issue.  That's why the Struts documentation tells you
(over and over again :-) to put "struts.jar" *inside* your web app (in
/WEB-INF/lib) and nowhere else.

> I assume this is due to code along the lines of Class.getClassLoader() -
> now what I dont understand is why those lines of code are not
> Thread.currentThread().getContextClassLoader() .  would that not solve
> both of these problems - it seems to be a more "embeddable" approach,
> letting another container (be it jspc, or jboss) control the system.
>

This would solve the problem in a Servlet 2.3 based container, which is
required to supply the web app class loader when getContextClassLoader()
is called.  However:

* Support for this was not required in Servlet 2.2, so you cannot
  count on it working.  In fact, it won't work in Tomcat 3.2 unless
  you enable the Jdk12Interceptor described in server.xml.

* getContextClassLoader() is not supported at all on JDK 1.1 systems.

> look forward to hearing thoughts on this.
>
> cheers
> dim
>
>

Craig McClanahan



Mime
View raw message