I read in Servlet 2.3 Spec that LifecycleListener is also portable, the same as ServletContextListener, Am I wrong ?, I guess not...
Guido. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 11:47 PM To: Tomcat Users List Subject: RE: Extending Standard Context On Thu, 3 Jan 2002, Mark Shaw wrote: > Date: Thu, 3 Jan 2002 17:56:26 -0800 > From: Mark Shaw <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: Extending Standard Context > > Craig, thanks for the quick reply. > > A quick follow-up: is there any reason to use ServletContextListener vs. > LifecycleListener (declaring the listener in web.xml vs. server.xml)? > Technologyically, they do very similar things ... but there is one extremely important difference: ServletContextListener is portable to *any* servlet container that implements Servlet 2.3, while LifecycleListener is something specific to Tomcat 4. > Thanks again, > -Mark > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 03, 2002 1:02 PM > To: Tomcat Users List > Subject: Re: Extending Standard Context > > > > On Thu, 3 Jan 2002, Mark Shaw wrote: > > > Date: Thu, 3 Jan 2002 12:37:56 -0800 > > From: Mark Shaw <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > Subject: Extending Standard Context > > > > I have 2 questions, one regarding the general order of Context > > initialization and the other regarding the use of Contexts, any insight is > > appreciated. > > > > 1) If I define multiple contexts under the same Host will their > constructors > > be called in the same order in which they're defined in server.xml (this > > looks to be the case, but I wasn't sure if it's guaranteed)? Is there a > way > > to guarantee that their start() methods will be called in that same order > > (this isn't the case so I'm looking for a way to order them)? Here's my > > example server.xml: > > > > <Context path="/1" docBase="." className="mypackage.MyContext"/> > > <Context path="/2" docBase="." className="mypackage.MyContext"/> > > <Context path="/3" docBase="." className="mypackage.MyContext"/> > > > > There are no guarantees about the startup order of contexts within the > same host. > > In the HEAD branch of Tomcat 4 (i.e. what you get when you download a > recent nightly build), there is a guarantee about the order that <Service> > elements are initialized in. Assume a configuration like this: > > <Server ...> > > <Service ...> > <Connector ...> > <Engine ...> > <Host ...> > <Context path="/a1" .../> > <Context path="/a2" .../> > </Host> > </Engine> > </Service> > > > <Service ...> > <Connector ...> > <Engine ...> > <Host ...> > <Context path="/b1" .../> > <Context path="/b2" .../> > </Host> > </Engine> > </Service> > > </Server> > > then, Tomcat will guarantee to start all of the "/a1" and "/a2" contexts > (in some undefined order), before going on and starting the "/b1" and > "/b2" contexts (in some undefined order). But this might be more pain > than you really want to go through. > > > 2) I'm using "dummy" contexts and mapping these to components within my > > application, such as a rule engine, daemon threads, etc. in order to use > > Tomcat's manager application to start, stop, and install these components > > which have their own thread associated with them. I've done this by > > extending StandardContext and spawning a new thread when MyContext is > > created and mapping the Context lifecycle commands to this thread. Apart > > from violating the Servlet spec by creating my own thread, is this a > > horrible idea? Does anyone have a better way of managing server > components > > within Tomcat? > > One approach might be to use an application event listener for the > contextCreated() and contextDestroyed() method (you would implement > ServletContextListener). This way, you can fire up whatever services you > need when the webapp is started, and gracefully clean them up when it is > stopped -- without having to modify Tomcat at all. > > Note that the restriction on starting your own threads is a J2EE > requirement, not a servlet spec one. It's legal to do that in a non-J2EE > environment. (If you run Tomcat under a security manager, you'll also > need to ensure that the code is granted the required permissions in the > conf/catalina.policy file). > > > > > Thanks for your help, > > -Mark Shaw > > [EMAIL PROTECTED] > > > > Craig > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
