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();
Related
Suppose there is an application, which uses log4j directly, i. e. without slf4j or any other wrapper. Now I would like to replace the log4j with logback. Should I use slf4j (or any other wrapper)? What is considered "good practice"?
You surely should use slf4j API, if you later decide to go back to log4j or something else you will only need to change slf4j bridge, and your application logging code will work without changes. Besides, if you visit http://www.slf4j.org/ you will see that slf4j considers Logback as its native implementation, Logback actually natively implements the SLF4J API.
As mentioned by Evgeniy Dorofeev, logback natively implements the slf4j-api. This means that invocation of a logback logger via the slf4j-api, that is via an instance of org.slf4j.Logger incurs no overhead at all. You could directly invoke loggers of type ch.qos.logback.classic.Logger instead of org.slf4j.Logger but doing so does not provide any advantages but will probably make it harder to migrate to a different logging framework if and when you chose to do so.
By the way, slf4j is not a wrapper for logback as logback is implemented in terms of the slf4j-api.
To ease migration to SLF4J, there is a tool for migrating source code to slf4j. For code which can not be modified by you, there are bridges for log4j, java.util.logging and commons-logging.
You may be able to migrate with no code changes at all, using the log4j-over-slf4j.jar instead of the "real" Log4J one. This provides the same API as Log4J to its clients, but directs the logging calls to SLF4J, which in turn can send them to logback.
But if you have the option of modifying the code then I would recommend changing it to use SLF4J, and you can then swap in any back-end as required (logback, log4j, etc). One thing you must not do is try and combine log4j-over-slf4j with the Log4J backend...
There is one very good reason for using the SLF4J api regardless of actual logging backend, namely the
log.debug("Foo: {}, Bar: {}", foo, bar);
parameter construct. Log4j always need a full string to log, which is why you need surrounding ifs to see if the statement is enabled for an expensive string. SLF4J do not call foo.toString() or bar.toString() before doing the check, so disabled calls are cheap.
Hence I would suggest migrating your source to slf4j and use the appropriate bridge in the slf4j download to use log4j as the backend. This will allow you to continue as you do now, without further changes. You can then switch backend to logback if you need to.
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
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.
Are they alternatives, dependencies, APIs or implementations of each other?
And why do they exist?
Ah, logging frameworks in Java. Your question mixes 2 different types of libraries:
log4j and JDK logging are libraries for handling logging
Commons Logging and SLF4J are logging facades: you still need a real logging implementation (like log4j)
If you are writing a library that will be used in someone else's system, then you should use a logging facade because you do not know which logging framework they will use. In this case use SLF4J (Commons Logging is older and has some classloader issues).
If you control the whole application and can dictate which logging framework to use, you are free to choose your own preference. My preferred solutions are (in order of preference):
Logback
log4j
JDK logging (in my opinion, a case of 'not invented here' by SUN)
I've been looking into this recently too. I've been using Log4J for years with Commons Logging and recently switched to SLF4J.
Log4j
Log4j is a framework for actually doing the log writing/distribution. It's extremely flexible: you can direct it to send log messages to files, syslog, remote monitoring, etc. You can also configure multiple loggers, logging categories, include context in entries, and so on. It's one of the most popular logging systems.
JDK Logging
The built-in JDK logging (which I've never used, to be honest) was added in JDK 1.4.2. From what I gather, it's not very popular because it's not as flexible as Log4j, but I'd welcome comments :).
Commons Logging and SLF4j
Both of these are façades on top of various logging frameworks that present a common interface for your application. For example, you can use CL/SLF4J in your application, and they will automatically detect an underlying logger implementation (Log4J, JDK logging, or a built-in logger that just delegates to System.err.println()). The benefit is that you or your end user can decide to switch out the underlying logging implementation at will, and they greatly simplify your implementation by removing many of the complexities of Log4J and JDK logging.
Most often you will see them layered.
SLF4J is purely an abstraction layer and is not, in itself, used for the actual outputting of logging but used by you in your code to log messages.
A typical setup is to use SLF4J to log in your code, then use log4j as the underlying "output" layer using an appropriate slf4j->log4j bridge (a jar you just include on your classpath). In order to merge logging from different sources, various bridges exist. For instance, many app servers (like tomcat) will use JDK-logging to avoid forcing a "non standard" logging framework on the deployed applications. For that purpose, slf4j has a bridge that will pick up all output from JDK-logging. So, this could be a stack
JDK-logging <- Your app-server or framworks might log using this
|
(JDK->Slf4j bridge)
|
Slf4j <- your application logs using Slf4j
|
(Slf4j->log4j bridge)
|
log4j <- log4j is just responsible for outputting to the appenders you configure (file, console etc)
SLF4J just is a generic API with different back-ends (any other logging system). Log4j and commons-logging (CL) different logging libraries, CL is a fossil. But they all have a fatal flaw, so sun have invented JDK logging.
As for me, I prefer SLF4J as most flexible and logback as a backend for it. Logback is most modern and have a lot nice features.
We are developing a web-based application in Java using the Spring framework. We are wondering which Logging system would be the most appropriate for it, whether Log4j or JUL (java.util.Logging), which is integrated with jdk. As far as I'm concerned, the former is more popular among developers and offers higher customization options, but I'm not sure which is simpler to adapt with spring.
any help will be appreciated.
thanks!
Before you start with log4j, look at logback. Log4j shouldn't be used for new projects anymore. If you have legacy code that needs any logging framework, use slf4j to make the old code talk to logback (or log4j if you must).
The main reasons you should not use JUL is that it implements the bare minimum that you need for logging, the configuration is hard at best and, if you use any component that doesn't use it, you'll have to deal with two logging frameworks.
Regardless of which logging framework you use in your own code, as far as I can remember, Spring has a hard dependency on commons-logging. You can still use whatever you like for your own logging (I'd recommend SLF4J as your facade, with logback as your implementation), but Spring internally needs commons-logging. Whether you want to depend on multiple frameworks is your choice; it shouldn't prove problematic.
Spring uses commons logging, which is a log abstraction facility but has issues that sl4j doesn't have. Hibernate moved to slf4j - I would like to see spring do the same, but I don't think they have any plans in this regard.
So as long as your log abstraction facility (use slf4j) logs to the same logging framework as you've configured commons logging in spring, then you're good. One log configuration for both. You might find an adapter for logback for commons and slf4j.
Since the other responses didn't actually answer your question, I thought I'd have a stab at it.
Firstly, java.util.logging is horrible. It's a pain to use, and a pain to configure. Log4J is nicer on both counts. However, you should pick whichever one you're most comfortable with. Spring uses commons-logging, which in turn will use either log4j (if found on the classpath) or java.util.logging otherwise. In otherwords, if your application already has log4j present, then Spring will effectively use that, and so should you. If log4j is not already present, then either use java.util.logging (if you choose to), or add log4j to your classpath and use that.