logback initialization "à la" Spring

[Davide Baroncelli]

Hi, I'm thinking about moving to logback after a life happily spent using log4j: nevertheless I'm having problems understanding if there's a way to initialize it in a similar way as we did with log4j.

What I do not want to do is put a configuration file under the WEB-INF/classes dir in my webapp: all of our configuration files are stored under WEB-INF/cfg, and we want to continue this way.

I see that logback has a way to define contexts through jndi, but we do not want to ask our system administrators to change the config of our weblogic clusters just because we think about introducing a new library: is there another way?

What I'd like to obtain is something like we did with Spring's Log4jConfigListener: simply define into the web.xml a listener which configures the logging subsystem at startup time using the xml file indicated by a servlet context parameter. Is there something like that? I was thinking about writing a class by myself, but I see no way to do it without triggering the BasicConfigurator part in the static initialize method of StaticLoggerBinder.

Thank you,
Davide Baroncelli

P.s.: let me express my disagreement for logback and sl4j not supporting neither the FATAL logging level nor automatic reloading of config files.

[Jorg Heymans-3]

On 9/27/07, Davide Baroncelli <baroncelli@...> wrote:

P.s.: let me express my disagreement for logback and sl4j not supporting
neither the FATAL logging level nor automatic reloading of config files.

+1 for automatic reloading !

Jorg

_______________________________________________
Logback-user mailing list
Logback-user@...
http://qos.ch/mailman/listinfo/logback-user

[Joern Huxhorn]

Hi Davide.

