[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Commons logging madness
|
I'd like to wholeheartedly second the suggestion to minimize manual
logging and use tools like AOP to provide automatic tracing etc.
Until recently I have always been very puzzled by the inane amounts of
energies people spent on Logging APIs, let alone the gigabytes of log
output a simple program can generate. Now when I try to follow the
logging tales from Hal I am no longer puzzled but baffled :-)
BTW, I guess if you use Gatespace's log it probably goes to the OSGi
log which you can query with the Log Reader service. All frameworks
have a tool to see this log.
Less is more ...
Kind regards,
Peter Kriens
MW>
MW> Hal,
MW>
MW> May I suggest you take a look at using the Aspects Equinox
MW> Incubator (http://www.eclipse.org/equinox/incubator/aspects/)? You
MW> can use AspectJ to weave any bundles you like with the logging
MW> implementation of you choice. In fact there are a couple of nice
MW> examples in the demos for the project: tracing all entry/exit with
MW> arguments and logging all catch blocks to record caught exceptions.
MW>
MW> Matthew Webster
MW> AOSD Project
MW> Java Technology Centre, MP146
MW> IBM Hursley Park, Winchester, SO21 2JN, England
MW> Telephone: +44 196 2816139 (external) 246139 (internal)
MW> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
MW> http://w3.hursley.ibm.com/~websterm/
MW>
MW>
MW> Hal Hildebrand <hal.hildebrand@xxxxxxxxxx>
MW> Sent by: equinox-dev-bounces@xxxxxxxxxxx
MW> 21/12/2006 16:51
MW>
MW> Please respond to
MW> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
MW>
MW>
MW> To
MW> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
MW> cc
MW>
MW> Subject
MW> Re: [equinox-dev] Commons logging madness
MW>
MW>
MW>
MW>
MW> Yes, this is precisely what Costin (another member of the Spring/OSGi group)
MW> has done. I've gotten a lot of good suggestions from various people -
MW> sadly, the two mailing lists don't have cross posting. So, I'm slowly
MW> moving through the suggestions and previous work that went on the other side
MW> of the globe while I was asleep...
MW>
MW> Hopefully I'll figure this out...
MW>
MW>
MW> On 12/21/06 8:39 AM, "Simon Kaegi" <simon.kaegi@xxxxxxxxx> wrote:
MW>
>> 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
MW>
MW>
MW> _______________________________________________
MW> equinox-dev mailing list
MW> equinox-dev@xxxxxxxxxxx
MW> https://dev.eclipse.org/mailman/listinfo/equinox-dev
MW>
MW>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
