Hi,

>According to your suggestion it is advisable not to use
>ServletContextListener if we are using <load on startup> feature.
>And we just need to create a separate servlet for destroying daemon
>threads.

Say what?  That's not what I said or at least not what I meant ;)  A
ServletContextListener is good.  A <load-on-startup> servlet is also
good, but for other things, as the container may restart it at will.
Using one does not preclude using the other.  For your scenario, I think
the Listener is a better choice than the servlet.

Yoav

>
>Please provide us your valuable thoughts.
>
>
>-Jignesh
>
>
>
>On Wed, 2004-07-28 at 08:57, Shapira, Yoav wrote:
>> Hi,
>> Excellent answer by Rodrigo Ruiz.  I wanted to correct one tiny part,
>> and for Tomcat it's a theoretical correction only, but since this a
>> common mistake and a blemish on an otherwise great post:
>>
>> <load-on-startup> servlets are initialized on startup by the
container.
>> But that doesn't mean they are destroyed on shutdown like the
>> ServletContextListener.  The container is free to destroy these
servlets
>> as it sees necessary, usually to preserve resources if they are not
>> under load and other servlets are.  Therefore it's entirely possible
and
>> legal for a <load-on-startup> servlet to be initialized and destroyed
>> numerous times while the webapp is NOT restarted.
>>
>> Accordingly, take his advice and use a ServletContextListener.
That's
>> what it's for ;)
>>
>> Yoav Shapira
>> Millennium Research Informatics
>>
>>
>> >-----Original Message-----
>> >From: Rodrigo Ruiz [mailto:[EMAIL PROTECTED]
>> >Sent: Wednesday, July 28, 2004 6:21 AM
>> >To: Tomcat Users List
>> >Subject: Re: detecting the shutdown of tomcat in a servlet
>> >
>> >There is more than one way :-)
>> >
>> >- From within a servlet, add a shutdown hook with
>> >Runtime.getRuntim().addShutdownHook()
>> >- Create a ServletContextListener, and implement the clean stop of
your
>> >daemon in the listener contextDestroyed() method
>> >- Create an initialization servlet, and implement the clean stop in
its
>> >destroy() method
>> >
>> >and probably a few more if you use specific Tomcat classes.
>> >
>> >I would not use the first option unless really necessary, as it
seems
>> to
>> >me a too much "low level solution".
>> >My favourite is the second option, as this is what
>> >ServletContextListeners are for. You could start and stop the thread
>> >from this listener.
>> >
>> >The second and third options will perform the thread stop when the
>> >context or the container are shut down. This includes a context stop
>> >from the admin webapp. Whether this is good or bad for your purposes
>> >depends on the actions you need to perform. I suppose you do not
want
>> >your thread to keep running if you stop the webapp, because
restarting
>> >the webapp would lead to have two daemon threads :-)
>> >
>> >HTH,
>> >Rodrigo Ruiz
>> >
>> >STOCKHOLM, Raymond wrote:
>> >
>> >>In my tomcat 4.1.30n, I have a webapp in which a deamon Thread
>> (started
>> >automatically)
>> >>is scheduled to send automatic mails every morning.
>> >>
>> >>I would like to make a clean stop of my deamon when tomcat
shutdowns.
>> >>
>> >>How can I detect that tomcat is shuting down ?
>> >>
>> >>
>> >>Raymond Stockholm
>> >>Aubay Luxembourg
>> >>51, Rue de Strasbourg
>> >>L-2561 LUXEMBOURG
>> >>Tel : +352 29 92 50 31
>> >>
>> >>
>>
>>---------------------------------------------------------------------
>> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>For additional commands, e-mail:
[EMAIL PROTECTED]
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >--
>> >Outgoing mail is certified Virus Free.
>> >Checked by AVG anti-virus system (http://www.grisoft.com).
>> >Version: 6.0.727 / Virus Database: 482 - Release Date: 27/07/2004
>> >
>> >
>>
>---------------------------------------------------------------------
>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>> This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else.  If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender.  Thank you.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to