tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Still have XML loading problems
Date Sat, 24 Mar 2001 16:36:26 GMT


On Sat, 24 Mar 2001, Kevin Jones wrote:

> Craig,
> 
> bear with my ignorance of how Catalina works at this point.
> I'm assuming that the JSP servlet compiles the 'raw' JSP->XML->Java and then
> compiles this to a .class file.
> 

It doesn't actually go to XML if the original syntax was the JSP
syntax.  There are two parsers (sharing a lot of underlying code), that
each go directly to Java.

> Why does the Jasper class-loader delegate to the web-apps classloader, isn't
> the Jasper step entirely independent. If so, couldn't the JSP servlet create
> its own CL that doesn't delegate to the webapps loader, but delegates
> straight to the shared classloader. In fact we could take tools.jar off-of
> the classpath and make it available to this classloader only.
> 

The Jasper page compiler needs to have access to all of the bean classes
that you might have placed in WEB-INF/classes and WEB-INF/lib.  This could
be "faked" by setting up yet another class loader that simulates the
"real" webapp class loader (in terms of what repositories it gives you
visibility to), or by making the special Jasper class loader a sibling of
the webapp class loader (rather than a child), and adding the WEB-INF
repositories to it as well.

This will work as long as you don't create an object in the Jasper class
loader and then expect it to be visible in the webapp class loader (or
vice versa) -- you get class cast exceptions at that point.

> So the Jasper CL would pick up tools.jar, crimson.jar and jaxp.jar and
> everything from my webapp lib and classes, but doesn't delegate to the
> webapp CL. This should have the effect of making Jasper independent of my
> webapp CL.
> 

The Cocoon folks would not be happy if we made tools.jar invisible to
webapps :-).

> The other CLs would work the same.
> 
> It makes the CL architecture slightly more complicated (but it already is
> complicated).
> 

I'll say.

> Will this work?
> 
> Another thought. If Jasper is a two step process (.jsp->XML, XML->Java) as
> step 1, java->.class as step 2, only the first step needs an XML parser, can
> we isolate that first step with a separate CL?
> 

As above, it's not a two step process today -- we took the expedient of
minimal work in creating the original parser so we basically didn't touch
the existing JSP->Java translations.

I'm interested in seeing if we can gather enough folks to start a "Jasper
2.0" effort, on a completely fresh slate.  The design of this would take
into account the two input syntaxes and everything we've learned, and the
implementation could implement many obvious optimizations that would speed
up the runtime code as well.

What do you think?

> Kevin (waiting to be shot down in flames) Jones
> 
> 
> 

Craig



Mime
View raw message