[
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
