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 Sat, 10 Mar 2001 07:12:39 GMT
Hi Casey,

Welcome to the wonderful world of ClassLoading.

The default configuration for 3.3 is to use a separate class loader for
container ( i.e. tomcat.core, jasper, jaxp ) and web applications. 

This resolves a number of problems - like having a different parser in the
web application. 

It also resolves the problem of overriding and fine-control over what is
seen in the web app, and does enhance the security ( most classes that are
 visible in container are "trusted" ).

But what I love about this is that it forces us to make a clear
distinction between what is runtime and what is internal to the container.

To answer to your problem:  I assume TagPoolManager will be available at
runtime to jsps. So it should be included in the common runtime, shared by
both webapps and container. 

TagPoolInterceptor is a container extension, so it'll be part of the
container loader. You shouldn't use static fields in general, but if you
do keep in mind that "static" refers to the ClassLoader+Class combination
( you have one instance of the static field for each class loader ).

BTW, this operating mode ( with multiple loaders ) is the most flexible
for tomcat. The old mechanism still works ( with the old limitations ),
but requires some code to enable it ( it's mostly for embeded tomcat ).


Costin


On Sat, 10 Mar 2001, Casey Lucas wrote:
> 
> Now, I'm testing the pooling stuff out.  I've got a
> TagPoolManagerInterceptor that listens to contextInit, etc.  But my
> problem is that the static TagPoolManager reference that I initialize
> in contextInit always ends up null when the jsp runs.  I put a print statement
> in the static initializer of TagPoolManager and I can see that it is
> being called once when tomcat starts up (and the various contexts are
> loaded) and a second time when the jsp is run.  I assume that there's
> some class loader stuff going on that I don't understand.
> 
> I looked at JspFactory because I'm using the same set/getDefault idiom.
> It some how keeps its static reference that is initilized in contextInit.
> My code seems to be just like JspFactory, yet my static gets reinitialized
> to null.
> 
> Any suggestions?
> 
> -Casey
> 
> > -----Original Message-----
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > Sent: Friday, March 09, 2001 2:29 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: RE: where to plug-in startup/shutdown knowledge for internal
> > tomcat components
> > 
> > 
> > On Fri, 9 Mar 2001, Casey Lucas wrote:
> > 
> > > So, given all that, I need to control lifetime of TagHandlerPoolManager's
> > > default instance.  By controlling it, I can have one TagHandlerPoolManager
> > > instance per web application and when the web application gets unloaded,
> > > all the Tag.release methods can be called.  Aren't the JspServlet and
> > > JspInterceptor mechanisms specific to an individual jsp file?  If so,
> > > I don't think that's what I need because pooling will be for the entire
> > > web application not a specific JSP.
> > 
> > > I was hoping that when the web application (not individual jsp) is
> > > loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization
> > > and cleanup tasks.  Maybe I'm making things too complicated.  Should
> > > managing the lifetime of a per-web-application object like
> > > TagHandlerPoolManager be simpler?
> > 
> > And you have 2 solutions:
> > 1. Use tomcat hooks. You can let a tomcat module manager the
> > TagHandlerPool and you'll get all the notifications you need. 
> > Just implement and TagPoolManagerInterceptor module, implement
> > the hooks you need ( addContext, contextInit, reload, etc).
> > 
> > 2. Use some "hacks" in the generated init()/destroy().
> > For example, in init() you can use a context attribute ( TagPoolManager ),
> > if not set you'll create it and init, if it's set you just use it. 
> > 
> > > Am I off base, with my general strategy?
> > 
> > No, it is ok.
> >  
> > > Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable
> > > to all.  We're currently using 3, but will eventually migrate to 4.
> > 
> > 4.x also have a mechanism to notify you about events - either a 2.3 filter
> > or use the internal Listener interfaces, and most decent servlet
> > containers will provide such a mechanism.
> > 
> > As long as you keep a simple interface to your tag pool, it should be easy
> > to write the container-specific adapter that will plug it in.
> > 
> > 
> > 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
> 


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


Mime
View raw message