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.
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.
look forward to hearing thoughts on this.
cheers
dim
