Hello Holger, Thank you for your response. Bender Heri has described a similar use case on the log4j-user list. I believe that the problem you describe, namely separation of logging (per thread), can be accomplished by means other than repository selectors. Assuming a new appender, say MultiAppender, was capable of embedding and managing other appenders per thread basis, you would no longer need context selectors. More importantly, most of the work would be done by MultiAppender. You would only need to configure it in logback.xml and push MDC values at the beginning of each thread. (I am making the assumption that the MDC can be used to distinguish threads.) Needless to say, there is no intention of removing support for context selectors. Mense, Holger wrote:

Hello,

...

I am in the process of fixing bugs related to context selectors in logback. However, while sometime ago I thought that context selectors were the wave of the future, I am increasingly skeptical about their usefulness (of context selectors).

...

If you are using context selectors, could you please explain why?

I am developing a multi threaded application, which can be executed all together in one JVM or in several JVMs. In order to have the possibility of different logback configurations and the same log behaviour in different runtime environments I am using my own ContextSelector, which decides on behalf of the source thread, where the log request comes from, which LoggerContext should be used for the log event.

So I would not like to see ContextSelector support gone in SLF4J or Logback.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Holger Mense Wincor Nixdorf International GmbH Banking Division Product Development (PSD5) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

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

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

We haven't looked into j.u.l over logback, but once we upgrade to tomcat 6 we'll likely want tomcat logging controlled by logback. I assume we may have similar initialization concerns once we upgrade to tomcat 6. casey -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Ceki Gulcu Sent: Thursday, November 27, 2008 3:56 AM To: logback users list Subject: [SPAM] - Re: [logback-user] - Context selectors useful? - Email found insubject - Email found in subject Hello Lucas, Thank you for your detailed and helpful response. Web-applications can accomplish logging isolation by simply embarking their own copy of slf4j-api.jar and logback-*jar under WEB-INF/lib. As for Tomcat's own logging, Tomcat 6 no longer uses commons-logging, they use the j.u.l. instead. This circumvents a major problem occurring in the Tomcat 5.x series which leaked commons-logging loggers into the web-applications it hosted, preventing their proper garbage collection. Anyway, assuming you can upgrade to Tomcat 6 and can live with jul logging for Tomcat, logging separation for web-applications can be accomplished by embarking slf4j and logback in each of your web-apps. Do you think the above would work for you? Lucas, Casey wrote:

For our web applications deployed within tomcat 5.x we use a custom context selector to allow use of multiple independent logback configurations and implementations. We use logback for tomcat internal logging (via commons logging over slf4j) and application level logging. Each web application and tomcat has it's own logback configuration file, own set of logback related jars and is separately controllable via JMX. We did not put any logback, slf4j, etc. related jars into TOMCAT_HOME/common/lib - instead they are in TOMCAT_HOME/server/lib.

The high level of isolation simplifies our development and deployment practices. In general, we did not want any logging related jar or configuration dependencies between tomcat and the multiple web applications. We accomplished our isolation goals by developing a custom ContextSelector, however if there were different or better options for isolation we would look at those. In other words, we're not set on using a ContextSelector implementation - we just want strict isolation.

I should mention that we potentially don't use ContextSelector in its originally intended manner. We tried the JNDI based ContextSelector that ships with logback, but JNDI is not available when tomcat starts doing internal logging so we had trouble separating tomcat logging from application level logging when using the JNDI ContextSelector. Anyway, our ContextSelector implementation boils down to using a classpath-based resource for logging configuration. We don't really do any dynamic context selection like that of ch.qos.logback...LoggerContextFilter.

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user

Lars Ködderitzsch wrote:

Hello Ceki,

thanks for the heads up on this issue on the mailing list.

Starting off I'd like to mention that for me the most wanted feature is separation of logging from different contexts (e.g. war's, ejb) of of an enterprise application (ear), without needing to resort to classloader stunts, multiple repeated logging configurations etc.

That means that the contexts of an enterprise app should be able to use the same logging implementation (that is placed in the ear classloader) and the same logging configuration, but ultimately the log into different log files. This way it can be truely sorted out, which context logged which message.

To my knowledge such a thing is supported in neither logging implementations. Currently I am running this as a hack on log4j, based on a specialized appender which switches the underlying log file based on some thread local, which in turn is set by a special servlet filter in each web context.

Switching log files can be accomplished by a new appender which can embed and manage appenders based on MDC values.

If your're interested I can elaborate more on the problem, so you can get a better understanding what would actually be needed.

Additional detail would be nice. For example, how are you managing thread local values in the web-app and in ejbs? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

Lars Ködderitzsch wrote:

Hello Ceki,

This sounds like a vialable way, that somehow matches my current log4j based hack. Is this appender already available? I had a quick look at the 0.9.11 sources and didn't find any.

No it is not available.

...

Additional detail would be nice. For example, how are you managing thread local values in the web-app and in ejbs? For web-apps I currently use a servlet filter, which sets a thread special thread local variable to the value of a special context param in the webapp. This matches the MDC approach using servlet filters.

For ejb's this proves a bit more difficult (at least EJB2, havent checke EJB3 so far) since there is no standardized support for custom EJB interceptors. Currently I am using aspectj to weave an aspect around the ejb implementation class - which sets the thread local.

