Ok, I'm going crazy. I had everything setup like you recommended (at
least I thought I did), but I'm still running into problems.
scenarios:
TagPoolManagerInterceptor is in package org.apache.tomcat.modules.tagpool
TagPoolManager (Impl, etc) are in org.apache.jasper.runtime
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.
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.
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
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.
-Casey
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, March 10, 2001 1:13 AM
> To: [EMAIL PROTECTED]
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
