tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof>
Subject Re: classloader issues (ClassCastException on org.xml.sax.Parser)
Date Wed, 23 Jan 2002 23:05:59 GMT
On Wed, Jan 23, 2002 at 02:28:52AM -0800, Remy Maucherat wrote:
> > On Tue, Jan 22, 2002 at 06:14:18PM -0800, Remy Maucherat wrote:
> >
> > Do you mean you're spawning another process to do compilation?  I
> > thought that javac's core class had been fixed so that it'd be possible
> > to run it in a thread in an existing server ... for a number of reasons,
> > including performance and the awkwardness of spawning processes on
> > win32.  (I know there was talk about that years ago, when I last worked
> > on a page compilation system, but I don't know what happened with it.)
> Jasper uses the javac API which doesn't spawn a process, but it still
> behaves the same way it does if you actually spawn a process.

You said the reason that we can't do what I suggested is that it would
"make JSPs behave differently from servlets" -- so I went to look at
Jasper to see how similar the behavior is right now, in terms of
classloading.  It looks like there's no guarantee at all about

Jasper already assumes that the classpath for JSP compilation may be
different from that used in servlets.  There are a number of
inconsistencies, including at least the following:

1) jars accessed by URLs using protocols other than the file protocol
will be silently left out (

2) the order of classname resolution does not match the special logic in
WebappClassLoader, since the webapp classloader's jars aren't ever
preptended to the system classpath, they're always appended
(  I haven't yet followed the logic all the way back
in terms of how the data gets into the context for use by JspServlet --
it is possible that the order is reversed somewhere else ... but if so,
the logic isn't in WebappClassLoader, which is the only class which will
know if delegation is true or false.  So I suspect it's not being done.

Note that #2 may mean that excluding the jars from the classpath to
Jasper might not be such a big deal, as the only reason for the
filtering of those jars in WebappClassloader is the fact that they could
override classes defined in their parent classloaders.

I can imagine that there may be other good reasons not to allow the
changes which I suggested, but AFAICT there's very little consistency
left to be preserved, when comparing classpath handling for JSP pages
and servlets.

> Also, you can't change the delegation and still be spec compliant. We could
> avoid implementing the requirement of preventing loading core libraries, if
> it turns out it's not implementable.

I don't mind configuring tomcat so that my install isn't spec compliant
(that's already possible, with the setDelgate toggle).  I tend to feel
as Daniel said -- the spec is broken.  But I can understand wanting to
build tomcat in such a way that it satisfies the spec as well as is

It is possible to be compliant with the specification, but I don't think
the current implementation is.  I can override classes in each of the
"protected" packages, so long as I take care to leave out the trigger
class, for which tomcat looks, in my .jar files -- so if it's tomcat's
job to avoid loading core libraries in the webapp classloaders, I don't
think it's doing it reliably.

Anyway -- one possibility would be to do filtering of .jars before
handing them to the JSP engine (much as it's being done now, thought it
might make more sense to read through the contents of the jars and look
for any classes which are in packages they're not allowed to be in), but
to do the kind of filtering which I described in my first message, in
loadClass.  And I'd suggest adding one or more toggles, to configure how
filtering is done.  (I'm not sure if one or two is appropriate because
I'm not sure if #2 -- up above -- should be fixed.)

thanks --


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message