A third use case are workmanager and timer threads (Websphere 6.1), where the aspect aproach also works - here the context setting aspect is applied the work item implementation classes (basically a Runnable implementation).

I see. Thank you for this explanation. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

Hi again, thanks, I'll look into the snapshot, if I find the time. No promise, though. If I remember correctly the JNDIContextSelector didn't work out for me in Websphere 6.1, because the JNDI entries of the web-app/ejb were bound at a later point during application startup. At the time logging was first used during application startup the value wasn't yet bound in the JNDI, therefor the application initialization failed. After that I tried with a custom ContextSelector (based on a thread local), but that did not work out back then because of context selectors being not truely pluggable. I filed a bug report/enhancement request at the time - which you fixed, I believe - but due to lacking time I lost sight of the issue (and logback for that matter). If my memory serves me right, there was also another, more fundamental issue with context selectors. I think it had to do with when the context switching actually occurs, and that is when the reference to the Logger is obtained - and not when actually logging a message. From my experience 99% of all loggers (in own code as well as all third party libs I know) are obtained via this pattern: public class A { private static final Logger logger = LogFactory.getLog(A.class); //don't rememer the correct SLF4j api currently } That means that the context selector is only hit once per loaded class, and not per actuall message logging. And that is the core problem in an enterprise application. Normally you have your utility and framework jars (spring, hibernate, commons-* and many many more) in the ear file, to be shared among the potentially multiple web-apps, ejb-jars of the enterprise app. This means that the framework classes are loaded only once per enterprise application, therefor the logging context at the time of the first load of a framework class wins. After that no more context switching occurs, leading to the undesirable result of logging of shared libraries going only to the winning context. Because of that problem context selectors in an enterprise application as they are now are basically useless. They could become very *useful* if the context switching did not occur during logger creation, but also when actually logging messages through the static logger reference. I don't know if it would be viable to change logback in that regard. I hope I could explain the difficulties of context switching in enterprise apps a bit. To me true context switching capabilities would be the ideal solution, the MultiAppender approach would work somewhat - at the expense of having the same context/log level among multiple web-apps. Best regards, Lars Ceki Gulcu schrieb:

Hello Lars,

You might want to check out logback 0.9.12-SNAPSHOT. It can be downloaded from

http://logback.qos.ch/dist/logback-0.9.12-SNAPSHOT.tar.gz

I have tested logging separation in a Enterprise Application consisting of a stateless session and a web-app under JBoss 5.

In this version of logback, if you set up a env-entry for "logback/context-name" in JNDI, you no longer have to set an additional entry for the configuration file. For example, if "logback/context-name" is set to "MANGO", then the associated configuration file is named logback-MANGO.xml by convention. This makes things a bit easier, especially if you need to configure several EJBs or several web-apps.

The ejb-jar.xml file in my example reads

<?xml version="1.0"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" version="3.0">

<enterprise-beans> <session> <ejb-name>Echo</ejb-name> <env-entry> <description>JNDI logging context for this app</description> <env-entry-name>logback/context-name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>vader</env-entry-value> </env-entry> </session> </enterprise-beans> </ejb-jar>

and web.xml reads

<web-app id="kenobi" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<display-name>kenobi</display-name>

<servlet> <servlet-name>KenobiServlet</servlet-name> <servlet-class>ch.qos.KenobiServlet</servlet-class> </servlet>

<servlet-mapping> <servlet-name>KenobiServlet</servlet-name> <url-pattern>/kenobi/*</url-pattern> </servlet-mapping>

<env-entry> <description>JNDI logging context for this app</description> <env-entry-name>logback/context-name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>star</env-entry-value> </env-entry>

<!-- To refer local EJB's --> <ejb-local-ref> <ejb-ref-name>ejb/Echo</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local-home></local-home> <local>ch.qos.IEcho</local> </ejb-local-ref>

</web-app>

While it was easy to get jndi context selector to work in JBoss, I was not able to make it work under Geronimo. Ironically, because it uses SLF4J internally.

HTH,

Lars Ködderitzsch wrote:

...

Hello Ceki,

thanks for the heads up on this issue on the mailing list.

Starting off I'd like to mention that for me the most wanted feature is separation of logging from different contexts (e.g. war's, ejb) of of an enterprise application (ear), without needing to resort to classloader stunts, multiple repeated logging configurations etc. That means that the contexts of an enterprise app should be able to use the same logging implementation (that is placed in the ear classloader) and the same logging configuration, but ultimately the log into different log files. This way it can be truely sorted out, which context logged which message.

To my knowledge such a thing is supported in neither logging implementations. Currently I am running this as a hack on log4j, based on a specialized appender which switches the underlying log file based on some thread local, which in turn is set by a special servlet filter in each web context.

At the time trying logback I thought that context selectors could achieve that in a better, more standardized and less hacky way. Ultimately I failed at the time and haven't looked back yet at logback.

So back to the question, yes, I would be very much interested in such a feature - be it contexts selectors or something else.

If your're interested I can elaborate more on the problem, so you can get a better understanding what would actually be needed.

Best regards, Lars

Ceki Gulcu schrieb:

...

Hello all,

I am in the process of fixing bugs related to context selectors in logback. However, while sometime ago I thought that context selectors were the wave of the future, I am increasingly skeptical about their usefulness (of context selectors).

If you are using context selectors, could you please explain why?