I have configuration the logback with specified custom logback.xml file, but the log it prints is not what I want.
This is my code to initial logback:
private void initLogBack() throws JoranException {
JoranConfigurator configurator = new JoranConfigurator();
configurator.setContext(createLogbackContext());
configurator.doConfigure(mycustomLogbackConf);
}
I think it may read some unexpected "logback.xml" files from somewhere I don't know. Is there any way to print all the configuration information that logback used?
e.g.
The configuration files it uses
The loggers defined
The debug levels defined
Is it possible?
logback 1.0.4 version has a fix with which you can set debug level at jvm level by using a property
-Dlogback.debug=true
Reference: http://jira.qos.ch/browse/LOGBACK-527
Hope it helps.
Related
I'm using log4j and slf4j-log4j12 to print log in my project.
Problem is i don't want to show ebean's log.
I have read Ebean logging config documentation but it's for logback.
I have tried log4j.logger.io.ebeaninternal.server.transaction.JdbcTransaction=INFO. It's not work too.
Does anyone know how to config log4j for ebean to just printout [INFO] level or None
I solved my problem. This is my config for anyone who need it.
# Setup log level for Ebean
log4j.logger.io.ebean.SQL=INFO
log4j.logger.io.ebean.SUM=INFO
log4j.logger.io.ebean.TXN=INFO
log4j.logger.org.avaje.classpath.scanner=INFO
I am using log4j 2.4 and trying to convert log4j2.xml to log4j.properties, however monitorInterval property doesn't seem to be working with log4j2.properties.
status = trace
name=PropertiesConfig
property.filename = logs
appenders = console, file
monitorInterval=10
though log4j2 following documentation
https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
clearly stats that
Properties configuration files support the advertiser,
monitorInterval, name, packages, shutdownHook, status
any changes in property file doesn't leads to reloading of logging configuration. On the contrary, it seems to be perfectly working in xml format
<Configuration status="TRACE" monitorInterval="5">
where whenever I do make any changes in .xml my log4j configuration is picked up and is verified via following log.
2016-06-17 14:43:17,267 Thread-5 DEBUG Reconfiguration started for context 1198108795 (org.apache.logging.log4j.core.LoggerContext#86be70a)
2016-06-17 14:43:17,268 Thread-5 DEBUG Not in a ServletContext environment, thus not loading WebLookup plugin.
2016-06-17 14:43:17,273 Thread-5 DEBUG Initializing configuration XmlConfiguration[location=/Users/userx/Desktop/logs/log4j2_prod.xml]
I also tried to upgrade Log4j version to 2.5 but still observe same behavior.
To add to Ralph's answer, this was fixed in Log4j 2.6. The corresponding ticket is https://issues.apache.org/jira/browse/LOG4J2-1263
Please use Log4j-2.6.1 or later.
This was a bug that has been fixed. I would suggest updating the latest log4j release.
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'm sure this is easy, but I'm failing to find it.
I have a org.apache.commons.logging.Log instance for logging, and I see that the source code of one of my dependencies has statements like:
if (logger.isDebugEnabled())
logger.debug("Doing stuff.");
I would like to enable debugging, so that I could see these messages. I'm using Maven to build, and run tests. I don't particularly care whether the solution is a command-line argument, adding something to pom.xml, or using code to set the logger itself.
In your log4j.properties specify log4j.logger.com.yourpackage=debug. If you don't have a log4j.properties, get a default one (google it) and place it on the root of your classpath.
(commons-logging will delegate to log4j)
org.apache.commons.logging.Log is not a logging framework. It is an abstract interface which helps you to have any concrete logging implementation under it.
There is a good chance that you are using log4j underneath the org.apache.commons.logging.Log api . If that is the case then place a log4j.properties at the root of your classpath. If you already have one then you just need to change the log level as specified in the file .
If you are using any other logger like jdk logger you need to find the logging configuration file for the same.