1
votes

I am running a POC to see the impact of migrating our j2ee applications to logback. I spent some time on the official website and apparently, the only change beside new jars was the logback.xml file. Unfortunatly doesn't look to be enough, the deployment works and the log file is created as well, but nothing is logged (empty).

my code has the following statements

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

private static final Logger log = LoggerFactory.getLogger(CustomerServiceBean.class);
log.debug("test Log Back - customer ID  " + input.getCustomerId());

pom.xml has now the following

<dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-classic</artifactId>
   <version>0.9.18</version>
 </dependency>

logback.xml (created using web utility from the official website)

<configuration>
   <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <!--See also http://logback.qos.ch/manual/appenders.html#RollingFileAppender-->
   <File>/var/log/dcs-3/dcs3.log</File>
   <encoder>
     <pattern>%d{ABSOLUTE} %5p %c{1}:%L - %m%n</pattern>
   </encoder>
   <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
     <maxIndex>1</maxIndex>
     <FileNamePattern>/var/log/dcs-3/dcs3.log.%i</FileNamePattern>
   </rollingPolicy>
   <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
     <MaxFileSize>1MB</MaxFileSize>
   </triggeringPolicy>
 </appender>
 <logger name="com.lgi.dcs" level="DEBUG" />
 <root level="debug">
   <appender-ref ref="file"/>
 </root>
</configuration>

any idea? thanks

UPDATE
I made few more changes as suggested. The issue is still open, however I was able to obtain more information.
I logged an ERROR instead of a simple DEBUG. I removed all log4j jars or dependencies from the project and added the log4j-bridge. I changed the logback.xml with one more generic taken from another post and used an appender on the console in addition to the file.

Now in my IDE looks like the Logger instance is implemented by ch.qos.locback.classic.Logger. The log file is still empty, but if I delete it than is recreated during server start-up. On the server log I can now see the my test message like:

SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [zip:/opt/oracle-soa/user_projects/domains/osb/servers/AdminServer/tmp/_WL_user/dcs3-ear-3/9yhkv9/APP-INF/lib/logback-classic-0.9.18.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [zip:/opt/oracle-soa/user_projects/domains/osb/servers/AdminServer/tmp/_WL_user/dcs3-ear-3/9yhkv9/APP-INF/lib/logback-classic-0.9.18.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. 11:40:17.902 [[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR c.l.d.s.customer.CustomerServiceBean - test Log Back - customer ID 6107576

which some how makes me think about the log4j within weblogic perhaps.

3
How does your logback.xml look like?ssindelar
Is logback.xml in the classpath? Does your program finds it when it runs?Marsellus Wallace
I guess yes, because the file is created, but is empty. It's inside the ejb part of an ear, at the same level where log4j used to be.AleIla
however while debugging I see the org.slf4j.impl.Log4jLoggerAdapter for the logger.AleIla
Did you try to log different level than debug? Try to log something on error level and see what will happen. It is not likely to happend, but you could left other logging framework on classpath by mistake. Please doublecheck for log4j, apache-logging, jboss-loggingAntoniossss

3 Answers

0
votes

As you have mentioned above, logger factory returns instance of log4j not logback. That means that you still have log4j on classpath. It could be directly provided and left there by mistake, or it comes as dependency to libraries you are using. If you are using maven, try to investigate EFFECTIVE POM for log4j existatnce, and exclude them. Otherwise you have to do it manually. If you will find that dependency, deleting it should do the trick.

The jar you should look for is probably slf4j bridge log4j-over-slf4j. jcl-over-slf4j could be related too.

0
votes

Log4jLoggerAdapter exists in the SLF4J Log4J wrapper implementation. Most probably you have slf4j-log4j12 in your classpath, so that there are 2 logging backend impl for SLF4J at the same time (LogBack and Log4J Impl)

The other answer is mentioning about log4j-over-slf4j, which is for redirecting calls to Log4J to use SLF4J, and that should exists if you are using LogBack (of course, if you want log4j messages to go through SLF4J)

0
votes

For Java EE applications you break the specification if your application writes to the file system directly (because that breaks on multi-JVM containers).

This essentially rule out in-war/in-ear logging.

Instead consider using the slf4j java.util.logging bridge and let the container capture and manage the logging.