Class of appender should be logback.eclipseappender.EclipseAppender N On Tue, Jul 13, 2010 at 11:20 AM, Frank Grimm <grimmfrank@googlemail.com>wrote:

Dear mailing list,

I'm trying to use logback (via its slf4j API) in an Eclipe/OSGi environment. More specifically I'm trying to write a logback appender that redirects log events to the Eclipse logging mechanism (org.eclipse.core.runtime.ILog).

So the first thing I did was to create an Eclipse plugin/PDE project for the custom appender. In the project, the following class was added:

package logback.eclipseappender;

import ch.qos.logback.core.AppenderBase;

public class EclipseAppender extends AppenderBase<Object> { @Override protected void append(Object eventObject) { // TODO } }

The a logback configuration that made use of the custom appender was added to the project, too:

<configuration> <appender name="eclipse" class="eclipseappender.EclipseAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d %p %t %c - %m%n</Pattern> </layout> </appender>

<root level="debug"> <appender-ref ref="eclipse"/> </root> </configuration>

When the custom appender plugin/bundle is started in a new Eclipse runtime environment, the appender's class cannot be found (see stacktrace below).

I've read in another post (DynamicClassLoadingException - How does class loading in logback works?) that logback might require the logback jar files and the custom appender jar file to be bundled together. But bundling them does not make sense in OSGi environments since single bundles for each of logback's components (core, classic, slf4j API) and custom appenders should be used.

Is there a way to make logback see the appender class event if it's in another jar/bundle?

Thanks, Frank

11:00:58,210 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [eclipseappender.EclipseAppender] 11:00:58,211 |-ERROR in ch.qos.logback.core.joran.action.AppenderAction - Could not create an Appender of type [eclipseappender.EclipseAppender]. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type eclipseappender.EclipseAppender at ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type eclipseappender.EclipseAppender at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(OptionHelper.java:53)

[...]

Caused by: java.lang.ClassNotFoundException: eclipseappender.EclipseAppender at at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506) at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(OptionHelper.java:45) at ... 52 common frames omitted _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user

Hello Frank, The current class loading strategy is the simplest possible. Logback uses the class loader that loaded logback itself to load appenders (custom or not). More precisely, the class loader that loaded the class of the ch.qos.logback.classic.LoggerContext instance currently being configured is used to instantiate all appenders (custom or not). By "LoggerContext instance currently being configured" I mean the context instance on which the current configuration process is applied upon. See the instantiateByClassName methods on lines 27 through 32 and 35 through 56 in the ch.qos.logback.core.util.OptionHelper class [1]. I suggest that you modify the class loading mechanism in OptionHelper class and possibly in the getClassLoaderOfObject method in the ch.qos.logback.core.util.Loader [2] class to suit the OSGi environment. We can then integrate your changes back into the project. In other words, how would you like to see the EclipseAppender class loaded in OSGi? [1] http://logback.qos.ch/xref/ch/qos/logback/core/util/OptionHelper.html [2] http://logback.qos.ch/xref/ch/qos/logback/core/util/Loader.html On 13.07.2010 11:20, Frank Grimm wrote:

Dear mailing list,

I'm trying to use logback (via its slf4j API) in an Eclipe/OSGi environment. More specifically I'm trying to write a logback appender that redirects log events to the Eclipse logging mechanism (org.eclipse.core.runtime.ILog).

So the first thing I did was to create an Eclipse plugin/PDE project for the custom appender. In the project, the following class was added:

package logback.eclipseappender;

import ch.qos.logback.core.AppenderBase;

public class EclipseAppender extends AppenderBase<Object> { @Override protected void append(Object eventObject) { // TODO } }

The a logback configuration that made use of the custom appender was added to the project, too:

<configuration> <appender name="eclipse" class="eclipseappender.EclipseAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d %p %t %c - %m%n</Pattern> </layout> </appender>

<root level="debug"> <appender-ref ref="eclipse"/> </root> </configuration>

When the custom appender plugin/bundle is started in a new Eclipse runtime environment, the appender's class cannot be found (see stacktrace below).

I've read in another post (DynamicClassLoadingException - How does class loading in logback works?) that logback might require the logback jar files and the custom appender jar file to be bundled together. But bundling them does not make sense in OSGi environments since single bundles for each of logback's components (core, classic, slf4j API) and custom appenders should be used.

Is there a way to make logback see the appender class event if it's in another jar/bundle?

Thanks, Frank

11:00:58,210 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [eclipseappender.EclipseAppender] 11:00:58,211 |-ERROR in ch.qos.logback.core.joran.action.AppenderAction - Could not create an Appender of type [eclipseappender.EclipseAppender]. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type eclipseappender.EclipseAppender at ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type eclipseappender.EclipseAppender at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(OptionHelper.java:53)

[...]

Caused by: java.lang.ClassNotFoundException: eclipseappender.EclipseAppender at at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)

at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)

at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)

at at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)

at at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(OptionHelper.java:45)

at ... 52 common frames omitted