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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 09, 2001 2:29 PM
> > To: [EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
