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?