tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Casey Lucas" <clu...@armassolutions.com>
Subject RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Date Sun, 11 Mar 2001 18:10:04 GMT


I pulled src for 3.3 m2 (with jasper.runtime in common dir) and it
all started working.... cool!

Additionally, I have a much better understanding of tomcat's use
of ClassLoaders.

Thanks for the help.

-Casey

> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Sunday, March 11, 2001 3:27 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
> 
> 
> 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
> 

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


Mime
View raw message