tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Date Sun, 11 Mar 2001 09:27:04 GMT
Hi Casey,

I agree, resolving class loader problems is not easy. But it does have a
bit of logic :-)

The solution you found ( put everything in common/ ) is ok - that's how
tomcat worked in 3.2 and before, and still works.

Resolving the problem with a separate class loader for container is a bit
more difficult - the main benefit is that the container implementation (
modules and libs that are used - including jaxp ) are separated from the
web application.

> attempt 1:
> For each contextInit, TagPoolManagerInterceptor called
> TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl,
> yet when the jsp called TagPoolManager.getDefaultManager, the static
> reference set in setDefaultManager came back null.

Try to do a println( TagPoolManager.getClassLoader().toString() ) every
time you use it. You'll see what happens ( 2 different class loaders ).

You can also try to print the parent loader.

> Giving up on that, I tried 2:
> Use no statics, just call Context.setAttribute in the interceptor.  In
> the jsp use Context.getAttribute.  The object that comes back is
> the exact same TagPoolManagerImpl that was put there by the interceptor
> but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for
> that matter), I get a ClassCastException.

Same problem - different class loaders -> different classes :-)

> I was originally trying to follow the model of JspFactory.  I modeled my
> interceptor after the JspInterceptor, but no luck for me.  I noticed that
> sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common.  Maybe that's

That was fixed recently, servlet.jar should be only in common.

> why JspFactory works.  I jared up the TagPool* classes and stuck them into
> TC_HOME/lib/common and everything worked.  Even though it worked, it didn't
> seem right putting jasper.runtime.Tag* classes into the common directory.
> Any help / suggestions would be greatly appreciated.

jasper.runtime is now in common ( we did a number of fixes since M1 ). 
Everything that should be visible to webapps ( and jasper runtime is one
example - since jsps are using the classes from runtime ) should be in 
common ( i.e. visible in both apps and container ).

Jasper itself ( the compiler ) is in a separate loader.

Think of the container as another application, that happens to provide
some services to other apps. 

The common dir is what all applications are seeing ( including the
container ). Each app has it's own local jars, providing the local
functionality. The container provides jsp compilation, configuration, 
and other services that are used by tomcat. 


To unsubscribe, e-mail:
For additional commands, email:

View raw message