You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by ni...@uk.bnpparibas.com on 2005/01/18 20:55:20 UTC

Commons logging woes in Tomcat 5.x


Unless I am missing something, it seems to me that commons-logging-api.jar
is loaded by the JVM AppClassLoader (ie the root classloader)

There are two implications of this:
The first is that tomcat itsself will only ever delegate to JDK1.4 logging
as the commons-logging-api.jar has no log4j delegation classes
The second, more serious, seems be that any web application (and libraries
thereof) using commons logging will use the same commmons logging
configuration as tomcat - and will also only delegate to JDK1.4 logging....

:-(

Is there a way around this that I am missing?
Have I correctly understood the behaviour?


Cheers,
Nick




This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: Commons logging woes in Tomcat 5.x

Posted by Jacob Kjome <ho...@visi.com>.
At 01:44 AM 1/19/2005 +0000, you wrote:
 >
 >
 >Hmm, is that all?
 >I understand the parent-first/last classloading strategies that different
 >appservers have...
 >
 >However, the behaviour I observe is that depending on whether I have
 >*log4j* in the web-inf/lib (or commons-logging.properties in classes) then
 >the commons-logging Log instance I get will have been loaded by completely
 >different classloaders (root vs webapp).
 >
 >No configuration of commons logging - the Log class's classloader is the
 >JVM AppClassLoader
 >If I configure commons-logging successfully to use log4j, then the Log
 >class's classloader is the webapp classloader...
 >
 >Maybe there is some trickery going on in the commons-logging
 >LogFactory.....
 >

I can't argue with you there.  commons-logging is all about classloader 
trickery ("quackery"?).  I guess I thought you were talking about something 
else when I answered before.  This is where the UGLI API, being introduced 
along with the Log4j-1.3 release comes in.  It provides a common logging 
interface to avoid dependency on any particular logging implementation, but 
does so by using jar's with hardwired logging implementations.  For 
instance, ugli-jdk14.jar, ugli-simple.jar (system.out),  ugli-nop.jar (no 
logging), and log4j.jar (Log4j actually implements the UGLI API directly in 
1.3).

When this comes out officially, I highly recommend the move away from 
commons-logging.


Jake

 >-Nick
 >
 >
 >
 >
 >Extranet
 >hoju@visi.com - 18/01/2005 22:54
 >
 >
 >Please respond to tomcat-user@jakarta.apache.org
 >
 >
 >
 >To:    tomcat-user
 >
 >cc:
 >
 >
 >Subject:    Re: Commons logging woes in Tomcat 5.x
 >
 >
 >Quoting nick.minutello@uk.bnpparibas.com:
 >
 >>
 >>
 >> To answer the 2nd part of my own question:
 >> There seems to be some classloading trickery (ie special treatment for
 >> commons logging Log class) if a log4j jar (or a
 >commons-logging.properties)
 >> is found in the web app classpath  (WEB-INF\lib/classes)
 >>
 >
 >It's not really "trickery".  It is child-first classloading behavior
 >defined by
 >the servlet spec.  However, counting on this across platforms is not wise,
 >since other appservers either don't implement child-first behavior or
 >implement
 >it, but specify normal Java2 parent-first behavior as the default.
 >
 >
 >Jake
 >
 >> But part 1 still stands...
 >>
 >>
 >> -Nick
 >>
 >>
 >>
 >>
 >>
 >>
 >> Extranet
 >> Nick MINUTELLO/UK/EUROPE/GROUP@BNPPARIBAS - 18/01/2005 19:55
 >>
 >>
 >> Please respond to tomcat-user@jakarta.apache.org
 >>
 >>
 >>
 >> To:    tomcat-user
 >>
 >> cc:
 >>
 >>
 >> Subject:    Commons logging woes in Tomcat 5.x
 >>
 >>
 >>
 >>
 >> Unless I am missing something, it seems to me that
 >commons-logging-api.jar
 >> is loaded by the JVM AppClassLoader (ie the root classloader)
 >>
 >> There are two implications of this:
 >> The first is that tomcat itsself will only ever delegate to JDK1.4
 >logging
 >> as the commons-logging-api.jar has no log4j delegation classes
 >> The second, more serious, seems be that any web application (and
 >libraries
 >> thereof) using commons logging will use the same commmons logging
 >> configuration as tomcat - and will also only delegate to JDK1.4
 >logging....
 >>
 >> :-(
 >>
 >> Is there a way around this that I am missing?
 >> Have I correctly understood the behaviour?
 >>
 >>
 >> Cheers,
 >> Nick
 >>
 >>
 >>
 >>
 >> This message and any attachments (the "message") is
 >> intended solely for the addressees and is confidential.
 >> If you receive this message in error, please delete it and
 >> immediately notify the sender. Any use not in accord with
 >> its purpose, any dissemination or disclosure, either whole
 >> or partial, is prohibited except formal approval. The internet
 >> can not guarantee the integrity of this message.
 >> BNP PARIBAS (and its subsidiaries) shall (will) not
 >> therefore be liable for the message if modified.
 >>
 >>
 >****************************************************************************
 >******************
 >
 >>
 >>
 >> BNP Paribas Private Bank London Branch is authorised
 >> by CECEI & AMF and is regulated by the Financial Services
 >> Authority for the conduct of its investment business in the
 >> United Kingdom.
 >>
 >> BNP Paribas Securities Services London Branch is authorised
 >> by CECEI & AMF and is regulated by the Financial Services
 >> Authority for the conduct of its investment business in the
 >> United Kingdom.
 >>
 >> BNP Paribas Fund Services UK Limited is authorised and
 >> regulated by the Financial Services Authority.
 >>
 >>
 >> ---------------------------------------------------------------------
 >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
 >> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
 >>
 >>
 >>
 >> ---------------------------------------------------------------------
 >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
 >> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
 >>
 >
 >
 >
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
 >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
 >
 >
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
 >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: Commons logging woes in Tomcat 5.x

Posted by ni...@uk.bnpparibas.com.

Hmm, is that all?
I understand the parent-first/last classloading strategies that different
appservers have...

However, the behaviour I observe is that depending on whether I have
*log4j* in the web-inf/lib (or commons-logging.properties in classes) then
the commons-logging Log instance I get will have been loaded by completely
different classloaders (root vs webapp).

No configuration of commons logging - the Log class's classloader is the
JVM AppClassLoader
If I configure commons-logging successfully to use log4j, then the Log
class's classloader is the webapp classloader...

Maybe there is some trickery going on in the commons-logging
LogFactory.....

-Nick




Extranet
hoju@visi.com - 18/01/2005 22:54


Please respond to tomcat-user@jakarta.apache.org



To:    tomcat-user

cc:


Subject:    Re: Commons logging woes in Tomcat 5.x


Quoting nick.minutello@uk.bnpparibas.com:

>
>
> To answer the 2nd part of my own question:
> There seems to be some classloading trickery (ie special treatment for
> commons logging Log class) if a log4j jar (or a
commons-logging.properties)
> is found in the web app classpath  (WEB-INF\lib/classes)
>

It's not really "trickery".  It is child-first classloading behavior
defined by
the servlet spec.  However, counting on this across platforms is not wise,
since other appservers either don't implement child-first behavior or
implement
it, but specify normal Java2 parent-first behavior as the default.


Jake

> But part 1 still stands...
>
>
> -Nick
>
>
>
>
>
>
> Extranet
> Nick MINUTELLO/UK/EUROPE/GROUP@BNPPARIBAS - 18/01/2005 19:55
>
>
> Please respond to tomcat-user@jakarta.apache.org
>
>
>
> To:    tomcat-user
>
> cc:
>
>
> Subject:    Commons logging woes in Tomcat 5.x
>
>
>
>
> Unless I am missing something, it seems to me that
commons-logging-api.jar
> is loaded by the JVM AppClassLoader (ie the root classloader)
>
> There are two implications of this:
> The first is that tomcat itsself will only ever delegate to JDK1.4
logging
> as the commons-logging-api.jar has no log4j delegation classes
> The second, more serious, seems be that any web application (and
libraries
> thereof) using commons logging will use the same commmons logging
> configuration as tomcat - and will also only delegate to JDK1.4
logging....
>
> :-(
>
> Is there a way around this that I am missing?
> Have I correctly understood the behaviour?
>
>
> Cheers,
> Nick
>
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
>
**********************************************************************************************

>
>
> BNP Paribas Private Bank London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Securities Services London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Fund Services UK Limited is authorised and
> regulated by the Financial Services Authority.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: Commons logging woes in Tomcat 5.x

Posted by Jacob Kjome <ho...@visi.com>.
Quoting nick.minutello@uk.bnpparibas.com:

>
>
> To answer the 2nd part of my own question:
> There seems to be some classloading trickery (ie special treatment for
> commons logging Log class) if a log4j jar (or a commons-logging.properties)
> is found in the web app classpath  (WEB-INF\lib/classes)
>

It's not really "trickery".  It is child-first classloading behavior defined by
the servlet spec.  However, counting on this across platforms is not wise,
since other appservers either don't implement child-first behavior or implement
it, but specify normal Java2 parent-first behavior as the default.


Jake

> But part 1 still stands...
>
>
> -Nick
>
>
>
>
>
>
> Extranet
> Nick MINUTELLO/UK/EUROPE/GROUP@BNPPARIBAS - 18/01/2005 19:55
>
>
> Please respond to tomcat-user@jakarta.apache.org
>
>
>
> To:    tomcat-user
>
> cc:
>
>
> Subject:    Commons logging woes in Tomcat 5.x
>
>
>
>
> Unless I am missing something, it seems to me that commons-logging-api.jar
> is loaded by the JVM AppClassLoader (ie the root classloader)
>
> There are two implications of this:
> The first is that tomcat itsself will only ever delegate to JDK1.4 logging
> as the commons-logging-api.jar has no log4j delegation classes
> The second, more serious, seems be that any web application (and libraries
> thereof) using commons logging will use the same commmons logging
> configuration as tomcat - and will also only delegate to JDK1.4 logging....
>
> :-(
>
> Is there a way around this that I am missing?
> Have I correctly understood the behaviour?
>
>
> Cheers,
> Nick
>
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
>
**********************************************************************************************
>
>
> BNP Paribas Private Bank London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Securities Services London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
>
> BNP Paribas Fund Services UK Limited is authorised and
> regulated by the Financial Services Authority.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Re: Commons logging woes in Tomcat 5.x

Posted by ni...@uk.bnpparibas.com.

To answer the 2nd part of my own question:
There seems to be some classloading trickery (ie special treatment for
commons logging Log class) if a log4j jar (or a commons-logging.properties)
is found in the web app classpath  (WEB-INF\lib/classes)

But part 1 still stands...


-Nick






Extranet
Nick MINUTELLO/UK/EUROPE/GROUP@BNPPARIBAS - 18/01/2005 19:55


Please respond to tomcat-user@jakarta.apache.org



To:    tomcat-user

cc:


Subject:    Commons logging woes in Tomcat 5.x




Unless I am missing something, it seems to me that commons-logging-api.jar
is loaded by the JVM AppClassLoader (ie the root classloader)

There are two implications of this:
The first is that tomcat itsself will only ever delegate to JDK1.4 logging
as the commons-logging-api.jar has no log4j delegation classes
The second, more serious, seems be that any web application (and libraries
thereof) using commons logging will use the same commmons logging
configuration as tomcat - and will also only delegate to JDK1.4 logging....

:-(

Is there a way around this that I am missing?
Have I correctly understood the behaviour?


Cheers,
Nick




This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.

**********************************************************************************************


BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Fund Services UK Limited is authorised and
regulated by the Financial Services Authority.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org