It's possible to change the logging configuration at runtime with code
like this:

        ILoggerFactory loggerFactory = LoggerFactory.getILoggerFactory();
        if (loggerFactory instanceof LoggerContext)
        {
            LoggerContext loggerContext = (LoggerContext)
LoggerFactory.getILoggerFactory();
            if (verbose)
            {
                // reset previous configuration initially loaded from
logback.xml
                loggerContext.shutdownAndReset();
                JoranConfigurator configurator = new JoranConfigurator();
                configurator.setContext(loggerContext);
                URL configUrl;
                configUrl = getClass().getResource("/logbackVerbose.xml");
                try
                {
                    configurator.doConfigure(configUrl);
                    if (logger.isDebugEnabled())
logger.debug("Configured logging with {}.", configUrl);
                    StatusPrinter.print(loggerContext);
                }
                catch (JoranException ex)
                {
                    if (logger.isErrorEnabled()) logger.error("Error
configuring logging framework!", ex);
                    StatusPrinter.print(loggerContext);
                }
            }
        }

The instanceof and cast are only needed because we are using logback via
slf4j.
I don't think this is exactly what you are looking for but it should
help you writing your own class, at least.

I've never used  Log4jConfigListener myself so I don't know how it works
but doesn't the configuration of the logging environment during normal
spring-initializations mean that at least some spring-log-events are
swallowed? If this is not the case then everything should be fine.

I hope this helps.

Joern.

Davide Baroncelli wrote:

> Hi, I'm thinking about moving to logback after a life happily spent using
> log4j: nevertheless I'm having problems understanding if there's a way to
> initialize it in a similar way as we did with log4j.
>
> What I do not want to do is put a configuration file under the
> WEB-INF/classes dir in my webapp: all of our configuration files are stored
> under WEB-INF/cfg, and we want to continue this way.
>
> I see that logback has a way to define contexts through jndi, but we do not
> want to ask our system administrators to change the config of our weblogic
> clusters just because we think about introducing a new library: is there
> another way?
>
> What I'd like to obtain is something like we did with Spring's
> Log4jConfigListener: simply define into the web.xml a listener which
> configures the logging subsystem at startup time using the xml file
> indicated by a servlet context parameter. Is there something like that? I
> was thinking about writing a class by myself, but I see no way to do it
> without triggering the BasicConfigurator part in the static initialize
> method of StaticLoggerBinder.
>
> Thank you,
> Davide Baroncelli
>
> P.s.: let me express my disagreement for logback and sl4j not supporting
> neither the FATAL logging level nor automatic reloading of config files.
>  

_______________________________________________
Logback-user mailing list
Logback-user@...
http://qos.ch/mailman/listinfo/logback-user

[Arthur Blake]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I've used automatic reloading in the past in log4j and it certainly can be a very nice and convenient feature--

There are various issues that come up in the complexity of implementing it -- normally it's done with a separate Thread that runs and wakes up every so often to check if the file timestamp on the config file has changed.

Thats a bit of a clunky and complex way to do it.

I have been mentally toying with an idea for a new way to accomplish this, without having to have a separate thread-- The check could be done at the point where each log message is generated-- system wide.

Since you already know the timestamp of the message generated, you could just compare that to the timestamp of the last time the log config file was reloaded-- and if a certain amount of time has elapsed since the last time the file was checked, you kick off the code that checks to see if the file time stamp has changed, and if so, reload it (that part could be done asynchronously as well so as not to slow down other threads writing out log messages)

It's simple, fast and it would have the very nice benefit of not having to have a separate Thread-- furthermore, you avoid the overhead of periodically checking the modification file stamp, over long periods when there is no log activity (such as idle periods when a server might not be getting any activity)

Has anyone thought of implementing it this way?

----- Original Message ----
From: Jorg Heymans <jorg.heymans@...>
To: logback users list <logback-user@...>
Sent: Thursday, September 27, 2007 10:23:07 AM
Subject: Re: [logback-user] logback initialization "à la" Spring

On 9/27/07, Davide Baroncelli <baroncelli@...> wrote:

P.s.: let me express my disagreement for logback and sl4j not supporting
neither the FATAL logging level nor automatic reloading of config files.

+1 for automatic reloading !

Jorg

---

Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more!
_______________________________________________
Logback-user mailing list
Logback-user@...
http://qos.ch/mailman/listinfo/logback-user

[Tom Leccese]

Some parts of this message have been removed. Learn more about Nabble's security policy.

One snafu, perhaps.  If all your loggers in your current config are turned OFF, then a message would never get generated, and it would never check to see if the config file has changed.

-----Original Message-----
From: logback-user-bounces@... [mailto:logback-user-bounces@...]On Behalf Of Arthur Blake
Sent: Thursday, September 27, 2007 12:45 PM
To: logback users list
Subject: Re: [logback-user] logback initialization "à la" Spring

I've used automatic reloading in the past in log4j and it certainly can be a very nice and convenient feature--

There are various issues that come up in the complexity of implementing it -- normally it's done with a separate Thread that runs and wakes up every so often to check if the file timestamp on the config file has changed.

Thats a bit of a clunky and complex way to do it.

I have been mentally toying with an idea for a new way to accomplish this, without having to have a separate thread-- The check could be done at the point where each log message is generated-- system wide.

Since you already know the timestamp of the message generated, you could just compare that to the timestamp of the last time the log config file was reloaded-- and if a certain amount of time has elapsed since the last time the file was checked, you kick off the code that checks to see if the file time stamp has changed, and if so, reload it (that part could be done asynchronously as well so as not to slow down other threads writing out log messages)

It's simple, fast and it would have the very nice benefit of not having to have a separate Thread-- furthermore, you avoid the overhead of periodically checking the modification file stamp, over long periods when there is no log activity (such as idle periods when a server might not be getting any activity)

Has anyone thought of implementing it this way?

----- Original Message ----
From: Jorg Heymans <jorg.heymans@...>
To: logback users list <logback-user@...>
Sent: Thursday, September 27, 2007 10:23:07 AM
Subject: Re: [logback-user] logback initialization "à la" Spring

On 9/27/07, Davide Baroncelli <baroncelli@...> wrote:

P.s.: let me express my disagreement for logback and sl4j not supporting
neither the FATAL logging level nor automatic reloading of config files.

+1 for automatic reloading !

Jorg

---

Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more!

This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal.
_______________________________________________
Logback-user mailing list
Logback-user@...
http://qos.ch/mailman/listinfo/logback-user

[Davide Baroncelli]

Joern Huxhorn wrote:

Hi Davide.

It's possible to change the logging configuration at runtime with code
like this:
        ILoggerFactory loggerFactory = LoggerFactory.getILoggerFactory();

Hi, thank you very much for your help: I finally managed to write something very similar to what's in Spring. You can find it here (here) in case someone should be interested. I finally resorted to using
ContextInitializer.configureByResource( loggerContext, url );
which spares some lines of code.

Joern Huxhorn wrote:

I've never used  Log4jConfigListener myself so I don't know how it works
but doesn't the configuration of the logging environment during normal
spring-initializations mean that at least some spring-log-events are
swallowed? If this is not the case then everything should be fine.

No, it does not because this is "in Spring" but only from a library perspective (i.e. you don't need a running application context in order to use it): it gets configured as a listener or a servlet with init order = 0, so it is initialized before anything else. The log4jconfiglistener and servlet in Spring allow configuring also the auto-reload (turn it on-off and reloading time): since there is no autoreload in logback I stripped this out of my listener.

[Davide Baroncelli]

Davide Baroncelli wrote:

P.s.: let me express my disagreement for logback and sl4j not supporting neither the FATAL logging level nor automatic reloading of config files.

Ok, I developed a small Spring runnable component useful for auto-reloading of logback configs. It may be configured in an application context like this:

<bean id="logbackReconfigurer" class="org.springframework.scheduling.concurrent.ScheduledExecutorFactoryBean">
        <property name="scheduledExecutorTasks">
            <list>
                <bean class="org.springframework.scheduling.concurrent.ScheduledExecutorTask">
                    <property name="period" value="5000"/>
                    <property name="runnable">
                        <bean class="it.stratosfera.commons.logback.LogbackConfigurationReloaderRunnable">
                            <property name="configResource" value="/WEB-INF/carcon-logback.xml"/>
                        </bean>
                    </property>
                </bean>
            </list>
        </property>
    </bean>

should anyone be interested, I re-attach a package with the updated classes, here.