[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