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.
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.
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)
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.
Related
I am trying to get DropWizard to log to an output file. The file is being created but nothing written to it.
In fact it would appear that the configuration in the provided .yml file is not being used.
I am also getting the following warnings during startup, not sure if they are related:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/conor/.m2/repository/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/conor/.m2/repository/com/conor/project/project-common/0.1-SNAPSHOT/project-common-0.1-SNAPSHOT.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
How can I get dropwizard to pickup the logging config in the yml provided at startup and how can I figure out where the current config is coming from? Thanks.
UPDATE::
I am running DropWizard v0.9.1 and my logging configuration is as follows:
# Logging settings.
logging:
# The default level of all loggers. Can be OFF, ERROR, WARN, INFO, DEBUG, TRACE, or ALL.
level: TRACE
# Logger-specific levels.
loggers:
# Sets the level for 'com.example.app' to DEBUG.
io.dropwizard: INFO
# Redirects SQL logs to a separate file
org.hibernate.SQL:
level: DEBUG
# Logback's Time Based Rolling Policy - archivedLogFilenamePattern: /tmp/application-%d{yyyy-MM-dd}.log.gz
# Logback's Size and Time Based Rolling Policy - archivedLogFilenamePattern: /tmp/application-%d{yyyy-MM-dd}-%i.log.gz
# Logback's Fixed Window Rolling Policy - archivedLogFilenamePattern: /tmp/application-%i.log.gz
appenders:
- type: console
- type: file
threshold: DEBUG
logFormat: "%-6level [%d{HH:mm:ss.SSS}] [%t] %logger{5} - %X{code} %msg %n"
currentLogFilename: output/logs/dropwizard.txt
archivedLogFilenamePattern: output/logs/dropwizard-%d{yyyy-MM-dd}-%i.txt.gz
archivedFileCount: 10
timeZone: UTC
maxFileSize: 10MB
This looks like a typical SLF4J binding issue and is solved easily. First take a look at the relevant section in the URL provided with the warning for an explanation.:
The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present, SLF4J will pick one logging framework/implementation and bind with it. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random. As of version 1.6.6, SLF4J will name the framework/implementation class it is actually bound to.
Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.
Since the binding choice is random, my guess is that the project-common SLF4J dependency is being bound and not the intended one from logback-classic, a transitive dependency of dropwizard. You should either exclude the one in the project-common in your Maven pom file or better yet, if you have access to the code to project-common, remove it from the pom file as the linked-to web page suggests (i.e. "mend their ways").
From the Exception, I think you are using the two different version of logback classic both in class path which arise the conflicts. Try to find out the jar which are included two times but different version and remove one of them. If you are using the Maven to manage the dependency exclude the jar using the tag
<exclusions>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>the version you want to remove</version>
</exclusion>
</exclusions>
I'm trying to figure out why our Hibernate code is not logging anything to log4j. I put together a simple project that calls one Hibernate service method that logs a log4j message as the first line.
Both the project and the Hibernate service have the following log4j specific code:
private static Logger NTEVENT_LOG = Logger.getLogger("NTEVENT");
NTEVENT_LOG.debug("==== LOG4J logging");
When I run the project (Eclipse->run) I get the following messages in red:
log4j:WARN No appenders could be found for logger (org.hibernate.cfg.annotations.Version).
log4j:WARN Please initialize the log4j system properly.
But immediately after I see the logging from the application itself so some part of log4j did get correctly initialized. However, nothing is being logged by the Hibernate service.
[main] DEBUG NTEVENT - ==== LOG4J logging
This is my log4j.xml
<appender name="NTEVENT" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-4r [%t] %-5p %c %x - %m%n"/>
</layout>
</appender>
<root>
<priority value ="debug" />
<appender-ref ref="NTEVENT" />
</root>
I must be missing something that Hibernate is expecting but I have no idea what.
To configure log4j using xml file you need to use DOMConfigurator.configure() method in your main.
Also for this method you need to import org.apache.log4j.xml.DOMConfigurator package.
public static void main(String[] args) {
DOMConfigurator.configure("log4j.xml");
..//your code
..
}
Hope this helps..!!
The problem was as ThrashBean implied, logging for org.hibernate was not enabled. If you want to see Hibernate debugging output, queries for instance, you need:
I finally got what was happening in my case. It might also help those in Netbeans users facing the same problem coz i have lost a lot of hair for quite some months now. My application had just stopped logging to console so i couldnt debug since the errors were not being displayed.
The answer "There are two log4j jar files in you libraries at different location." was true. Initially i had expected to find 2 files with the name log4xxx.jar of course with different version numbers but no file like that at all was there. You see Netbeans comes prepackaged with Hibernate libraries and many other libraries of course. So when developing in hibernate applications in Netbeans you DON'T need to manually add your own Hibernate Jars unless of course you need a specific version etc, you can just add the Hibernate library to your application via that right click project - Properties - Libraries - Add Library button . This will add many hibernate Jars in the background/classpath when running and also on Compiling in the dist/lib folder BUT NOT in the lib of the application. In my case i had added both the Hibernate Library AND also copied the generated hibernate jars from dist/lib to lib. This had happened by mistake as i copied libraries from previous application to include in my new application for use there.
So take home point, if in Netbeans, go to your lib folder, if you see jars like
hibernate-commons-annotations-x.x.x.Final.jar, hibernate-core-x.x.x.Final.jar,hibernate-entitymanager-x.x.x.Final.jar, hibernate-jpa-2.0-api-x.x.x.Final.jar, hibernate-tools-x.x.x.CR1.jar
Remove them and check if error resolves.
I'm using log4j in my WebSphere application. I need to debug class org.springframework.ejb.access.AbstractRemoteSlsbInvokerInterceptor, so I've created logger in my log4j.xml file:
<logger name="org.springframework">
<level value="INFO" />
</logger>
<logger name="org.springframework.ejb.access">
<level value="TRACE" />
</logger>
I've created also commons-logging.properties in src/main/resources of the web project (in maven):
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
However, Spring is NOT logging using log4j. I see no springframework logs in my debug file, but I can see some of them (INFO) in the console. Therefore I assume, the apache commons logging used by Spring is NOT logging using log4j.
Is it possible (and how) to redirect logging used by Spring to Log4j engine under WebSphere?
WebSphere 7.0, Spring 3.1.2, log4j 1.2.6, commons-logging 1.1 provided in shared library.
Try the following:
Consider using slf4j for your logging. Add log4j to your dependencies in maven.
Add jcl-over-slf4j to your maven dependencies. This redirectes each request from jcl to slf4j.
Search for the dependency commons-logging inside your maven dependencies. Exclude it, so it does not get to your deployment archive.
Delete the "commons-logging.properties"-file.
I hope that everythings works out fine now.
This technique to route JCL (including Spring) logging to your log4j configuration still works.
For the apps where we also have slf4j already (the Spring WebFlow ones), that can also be routed to your log4j configuration.
However, if you just want to see the Spring log information, you can increase its level of logging to WebSphere's own logs (SystemOut.log) via the console's Troubleshooting > Logs and Trace > server-name > Change log level details.
Add something like : org.springframework.ejb.access.*=fine (colon is the separator).
I don't know what the exact WAS levels correspond to, but fine, finer, and finest are listed under the "Trace" levels if you expand the Components and Groups area just to see what is available.
(I don't think it matters that your particular Spring package is not listed under there, BTW. I believe it should still successfully control your logging.)
I build a REST web service (using JAX-RS, Spring, Spring JMS, and ActiveMQ). I'm surprised that when I deploy it to Tomcat 5.5.23 I get an exception that JSF jars are required?!
Error configuring application listener of class org.apache.myfaces.webapp.StartupServletContextListener
java.lang.ClassNotFoundException: org.apache.myfaces.webapp.StartupServletContextListener
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3712)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
The web service was working fine until I added log4j functionality in different classes, here's my log4j.properties file (I placed it in WEB-INF/classes):
log4j.rootCategory=INFO, S
log4j.logger.com.dappit.Dapper.parser=ERROR
log4j.logger.org.w3c.tidy=FATAL
#------------------------------------------------------------------------------
#
# The following properties configure the console (stdout) appender.
# See http://logging.apache.org/log4j/docs/api/index.html for details.
#
#------------------------------------------------------------------------------
log4j.appender.S = org.apache.log4j.ConsoleAppender
log4j.appender.S.layout = org.apache.log4j.PatternLayout
log4j.appender.S.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %c{1} [%p] %m%n
Any idea how to resolve this?
I would expect to see this if you have a reference to org.apache.myfaces.webapp.StartupServletContextListener in your web.xml, like:
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
Can you verify that there is no such element?
Sounds like a classloader hierarchy issue. You should enclose log4j in your WAR file, not put it in the shared libraries of Tomcat.
Also, I had some problems with Tomcat 5.5 that was fixed in Tomcat 6.0. You may want to consider upgrading.
Make the following dependencies(if present) in maven as provided:
javax javaee-api 6.0 scope : provided
javax.servlet javax.servlet-api 3.0.1 scope : provided
I downloaded a big framework which I need to built from source. The project uses a maven build structure, and includes a demo application which can be viewed with an embedded jetty. Maven plugins handle all this stuff.
However when I run the demo application (with mvn jetty:run), I can't really use it because for some reason logging on the DEBUG level is turned on and the application spends most of its time logging a lot of statements. Responsiveness is reduced to almost nothing.
The framework (geomajas 1.5.0) seems to use SLF4J, but I can't figure out where it is configured or where it can be turned off.
Any ideas welcome... thanks!
Update:
Apparently they use logback. I found the configuration file (logback.xml), in which I edited out the DEBUG levels and replaced them with ERROR
To make sure the changes would propagate, I cleaned the project and rebuilt it. But the issue remains!
I manually looked at the logback.xml files in the target folder, and they've updated. But I still see the log records!
Update 2
I'm on Windows 7 btw.
The simplest and most straight forward way to disable logging would be indeed to use the NOP binding. To do so, edit geomajas/geomajas-dojo-example/pom.xml and change the logging dependencies into:
<!-- logging dependencies, delegate all to slf4j and use logback -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
<version>1.5.8</version>
</dependency>
And run mvn jetty:run.
looking at this slf4j manual/overview http://www.slf4j.org/manual.html it looks like you could turn off all logging by using the slf4j NOP jar (slf4j-nop-1.5.10.jar). So you'd probably need to find and replace the current slf4j implementation jar in your projects WEB-INF/lib folder with the NOP jar.
Though most likely it's using a log4j implementation, if that's the case you'd need to find the log4j.xml or log4j.properties and edit/remove them. They could be tricky to find though - first look in WEB-INF/classes and then in some sort of config directory would be a good start.
EDIT {
A bit ugly but if you just want to get it up and running as fast as possible you could redirect stdout and stderr to /dev/null which should make it a bit faster as it won't be writing to disk or console:
mvn jetty:run > dev/null 2>&1
}
HTH
Try to find out a log4j configuration (if it is used for logging) - that might be log4j.xml (or log4j.properties) file. If you remove this file from classpath there will be no logging at all. If you want to reduce level of logs try to comment out some logger sections in this file, like e.g.
<!--<logger name="org.hibernate">
<level value="debug"/>
<appender-ref ref="hibernate-file"/>
</logger>-->
For this example there will be no logs for classes from org.hibernate package.
Geomajas uses logback for the sample applications. You can configure the logging using the logback.xml file in src/main/resources.
Switching everything off can be done using a config file like:
<configuration>
<root>
<level value="OFF"/>
</root>
</configuration>
Kind regards,
Joachim