In our build.gradle:
dependencies {
// Logging
compile "org.slf4j:slf4j-api:$slf4jVersion"
compile "log4j:log4j:$log4jVersion"
compile "org.slf4j:slf4j-log4j12:$slf4jVersion"
....
}
In code we use classes from slf4j library.
Thus it looks like this:
Also we use Spring framework. It uses commons-logging inside. There are no exclusions of commons-logging in our configuration. But I see Spring logs in our log files. And I don't understand how does it work (I see that it works). Is our configuration correct?
P.S.
From my point of view I should add jcl-over-slf4j and exclude commons-logging but I see that now it works correctly.
Is concatenation of circumstances the expected behavior?
I have a project which depends on hadoop-core.
hadoop-core has its own log4j configuration.
The default log4j configuration is loaded in my project.
I want my project not to be affected by it.
How do I solve this?
If you do not want the hadoop-core provided log4j configuration to be the one used by log4j you have to provide another configuration file that should be used.
You should have a look at the log4j manual. The section "Default Initialization Procedure" describes how log4j will try to find the initialization file and explains possibilities to match a special configuration (e.g. by setting the system property log4j.configuration).
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:
What is wrong?
or
How can I get sfl4j (logback) to read the external configuration XML file?
or
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.
I have logback working in my gwt,eclipse, jetty projects. works quite well. Kind of worked out of the box. I am using maven. What I did is:
add slf4j-api and logback as a dependencies.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.4</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.0</version>
</dependency>
in my code I get a logger by using:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
protected Logger log = LoggerFactory.getLogger(this.getClass());
The logback.xml is in my src/main/resources folder. This way it will be placed in target/myproject/WEB-INF/classes after beeing compiled.
Hope this will help you.
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
Logback looks for its configuration files in the classpath, not in the file system.
To get to a configuration file in the file system, use file inclusion as described at http://logback.qos.ch/manual/joran.html#fileInclusion. Note that the filename can refer to an environment variable if it makes it easier to point to the file system location of the file.
I am also faced the same problem, found slf4j-simple.jar in the pom/class path. Once it was removed, working fine.
I created an Eclipse RCP "Hello World"-Plugin, it's running and showing me the main window, then I created a second plugin called "logging" with the logback libraries and added this logging-plugin as a dependency to the main plugin.
The main plugin now knows the logger-classes, and I can use them, but how do I reach the "logback.xml"-file from the main plugin? This file is stored in the "resources"-folder in the logging-plugin.
-mainplugin <---knows logging classes, but not reaching logback.xml
-logging
|-libs
|-resources
|-logback.xml
logback.xml is a configuration file for your logging, the one where you set log level ect. ... right? In this case it belongs to the mainplugin, not to the logging plugin (which would only expose the methods of the jar file in the libs folder).
Like this:
-mainplugin
|-resources
|-logback.xml
-logging
|-libs
In order to work you would have to set buddy policies in your plugins and lockback.xml have to be in the classpath (!). This is required to allow the logging plugin to find the lockback.xml inside your plugin without to have a direct dependency.
in the MANIFEST.MF of the logging plugin you would have to add:
Eclipse-BuddyPolicy: registered
In the MANIFEST.MF of your mainplugin you would have to add:
Eclipse-RegisterBuddy: org.logplugin.id
with org.logplugin.id being the id of your logging plugin.
For more information: http://www.eclipsezone.com/articles/eclipse-vms/
A more introductory, including another two approaches, is described at http://devblog.virtage.com/2012/07/logback-and-eclipse-attaching-logback-xml/.
Specifically, I use spring only for configuring my project through ApplicationContext. In my spring xml I load some bean properties through PropertyPlaceholderConfigurer. Whenever in the dependencies I swap commons-logging-x.x with jcl-slf4j.jar the loading of the context fails with ClassNotFoundExceptions on the placeholder substitutions. Example:
In my spring.xml there is:
<bean id="testbean" class="${testbean.implementingClass}"/>
where testbean.implementingClass is defined in spring.properties:
testbean.implementingClass=my.implementation.TestClass
If I run the project using commons-logging jar all works perfectly. If I change it to jcl-slf4j then I get ClassNotFoundException that the class [${testbean.implementingClass}] was not found, i.e. it does not do the placeholder substituion. Has anyone observed this?
EDIT: My problem doesnt have to do with the jars because:
From http://www.slf4j.org/legacy.html :
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future. You can immediately enjoy the benefits of SLF4J's reliability and preserve backward compatibility at the same time. Just replace commons-logging.jar with jcl-over-slf4j.jar. Subsequently, the selection of the underlying logging framework will be done by SLF4J instead of JCL but without the class loader headaches plaguing JCL. The underlying logging framework can be any of the frameworks supported by SLF4J. Often times, replacing commons-logging.jar with jcl-over-slf4j.jar will immediately and permanently solve class loader issues related to commons logging.
When you use jcl-slf4j, you have to make sure you have excluded all commons-logging dependencies from your project. Make sure there is no commons-logging jar anywhere in the classpath.