Ah, my worries are confirmed :-)

[EMAIL PROTECTED] wrote:
I don't think addShutdownHook() is enough for a J2EE deployment if you are
relying on static initialization of the thread.  Static initialization
occurs upon application deployment, but the shutdown hook would only run
when the server is stopped, not when the application is undeployed.
Consequently, the application would probably fail to undeploy properly,
which could eventually cause the app server to run out of memory.

AFAIK, in J2EE 1.3 there is no application level startup or shutdown hook.
Maybe something can be done with JMX?

Ken


-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 1:50 PM
To: Log4J Users List
Subject: RE: automatic reload



Howdy,
A decent place to stop and start such threads in a servlet container
would be the ServletContextListener.

There is no static destructor, but you have Runtime#addShutdownHook
which is suitable for this purpose as well. Create a little Runnable
class with a reference to the Watchdog thread, add your Runnable as a
shutdown hook, the JVM will run it (once) on shutdown, and your Runnable
should interrupt the log4j Watchdog thread. This approach is good
outside servlet containers as well.


Yoav Shapira
Millennium ChemInformatics



-----Original Message-----
From: Tom Eugelink [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 1:45 PM
To: Log4J Users List
Subject: Re: automatic reload

Hey Mark,

Well, I could always try to make time (time suddenly is a rare

commodity


once you furthered yourself in the human genepool, at least for the

next


6 years or so).

What I see as a problem is not so much the automatic starting of a
thread, but when to stop it. In a stand alone application this is not
such a problem, but in a container, where you have a separate
configuration for each context (webapp0, I can't imagine

where to hook


that in, in a generic fashion. Starting could be done in the static
constructor of a class, which is loaded by the classloader of the
context, but AFAIK there is no static destructor.

How does the plugin logic start and stop plugins?

Tom



Mark Womack wrote:


Tom,

In v1.3 Watchdogs will be a subclass of Plugin. Plugins are new to

v1.3


and

configurable from (at least xml) configuration files. So,

you'll be able

to

define watchdogs in the configuration files. Plugins have

some code to

not

stop/recreate running plugins during reconfiguration, so eventually

if a


watchdog is watching the configuration file that defines

it, it will be

maintained across reconfigurations, etc. Still working out some of

those


details. Actually the Watchdog code I released way-back-when still

needs


to

be checked into cvs and worked into the plugin infrastructure.

If you have any comments, ideas, or time to review (once I get it

checked


in) I'd love to hear them.

thanks,
-Mark



-----Original Message-----
From: Tom Eugelink [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 6:06 AM
To: Log4J Users List
Subject: Re: automatic reload


I see (took a look at the sources that were included in the older mail).

Basically he has rewritten the "AndWatch" part, expanding it into a
semi-framework, and adding a method to stop the thread
("stopWatching").

Basically one could write a servlet that starts a watchdog
upon load and
stops it upon finalize. It still isn't done totally external of the
application via configuration, but I can see how that can be
a problem.

I'll ponder a bit more. Thank you!

Tom



Jacob Kjome wrote:



look at configureAndWatch() in the configurators.

However, I wouldn't use this in a container as the thread

will run until



the JVM is shut down. There is no manual way to stop it.

Look for Mark Womack's watchdogs in the next version of

Log4j for a


better solution. Here's an old message with some actual

code showing



how it works. Check the latest CVS, though, as things have

probably



changed...
http://marc.theaimsgroup.com/?l=log4j-user&m=101656353725142&w=2

Jake

At 01:52 PM 11/9/2003 +0100, you wrote:



I know there is a parameter which can be used to specifiy

that log4j



must reload a configuration file (checking every so often). But I
prefer autoconfiguration. AFAIK it is not possible to set

autoreload



from a configuration file, correct?

Tom





-----------------------------------------------------------

----------


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]




-----------------------------------------------------------

----------


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]




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




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



Reply via email to