Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Commons logging madness
Title: Re: [equinox-dev] Commons logging madness
That unfortunately doesn’t help us with the support of the libraries we have that require commons logging.  

We have resolved the issue, though, and it turns out that the class loading issue of clogging was a red herring.  I’m sure it’s still lurking there, ready to bite me when I least expect it, but this time – at least – it wasn’t to blame.


On 12/22/06 2:16 AM, "Matthew Webster" <matthew_webster@xxxxxxxxxx> wrote:


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


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

Back to the top