[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] Commons logging madness

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