You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Scott Sauyet <li...@sauyet.com> on 2008/01/09 15:57:58 UTC
App server session recovery configures log4j too early
I've been using log4j for years with no issue, but today I've got
something that's stumped me. I need to find a way to either configure
log4j early on application server startup, or at least to reconfigure it
on demand.
I have a custom file appender that I need to statically configure before
the standard log4j configuration. I do this with a simple servlet that
runs at startup before my main application. It sets the directory for
the log files based on application-wide configuration, leaving only the
file name to be set by log4j's configuration file. This works fine...
... except that when the server restarts with live sessions, there are
objects stored in session from a third-party library (Wicket) that hold
references to Loggers. As the application server (Tomcat for now)
recreates these, log4j's initialization starts and the loggers are
configured too early. Because the directory hasn't been set explicitly,
these files end up in Tomcat's root directory. Then when my servlet
runs, the static initialization is too late to have an effect on the
Loggers.
No logging is done in the period before my initialization servlet is
run, so I don't think the files are actually created, so if I can just
just intervene and reset the file appenders' locations, I think I would
be okay. But I don't know how to do that. Is there a straightforward
way to get hold of all FileAppenders of my custom class?
Or is there some better way to do this altogether? Really, the goal is
for the user's configuration of the application to be done in a single
file. That include configuring the location of log files. I think this
could be done by running a custom Configurator, and the code doesn't
scare me, but I still don't know how I could intercept these early calls
to log4j to use my configurator without requiring them to add some
system property. The application is to be distributed as a single war
file, and messing with System properties would be very much frowned
upon. But that was the only other approach I could see.
Any suggestions?
Thanks,
-- Scott Sauyet
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: App server session recovery configures log4j too early
Posted by Scott Sauyet <li...@sauyet.com>.
Jacob Kjome wrote:
> Scott Sauyet wrote:
>> [ ... ] I need to find a way to either configure log4j early on
>> application server startup, or at least to reconfigure it on demand.
>> [ ... ]
>
> Take the Log4j config file that depends on setting up system properties
> out of your classpath. Put a dummy file in the classpath that does
> nothing more than set the root logger to "OFF"....
>
> [ ... ]
>
> Put your real Log4j config file under something like WEB-INF/ and run
> configure() when desired.
Oh, this sounds perfect. I didn't realize it was possible. It probably
means I can skip that silly servlet too. Thank you very much.
> BTW, this also prevents your app from autoconfiguring itself using a
> config file found in the parent classloader. It guarantees that your
> dummy file will be used for auto configuration.
That's not an issue in my test environment, but I could easily see it
coming up in some production.
Thank you very much for your help.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: App server session recovery configures log4j too early
Posted by Jacob Kjome <ho...@visi.com>.
Take the Log4j config file that depends on setting up system properties out of
your classpath. Put a dummy file in the classpath that does nothing more than set
the root logger to "OFF"....
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://logging.apache.org/log4j/" debug="false"
threshold="debug">
<root>
<level value="off"/>
</root>
</log4j:configuration>
Put your real Log4j config file under something like WEB-INF/ and run configure()
when desired.
BTW, this also prevents your app from autoconfiguring itself using a config file
found in the parent classloader. It guarantees that your dummy file will be used
for auto configuration.
Jake
Scott Sauyet wrote:
> I've been using log4j for years with no issue, but today I've got
> something that's stumped me. I need to find a way to either configure
> log4j early on application server startup, or at least to reconfigure it
> on demand.
>
> I have a custom file appender that I need to statically configure before
> the standard log4j configuration. I do this with a simple servlet that
> runs at startup before my main application. It sets the directory for
> the log files based on application-wide configuration, leaving only the
> file name to be set by log4j's configuration file. This works fine...
>
> ... except that when the server restarts with live sessions, there are
> objects stored in session from a third-party library (Wicket) that hold
> references to Loggers. As the application server (Tomcat for now)
> recreates these, log4j's initialization starts and the loggers are
> configured too early. Because the directory hasn't been set explicitly,
> these files end up in Tomcat's root directory. Then when my servlet
> runs, the static initialization is too late to have an effect on the
> Loggers.
>
> No logging is done in the period before my initialization servlet is
> run, so I don't think the files are actually created, so if I can just
> just intervene and reset the file appenders' locations, I think I would
> be okay. But I don't know how to do that. Is there a straightforward
> way to get hold of all FileAppenders of my custom class?
>
> Or is there some better way to do this altogether? Really, the goal is
> for the user's configuration of the application to be done in a single
> file. That include configuring the location of log files. I think this
> could be done by running a custom Configurator, and the code doesn't
> scare me, but I still don't know how I could intercept these early calls
> to log4j to use my configurator without requiring them to add some
> system property. The application is to be distributed as a single war
> file, and messing with System properties would be very much frowned
> upon. But that was the only other approach I could see.
>
> Any suggestions?
>
> Thanks,
>
> -- Scott Sauyet
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org