[logback-user] Custom appender

[Ceki Gulcu]

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