[logback-user] question reg. reading JNDI env entries

Ceki Gülcü ceki at qos.ch
Wed Jun 8 00:15:03 CEST 2011

Thread.currentThread().getContextClassLoader() is the context class 
loader which may be different than the "current" class loader, i.e. the 
class loader which loaded the class currently executing. You can get the 
current class loader by invoking this.getClassLoader() on any object. 
When you say that InsertFromJNDIAction instance and your servlet and 
filters instances have the same class loader, do you mean the same 
context class loader (with respect to the currently executing thread) or 
the class loader of the instances themselves?

Also note that the context class loader for the current thread is set 
some time during the initialization of your web-app by Tomcat by calling 
the setContextClassLoader method on the current thread. I am beginning 
to suspect that logback is being initialized before Tomcat has a chance 
to invoke setContextClassLoader. Is that plausible?


On 07/06/2011 12:00 AM, Ravikanth Gangarapu wrote:
> Hi Ceki,
>          I have logback-core, classic, janino, commons-compiler jar files located under WEB-INF/lib folder, and the logback.xml is under WEB-INF/classes. In the console, the logback logs appear ahead of the application specific servlet and filter (from web.xml) init method System out statements.
> I have modified the InsertFromJNDIAction class to print its classloader and did the same for servlet and filter init methods too. All of them printed the same class loader name.
> So, I added,
> ClassLoader loader = Thread.currentThread().getContextClassLoader();
> System.out.println("InsertFromJNDIAction "+loader.getClass().getName()+" "+loader.hashCode()+" "+loader.toString());
> org.apache.catalina.loader.WebappClassLoader 1024180126 WebappClassLoader
>    delegate: false
>    repositories:
>      /WEB-INF/classes/
> ---------->  Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader at 46c837cd
> The jndi context lookup is successful in servlet and filter init methods to print the env-entry-value. Logback still threw the error for lookup.
> Thanks for your help
> Ravi
> -----Original Message-----
> From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at qos.ch] On Behalf Of Ceki Gülcü
> Sent: Monday, June 06, 2011 5:15 PM
> To: logback users list
> Subject: Re: [logback-user] question reg. reading JNDI env entries
> Hello Ravi,
> This is quite strange because for some name 'n', the JNDI lookup code in
> logback essentially does InitialContext().lookup(n) the same code that
> seems to work for you. Could the discrepency be attributed to
> differences in the class loader for logback and the servlet code which
> is able to correctly read the JNDI entries? Where are the logback
> classes located on your application's class path?
> --
> Ceki
> On 06/06/2011 10:25 PM, Ravikanth Gangarapu wrote:
>> Hi,
>> I am using logback-classic (0.9.28) for a web application running on
>> tomcat 5.5.
>> I am trying to read the JNDI env entry values using the<insertFromJNDI
>> env-entry-name="java:comp/env/stderr-logging" as="stdErrLogging" />  tag
>> in the logback.xml file.
>> I have lots of env entry values that can be read from
>> META-INF/context.xml file. For this specific example, my context.xml
>> file has this.
>> <context>
>> ..
>> <Environment name="stderr-logging" type="java.lang.String" value="true"/>
>> ..
>> But, this insertFromJNDI tags always says the entry value is null or
>> empty. However, Once I am in a servlet code, new
>> InitialContext().lookup("java:comp/env/stderr-logging") retrieves the
>> correct value from context xml file.
>> I looked in the JNDIUtil class from ch.qos.logback.classic.util package
>> and the code throws error saying "javax.naming.NameNotFoundException:
>> Name java:comp is not bound in this Context".
>> Would somebody know how to read the environment entry values from the
>> META-INF/context.xml file ?
>> Thanks for help
>> Ravi

More information about the Logback-user mailing list