Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 39472 invoked by uid 500); 10 Mar 2001 06:14:10 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 39463 invoked from network); 10 Mar 2001 06:14:10 -0000 From: "Casey Lucas" To: Subject: RE: where to plug-in startup/shutdown knowledge for internal tomcat components Date: Sat, 10 Mar 2001 00:32:47 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Costin. Thanks for the help and sorry for all the questions. I wasn't familiar with tomcat hooks and didn't understand the JspInterceptor. But that was then... 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