[
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
