Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 95829 invoked by uid 500); 9 Mar 2001 20:26:32 -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 95816 invoked from network); 9 Mar 2001 20:26:31 -0000 X-Authentication-Warning: simona.wyn.org: costin owned process doing -bs Date: Fri, 9 Mar 2001 12:28:59 -0800 (PST) From: cmanolache@yahoo.com X-Sender: costin@simona.wyn.org To: tomcat-dev@jakarta.apache.org Subject: RE: where to plug-in startup/shutdown knowledge for internal tomcat components In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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