[logback-user] Context selectors useful?

[Lars Ködderitzsch]

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