tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
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. 

Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org


Mime
View raw message