Logging statements in my code, on the server-side, currently go from the SLF4J 1.7.2 API through the slf4j-log4j12 binding, through JBoss 6's log4j logmanager, into JBoss-logging.
I am eliminating my dependency on log4j. Client-side, this means switching to logback. Server-side, I would like to pull out the slf4j-log4j12 binding, but this seems to cause problems. JBoss 6 bundles its own decrepit slf4j API and binding, but they seem to be from around slf4j 1.5.5.
What is my best option from the following alternatives?
I can continue to let server-side logging flow through slf4j-log4j12 binding into jboss-logging. This seems to be best, but I was hoping to throw away the slf4j-log4j12 binding completely as part of getting rid of log4j. Plus, won't that eliminate a lot of the advantages of using a newer edition of SLF4J?
Upgrading slf4j API, slf4j-jboss-logmanager, and/or jboss-logging in JBoss 6 so that I can have log statements flow directly from slf4j 1.7.2 API into jboss-logging. Is this possible? If so, how do I find new versions of these components?
Switching to logback on the server-side, which takes me completely outside of JBoss logging and probably means I have to manage a separate logfile.
can you use slf4j-jboss-logmanager to connect slf4j-api to jboss-logging, as in these two questions from Jan ?
How to 'activate' SLF4J logging in JBoss6 AS
SLF4J logger.debug() does not get logged in JBoss 6
Related
I have implemented a POC and have used slf4j for logging. The zero day vulnerability issue in log4j, did that also impact slf4j logs?
Depends on the underlying implementation of SLF4J.
log4j 1.x is safe with respect to CVE-2021-44228. Thus, if your SLF4J provider/binding is slf4j-log4j12.jar, you are safe regarding CVE-2021-44228.
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
Check this - http://slf4j.org/log4shell.html
It depends. Slf4j is just an api, that can be using behind any of its implementions, being log4j just one. Check which one is using on the back, and if this is log4j and between versions 2.0.0 and 2.15.0 (2.15.0 is the one with the fix, versions 1.x are not affected) you should update it (if it is exposed to users directly or indirectly)
According to Apache, "only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
Also Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this."
So you should be safe, as long as you do not use log4j-core package.
[,1.7.26),[1.8.0-alpha0,1.8.0-beta2) has Vulnerabilities. Please follow the link https://snyk.io/vuln/maven:org.slf4j:slf4j-ext
After upgrading to Cayenne 4 BETA 1, I'm getting lots of logs. How do I turn them off?
For example:
org.apache.cayenne.log.Slf4jJdbcEventLogger logBeginTransaction
org.apache.cayenne.log.Slf4jJdbcEventLogger logCommitTransaction
... etc.
(I believe the methods are different from the previous versions.)
Thanks!
Methods generally are same as in previous version but underlying API used by Cayenne has changed from commons-logging to SLF4J. And JDBC events logger was renamed accordingly.
You can either:
tune log levels by yourself using logging API. How to do this depends on logging back-end of your choice (e.g. logback, log4j or commons-logging) and is out of Cayenne's scope. If you have some configuration for commons-logging you can learn how to keep it here.
or you can completely disable Cayenne JDBC logging, when you are creating ServerRuntime, for example:
ServerRuntime runtime = ServerRuntime.builder()
.addConfig("your_project.xml")
.addModule(binder -> binder.bind(JdbcEventLogger.class).to(NoopJdbcEventLogger.class))
.build();
We use slf4j + logback, and happened to have some third-party libraries which use commons-logging. How do I set it up to use logback?
The answer is to not use commons-logging.jar, since SLF4J was designed to do what commons-logging does but better. As #MahdeTo refers to, you need to use jcl-over-slf4j.jar.
Check out the documentation from the slf4j website on migrating from commons-logging.
I come across this question too, and found out jcl-over-slf4j.jar indeed can solve the problem, I couldn't understand that why commons-logging couldn't use logback automatically, since commons-logging is log interface and logback is implementation, they should integrate automatically, until I found this:
The Apache Commons Logging (JCL) provides a Log interface that is
intended to be both light-weight and an independent abstraction of
other logging toolkits. It provides the middleware/tooling developer
with a simple logging abstraction, that allows the user (application
developer) to plug in a specific logging implementation.
JCL provides thin-wrapper Log implementations for other logging tools,
including Log4J, Avalon LogKit (the Avalon Framework's logging
infrastructure), JDK 1.4, and an implementation of JDK 1.4 logging
APIs (JSR-47) for pre-1.4 systems. The interface maps closely to Log4J
and LogKit.
Obviously not all the log interface can integrate nicely with log implementation which mean, if you really want to use logback, jcl-over-slf4j.jar is your only solution now because JCL only support Log4J, Logkit, JDK 1.4.
Just add jcl-over-slf4j to the dependencies of your project (check current version at https://search.maven.org/search?q=g:org.slf4j%20AND%20a:jcl-over-slf4j&core=gav)
for those all who wants to keep the final package size smaller; checkout
mvn dependency:tree result of your project and if any dependency to commons-logging exists, exclude them as well. Since the jcl-over-slf4j.jar contains both Log and LogFactory classes with exact same package structure, these commons-logging jars will be extra on your final package.
I've noticed that many of the redhat/jboss frameworks have started migrating to jboss-logging where they've previously used SLF4J, for example hibernate 4.0. Jboss-logging can delegate to SLF4J
What are the advantages of using jboss-logging over e.g. SLF4J with Logback?
Technically, none. I suspect the move is mostly a political one.
JBossLlogging is itself just an API much like SLF4J, and therefore just delegates to an actual logging implementation. By using their own abstraction, the insulate themselves from changes to the SLF4J API (which has already shown itself to be non-backwards-compatible across versions).
Whether or not this is a good idea is debatable.
I have an existing application which does all of its logging against log4j. We use a number of other libraries that either also use log4j, or log against Commons Logging, which ends up using log4j under the covers in our environment. One of our dependencies even logs against slf4j, which also works fine since it eventually delegates to log4j as well.
Now, I'd like to add ehcache to this application for some caching needs. Previous versions of ehcache used commons-logging, which would have worked perfectly in this scenario, but as of version 1.6-beta1 they have removed the dependency on commons-logging and replaced it with java.util.logging instead.
Not really being familiar with the built-in JDK logging available with java.util.logging, is there an easy way to have any log messages sent to JUL logged against log4j, so I can use my existing configuration and set up for any logging coming from ehcache?
Looking at the javadocs for JUL, it looks like I could set up a bunch of environment variables to change which LogManager implementation is used, and perhaps use that to wrap log4j Loggers in the JUL Logger class. Is this the correct approach?
Kind of ironic that a library's use of built-in JDK logging would cause such a headache when (most of) the rest of the world is using 3rd party libraries instead.
One approach I have used successfully is to use slf4j as my primary logging API. I then have slf4j bind to log4j. 3rd party dependencies using other frameworks (like JUL) can be bridged to slf4j.
We use SLF4J on our current project and it's worked very well for us. SLF4J is written by Ceki Gülcü, the creator of Log4J, and he's done a really great job. In our code we use the SLF4J logging APIs directly, and we configure SLF4J so that calls from the Jakarta Commons Logging (JCL), java.util.logging (JUL), and Log4J APIs are all bridged to the SLF4J APIs. We need to do that because like you we use third party (open source) libraries that have chosen different logging APIs.
On the bottom of SLF4J, you configure it to use a particular logger implementation. It comes with an internal, or "simple" logger, and you can override this with Log4J, JUL, or Logback. Configuration is all done simply by dropping in different jar files in your classpath.
Originally, we used the Logback implementation, also written by Ceki Gülcü. This is very powerful. However, we then decided to deploy our application to the Glassfish Java EE application server, whose log viewer expects JUL-formatted messages. So today I switched from Logback to JUL, and in just a few minutes I replaced two Logback jars with an SLF4J jar that connects it to the JUL implementation.
So like #overthink, I would heartily recommend using SLF4J in your setup.
There is a simpler alternative than SLF4J to bridge JUL with log4j, see http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
You just have to put the jul-log4j-bridge on the classpath and add a system property:
-Djava.util.logging.manager=org.apache.logging.julbridge.JULBridgeLogManager
jul-log4j-bridge is not in Maven Central and can be fetched from this repository:
<repository>
<id>psmith</id>
<url>http://people.apache.org/~psmith/logging.apache.org/repo</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
and then used with:
<dependency>
<groupId>org.apache.logging</groupId>
<artifactId>apache-jul-log4j-bridge</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>apache-log4j-component</artifactId>
</exclusion>
</exclusions>
</dependency>
It's also possible to rebuild it from sources with the following steps:
svn co http://svn.apache.org/repos/asf/logging/sandbox/jul-to-log4j-bridge/
edit pom.xml, replace the dependency on log4j:log4j:1.2.15 with log4j:apache-log4j-extras:1.2.17 and remove the dependency on apache-log4j-component
mvn package
OCTOBER 2014
Since version 2.1 of log4j exists the component log4j-jul, which allows exactly this. Still, in case you are using log4j 1, it has to be possible to upgrade to log4j2 in order to use this approach.
JDK Logging Adapter
Class LogManager
Migrate from log4j 1.x to log4j 2
The slf4j site I believe has a bridge for passing java.util.logging events via slf4j (and hence to log4j).
Yes, the SLF4J download contains jul-to-slf4j which I believe does just that. It contains a JUL handler to pass records to SLF4J.
#Yishai - Thanks for posting the link to my wiki. The example there redirects JUL to Log4J and I've had it running in a production system for a few years. JBoss 5.x already redirects JUL to Log4J, so I took it out when we upgraded. I have a newer one that redirects to SLF4J, which I use on a few things now. I'll post that when I get a chance.
However, SLF4J already has it:
http://mvnrepository.com/artifact/org.slf4j/jul-to-slf4j
you should manually add blew at startup
SLF4JBridgeHandler.removeHandlersForRootLogger()
SLF4JBridgeHandler.install()
demo -> https://gist.github.com/jiahut/654ecc75a13b0a1d8f3b4d5d2d69dc6d