[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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