>
> there is still a problem with shared classloading in current jBoss.
>
> Tomcat fails to compile any JSP file which references a class that is
> only available from the application classpath, ie. the shared
> classpath which is constructed from Manifest-Classpath entries during
> EAR deployment. It seems, that javac is called with the wrong
> classpath. It only includes the WAR and jars from WAR!/lib.
>
> After tracing a JSP request in the debugger, I saw that the various
> jboss-interceptors were called properly and the Thread
> contextClassLoader was set to the jboss' loader. The problem is, that
> to call javac Jasper has to construct a command line option for the
> classpath, but there is no way to get the String representation of the
> contextClassLoader's path.
Since my first post I was trying to solve this problem, but it turned
out, that with the current WAR-deployer there is no easy fix possible.
For me, I found a simple workaround by additionally including the
referenced JARs to WEB-INF/lib, which will automatically added to the
compiler's classpath. During runtime, these classes will be loaded
through jBoss' app classloader, which is the parent of Tomcat's
loader, so intra-VM optimizations will work. I can live with this, but
it is very confusing, as Servlets and JSPs behave differenly when
referencing external classes. Perhaps these issue should be addressed
in the upcoming "Great Deployer Rewrite".
Here is an idea, how to solve the problem: As I reported, Tomcat needs
not only a classloader to locate application classes but also a
"classpath view" of the classloader's internal path. Tomcat uses a
special loader interface ServletLoader which provides these two views.
J2eeDeployer actually has a classpath view of the application libs as
an array of URLs. It uses this array to construct a URLClassLoader,
which then becomes the application classloader. One solution would be
to change the WAR-deployer interface and add one more argument to
'deploy' with the application classpath. Then Tomcat would construct a
ServletLoader from the classpath and a corresponding classloader
too.
Gabor
--
Gabor Herr [EMAIL PROTECTED]
Computer Science Department [EMAIL PROTECTED]
Darmstadt University of Technology
Germany
