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]>
