Re: [equinox-dev] Commons logging madness

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Hal,

May I suggest you take a look at using
the Aspects Equinox Incubator (http://www.eclipse.org/equinox/incubator/aspects/)?
You can use AspectJ to weave any bundles you like with the logging implementation
of you choice. In fact there are a couple of nice examples in the demos
for the project: tracing all entry/exit with arguments and logging all
catch blocks to record caught exceptions. 

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal) 
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

Hal Hildebrand <hal.hildebrand@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

21/12/2006 16:51

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Commons logging madness

Yes, this is precisely what Costin (another member
of the Spring/OSGi group)
has done.  I've gotten a lot of good suggestions from various people
-
sadly, the two mailing lists don't have cross posting.  So, I'm slowly
moving through the suggestions and previous work that went on the other
side
of the globe while I was asleep...

Hopefully I'll figure this out...


On 12/21/06 8:39 AM, "Simon Kaegi" <simon.kaegi@xxxxxxxxx>
wrote:

> Hi Hal,
> 
> If you're really stuck with using the JCL API you might take a look
at
> creating a bundle containing jcl104-over-slf4j and then statically
binding
> the implementation to log4j or whatever.
> I've run into similar problems in the past where I simply can't alter
> logging code and can confirm this works as it sidesteps the JCL discovery
> process and less intrusive.
> 
> HTH
> -Simon 
> 
>> -----Original Message-----
>> From: equinox-dev-bounces@xxxxxxxxxxx
>> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Hal Hildebrand
>> Sent: Thursday, December 21, 2006 10:42 AM
>> To: Equinox development mailing list
>> Subject: Re: [equinox-dev] Commons logging madness
>> 
>> Bitter is a good word ;)
>> 
>> Yea, I'm pretty much stuck with JCL as that's what Spring
>> uses and I'm desperately trying to figure out why the latest
>> change to the Spring/OSGi is making every bit of functional
>> testing I have silently fail.  So, I'm looking at a holiday
>> debugging fest with my eyes gouged out.
>> 
>> Thanks, though, for all the suggestions...
>> 
>> 
>> On 12/21/06 3:40 AM, "Neil Bartlett" <njbartlett@xxxxxxxxx>
wrote:
>> 
>>> Hal,
>>> 
>>> Jakarta Commons Logging (JCL) tries to be clever about
>> classloading. 
>>> In the words of Spinal Tap "there is a fine line between
>> clever and stupid".
>>> 
>>> JCL makes a number of old-fashioned assumptions about class
>> loading in 
>>> order to dynamically discover a logging library to use. Heaven
only
>>> knows why this can't be done with static linking or runtime
>> configuration.
>>> Anyway those class loading assumptions are hairy in application
>>> servers and plain wrong in OSGi. Its use should be heavily
>> discouraged.
>>> 
>>> SLF4J does provide a statically linked drop-in replacement
for JCL,
>>> but frankly it would be much nicer if Spring factored out
its
>>> dependency on the JCL API.
>>> 
>>> - Neil
>>> 
>>> PS: if I sound bitter, I am. I lost days to debugging these
>> problems. 
>>> I shudder to think of the total worldwide productivity that
>> has been 
>>> destroyed by JCL.
>>> 
>>> 
>>> 
>>>> Cross posting this on the equinox dev and Spring/OSGi
lists.
>>>> 
>>>> I'm desperately trying to get logging to work in the Spring/OSGi
>>>> testing environment as I simply have no hair left - having
>> pulled it 
>>>> out from frustration.  Those who know me will understand
>> that this is 
>>>> a lot of hair.
>>>> 
>>>> So, in desperation, I finally turned on the commons logging
>>>> diagnostic information so I can see something - anything
-
>> that will 
>>>> tell me what the heck is going on.  Attached is the
trace running
>>>> under Equinox 3.2.1 and from running under Knopflerfish
2.0.1.
>>>> 
>>>> The same loaded bundle configuration is used for both
>> runs.  In the 
>>>> KF case, the log4J implementation is discovered and used
>> as expected.  
>>>> In the Equinox case, the Log4J configuration fails because
>> of  which 
>>>> results in commons logging using the JDK logging implementation.
>>>> 
>>>> The problem appears to be multiple versions of
>>>> org.apache.commons.logging.Log which causes ­ as one might
>> expect ­ a 
>>>> class mismatch problem.
>>>> 
>>>> In both the KF and Equinox case, I have set the OSGi
>> System property 
>>>> ³org.osgi.framework.bootdelegation² to
>>>> ³javax.*,org.w3c.*,sun.*,org.xml.*,com.sun.*².  So,
I¹m not sure
>>>> what¹s happening.  I¹m stumped as to what¹s going
on.
>>>> 
>>>> Below are the relevant sections of trace output in the
>> Equinox case 
>>>> (there¹s a lot of output, sorry).
>>>> 
>>>> Any help would be appreciated in tracking this down...
>>>> 
>>>> 
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> [WARNING]
>>>> the context classloader is not part of a parent-child
relationship
>>>> with the classloader that loaded LogFactoryImpl.
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Trying to load 'org.apache.commons.logging.impl.Log4JLogger'
from
>>>> classloader
>>>> org.eclipse.core.runtime.internal.adaptor.ContextFinder@667901
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Class 'org.apache.commons.logging.impl.Log4JLogger' was
found at
>>>> 
>> 'jar:file:/Users/hhildebrand/.m2/repository/org/springframework/osgi/
>>>> commons 
>>>> 
>> -logging.osgi/1.1-SNAPSHOT/commons-logging.osgi-1.1-SNAPSHOT.jar!/org
>>>> /apache /commons/logging/impl/Log4JLogger.class'
>>>> [LogFactoryImpl@15479518 from
>>>> 
>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
The
>>>> log adapter 'org.apache.commons.logging.impl.Log4JLogger'
>> is missing 
>>>> dependencies when loaded via classloader
>>>> org.eclipse.core.runtime.internal.adaptor.ContextFinder@667901:
>>>> org/apache/log4j/Category
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Attempting
>>>> to instantiate 'org.apache.commons.logging.impl.Jdk14Logger'
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> [WARNING]
>>>> the context classloader is not part of a parent-child
relationship
>>>> with the classloader that loaded LogFactoryImpl.
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Trying to load 'org.apache.commons.logging.impl.Jdk14Logger'
from
>>>> classloader
>>>> org.eclipse.core.runtime.internal.adaptor.ContextFinder@667901
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Class 'org.apache.commons.logging.impl.Jdk14Logger' was
found at
>>>> 
>> 'jar:file:/Users/hhildebrand/.m2/repository/org/springframework/osgi/
>>>> commons 
>>>> 
>> -logging.osgi/1.1-SNAPSHOT/commons-logging.osgi-1.1-SNAPSHOT.jar!/org
>>>> /apache /commons/logging/impl/Jdk14Logger.class'
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Class 'org.apache.commons.logging.impl.Jdk14Logger' was
found in
>>>> classloader 
>>>> 
>> org.eclipse.core.runtime.internal.adaptor.ContextFinder@667901.
It is
>>>> bound to a Log interface which is not the one loaded from
>> classloader
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881
>>>> [LogFactoryImpl@15479518 from
>>>> 
>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@49998
>> 81] Warning:
>>>> bad log hierarchy. You have more than one version of
>>>> 'org.apache.commons.logging.Log' visible.
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Trying to load 'org.apache.commons.logging.impl.Jdk14Logger'
from
>>>> classloader
>>>> org.apache.maven.surefire.booter.IsolatedClassLoader@14994372
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Class 'org.apache.commons.logging.impl.Jdk14Logger' was
found at
>>>> 
>> 'jar:file:/Users/hhildebrand/.m2/repository/org/springframework/osgi/
>>>> commons 
>>>> 
>> -logging.osgi/1.1-SNAPSHOT/commons-logging.osgi-1.1-SNAPSHOT.jar!/org
>>>> /apache /commons/logging/impl/Jdk14Logger.class'
>>>> [LogFactoryImpl@15479518 from
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881]
>>>> Class 'org.apache.commons.logging.impl.Jdk14Logger' was
found in
>>>> classloader 
>>>> 
>> org.apache.maven.surefire.booter.IsolatedClassLoader@14994372.
It is
>>>> bound to a Log interface which is not the one loaded from
>> classloader
>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@4999881
>>>> [LogFactoryImpl@15479518 from
>>>> 
>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@49998
>> 81] Warning:
>>>> bad log hierarchy. You have more than one version of
>>>> 'org.apache.commons.logging.Log' visible.
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> equinox-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev