Question

I’ve made an app init function that I’m using both in Java and GWT applications. I have external logback.xml file that I’m setting the path to the "logback.configurationFile" System property. In pure Java projects, all works as expected, but not in GWT projects.

I’ve implemented my ServletContextListener and in method contextInitialized I’m setting the System property. Logback does not read it, but falls back to basic (red letters in console).

So, I tried to follow instructions from logback configuration

LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();

to reconfigure Logback, but that throws

java.lang.ClassCastException: org.slf4j.impl.SimpleLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext

I also tried to put logback.xml in folders: src, war, war/WEB_INF, but it doesn’t read it.

I’m switching to slf4j because previous log4j started to throw many "class not found" exceptions (something with commons-logging)

The question is:

1. What is wrong?

   or

2. How can I get sfl4j (logback) to read the external configuration XML file?

   or

3. How can I get sfl4j (logback) to read any configuration XML file?

Help appreciated

EDIT: Tried to use log4j adapter with slf4j, and it doesn’t work either.

EDIT2: I reverted back to pure log4j that didn’t work before. However, I added log4j.jar directly in "Installed JRE" in Eclipse in the main system JRE and now the pure log4j works. What seems to me is that there is quite a difference between the OpenJDK and the Sun’s JDK, and that is causing problems. I’ll try to fix this slf4j issue in a few days. Maybe there is also a need for some jar on some weird place.

EDIT3: slf4j now works with log4j, but I have to manually configure it. Doesn’t matter where I put log4j.xml, it doesn’t read it. Looks like classloader problem with Sun’s JDK. I’ll try with Logback soon. It might be similar problem.

Answer 1

There are a number of possible configurations with jetty, slf4j, and logback.
It really depends on what you are trying to accomplish.

1) Having the webapp itself do its own logging to logback.

2) Having a global log at the server level that logs the server events and webapp events to logback.

3) Having a global logback configuration at the server level that creates a log file for the server and individual log files for each webapp.

To accomplish #1, you just have to put the slf4j and logback files in your webapp’s WEB-INF/lib directory and deploy the webapp. (be sure you put the configuration files in the webapps WEB-INF/classes or WEB-INF/ directory)

To accomplish #2 and #3 you need to let jetty know that slf4j and logback should be exposed to all webapps, and that all webapps, regardless of the existence of their own (potential) slf4j and logback jars, they are to always use the jar files from the server.
This is done by manipulating the WebAppContext’s list of systemClasses and serverClasses via the default web
Slf4j is permitted through the webapp classloader barrier on Jetty, but logback is not.

This can be defined statically in the context/*.xml deployable, or dynamically via a DeploymentManager binding. see the jetty-webapp-logging module on jetty.codehaus.org for details on how to accomplish this (I would link you do this, but codehaus is undergoing a server migration ATM)
So, i gist’d the relevant file here – https://gist.github.com/1409147

package org.mortbay.jetty.webapp.logging;

import org.eclipse.jetty.deploy.App;
import org.eclipse.jetty.deploy.AppLifeCycle;
import org.eclipse.jetty.deploy.graph.Node;
import org.eclipse.jetty.server.handler.ContextHandler;
import org.eclipse.jetty.webapp.WebAppContext;

public class CentralizedWebAppLoggingBinding implements AppLifeCycle.Binding
{
    @Override
    public String[] getBindingTargets()
    {
        return new String[]
        { "deploying" };
    }

    @Override
    public void processBinding(Node node, App app) throws Exception
    {
        ContextHandler handler = app.getContextHandler();
        if (handler == null)
        {
            throw new NullPointerException("No Handler created for App: " + app);
        }

        if (handler instanceof WebAppContext)
        {
            WebAppContext webapp = (WebAppContext)handler;
            webapp.addSystemClass("org.apache.log4j.");
            webapp.addSystemClass("org.slf4j.");
            webapp.addSystemClass("org.apache.commons.logging.");
        }
    }
}

To accomplish #3 you’ll need to setup a slf4j MDC handler and sift logging in logback that uses the MDC information to route the appropriate logging event to the logfile of your choice.
I blogged about this at http://webtide.intalio.com/2011/08/sifting-logs-in-jetty-with-logback/ and have example projects for basic logback, sifted logback, and even how to use the logback-access module for NCSA access logging at https://github.com/jetty-project/jetty-and-logback-example