I am using JSF 2.0, Spring, Hibernate and I need to implement Log4J for centralized error catching. Can anybody help?
If you want centralized logging and since you are using Spring and Hibernate, things are a bit more complicated than just providing a log4j.properties because Hibernate uses SLF4J as logging facade while Spring uses Jakarta Commons Logging (JCL) as logging facade and they seem to conflict.
My recommendation would be to use SLF4J and for that, you'll need to:
provide slf4j-api.jar (you should actually get this one with Hibernate)
remove commons-logging.jar that comes from Spring
provide jcl-over-slf4j.jar to bridge JCL calls to SLF4J
provide the SLF4J binding for Log4J (slf4j-log4j12.jar) to bridge SLF4J calls to Log4J
provide log4j.jar
See also
Hibernate, Spring and SLF4J Binding
Logging Dependencies in Spring
log4j has absolutely nothing to do with spring, jsf or hibernate.
place log4j.jar in WEB-INF/lib
get a sampel log4j.properties and place in on the root of your classpath
use private static final Logger log = Logger.getLogger(CurrentClass.class);
Related
We have a common service module which uses legacy log4J for logging. We need to use this module as dependency in a new Spring Boot application. In new application we are trying to set up SLF4J-Logback as logging framework which is recommended as Log4J is old however we are observing that the log messages are going to different log files. I think this is happening because our common module uses log4j while we are using logback in new module. Now which approach should we use ? Having log messages in two different files will make it difficult to read and debug issues. Shall i configure log4J and logback to use same file ? Is that safe ? Or we use log4j in new application as well and drop logback ?
I would strongly recommend that you use a logging facade, what you already do with SLF4J.
That means that logback in combination with SLF4J is a perfect choice. Thereby SLF4J severs as a simple facade for various logging frameworks. It allows to redirect log messages from legacy logging frameworks to behave as if they were made to the SLF4J API instead.
Adding the appropriate briding module (log4j-over-slf4j) to your classpath, should be everything you have to do for "installation".
I was using a slf4j-api as an interface in my projects. I was trying to provide this projects as a library, so my customer will have to choose which logging framework they want to use.
I know if no binding jar file is provided in the classpath, then the slf4j will simply use a no-op logger implementation which did nothing.
My question is: is there a way to configure slf4j such that if no binding jar file is provided by customer, slf4j will use java.util.logging as a default logging system. And if customer provides an implementation, say log4j, then it will override the default and change to use log4j as logging system.
I had configured my application to use slf4j with log4j, but some how JBoss logger is being selected over slf4j:
org.jboss.logging [DEBUG] Logging Provider: org.jboss.logging.Log4jLoggerProvider.
My application uses spring and hibernate and as I understand it, hibernate now uses JBoss logger instead of slf4j. Is there away for me to force the use of slf4j? Or better yet, make my logging calls API agnostic? As it stands now, hibernate and spring log correctly, but my application specific logging is ignored since it uses the slf4j API.
UPDATE: Logging related jars (which are managed by maven) include:
slf4j-api-1.6.1
slf4j-parent-1.6.1
slf4j-simple-1.6.1
slf4j-log4j12-1.6.1
jboss-logging-3.1.0.CR2
log4j-1.2.12
Thanks.
You have too many logging implementations in your classpath.
Apparently Hibernate uses SLF4J: documentation
So you should remove the following jars:
slf4j-simple-1.6.1 (it conflicts with slf4j-log4j)
jboss-logging-3.1.0.CR2
I'm not so sure what slf4j-parent-1.6.1 is, you can try with and without it.
How to teach Mojarra to use slf4j or log4j?
According to slf4j documentation I have to call:
org.slf4j.bridge.SLF4JBridgeHandler.install();
Somewhere in my project. But I can't call it in Mojarra... So, the question is when and how shall I execute this install() method?
The best way to do it is through a custom Listener. Being initialized before JSF servlet it should configure jul-to-slf4j bridge in contextInitialized(ServletContextEvent).
I believe Mojarra, being Sun code, uses java.util.logging.
The slf4j project download contains a drop-in module which forwards all j.u.l statements to slf4j. You can then use log4j as the slf4j backend.
How can I configure Spring Roo to replace Log4j with SLF4J and Logback as the default logging libraries?
This JIRA issue would seem to suggest that this is not yet possible.