Thank you, Jess...

I'm now trying to use the (log4j) ConfigurationServlet in order to learn
more about these problems...the information bellow is very usefull!

Alvim.

-----Mensagem original-----
De: Jess Holle [mailto:[EMAIL PROTECTED]
Enviada em: sexta-feira, 14 de outubro de 2005 10:05
Para: Tomcat Users List
Cc: Tomcat Users List; [EMAIL PROTECTED]
Assunto: Re: RES: Tomcat Log4j Log Level Configuration


Paulo Alvim wrote:

>Hi Jojo,
>
>I'm with the same problem: I'd like to change the "log level" e also the
>"appender configurations" without redeploy my war (my log4j.properties file
>is bundled into the web-inf/classes)...
>
>
This is a major failing of the WAR format as I see it.  You have to
redeploy everything to change anything but the deployment descriptor.
That seems less than realistic for a large web application.

>I have thought about a few - not very good - approaches (of course the best
>one would be an "out-of-box" solution):
>
>- I was wondering if I could change the log level by programming against
>Log4j memory beans...have you already tried that? I have already done this
>kind of configurations with Java code to initialize the appenders and
>levels, but I'm not sure if there are performance or "thread safe" issues
>related to modified them "on fly"...
>
>
Do you mean log4j management bean (MBeans)?  If so, there are issues
with these and use per-web-app logging repositories.

I wrote my own MBeans for log4j to get around this and many other issues
I encountered with the bundled MBeans.  [My MBeans allow me to create a
separate branch of MBeans for each log4j LoggerRepository, e.g. one per
web app and one for the default LoggerRepository as well if one
configures Tomcat itself to use log4j as well.]

>- Try to put my log4j.properties out of the war (something like "each war's
>log4j file into subdirectories of Tomcat's log directory"). This would also
>require app code to "reload" log4j configuration - I don't know if it's
>possible...
>
>
This is doable.  You could have JNDI environment entries in your
deployment descriptor (your Context XML) calling out the location of
your log4j properties (or XML) file.  You can then have a thread watch
this for changes and reapply the config file on the fly when changes are
noticed.  log4j has functionality for this, but it is problematic in
that you can't cleanly close down the threads on web app shutdown, etc,
so you're better off writing your own (or using log4j 1.3, which
supposedly fixes this but is in alpha...)

>- Manage log4j configurations as JMX beans...I'm not using JMX in depth but
>it seems that I'd be able to modify the configuration this way.
>
>
Oh, so you meant something else above.

--
Jess Holle

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