If you are interested by Java EE development and roadmap you might have read recently that the Cloud feature in Java EE 7 has been delayed. As I’ve already expressed in the Java EE 7 expert group mailing list, I’m happy about this news because I feel standardizing cloud in EE 7 was way too early. But I’m also sad. Sad because we’ve spent a lot of time discussing Cloud, PaaS, multi-tenancy… and not concentrating on other topics. And one topic that I have in mind is logging ! Shouldn’t we standardize a Logging API ?
Few months ago I was struggling (again) with logging configuration in JBoss 7.x. I was so depressed that I wrote to the Java EE 7 expert group : Logs. Should we finally do something ? (you should read it, there are valuable opinions expressed by the members). As a developer I’ve used all the possible logging Java frameworks for the last 12 years and I still struggle with logging in 2012. How many logging frameworks do we have ? Look at the list :
- JUL : the good old java.util.logging API that is included in our JDK. Bad luck, it is there and nobody uses it
- Log4j : widely used, Log4j hasn’t really been updated lately (update : the team is working on a 2.0 version)
- Commons Logging : How many more Apache logging frameworks do you want ?
- SLF4J : if you are not sure which logging API to use, well, use an abstraction (hum, abstraction, we love abstraction)
- Logback : the successor of Log4J (successor ? really ?)
- TinyLog : because all these frameworks are too big, we need to use a tiny one
- And many many many more Java logging frameworks
I’m not a log expert and I’m sure all these frameworks exist for good reasons (I’m trying to be politically correct here), but for god sake, we just need to write logs. I don’t want to do a benchmark of all the logging APIs to make up my mind. I don’t want to have to relearn a new logging framework each time a new version of my application server is out (yes, JBoss 7 uses its own JBoss Logging API). To be honest, instead of all saying “using System.out.println is bad” we should have encouraged it and let Java SE redirect the messages to files (using external configuration). This way our code would be full of System.out.println("message") or System.out.println(WARNING, "message") and we would have avoided all the logging frameworks. Anyway, this is the situation we’re in.
Let’s standardize a logging API
Standardizing too soon is bad… but we’ve been doing logs for more than a decade now. We have a big expertise in logging, we could even take some ideas of other languages. So it’s time to standardize logging. Let’s not do the same mistake as JUL and only standardize an API. Then, we could let all the known frameworks to implement it and fight about better performances or functionalities. Today, logging portability is a nightmare, enough. With a standard API we could also have some tooling and descent log viewers coming on board.
Integrate this logging API in Java EE (and other specs)
If all the Java EE specs (EJB, JPA, JAX-RS, CDI…) use this standard API and impose it to the implementations, we could then easily change the level of logs in a standard way on our applications by using a simple package naming convetion :
[sourcecode]
javax.ejb.level = debug // EJB spec
javax.persistence.level = debug // JPA spec
org.weld.level = debug // CDI implementation (Weld)
my.app.level = debug // My application
[/sourcecode]
And who knows, when modularization arrives we could get rid of java.util.logging and have a new javax.logging module in Java SE (and choose the implementation).
Think to the future
If we had a Logging API 1.0 specification, then, when multi-tenancy comes along, we could have a Logging API 1.1 which handles it (wouldn’t it be nice to have multi-tenant logs with no effort ?). Another idea would be to play with staging. JSF 2.0 introduced staging and it might be spread all over Java EE. If that’s the case, we could simply use default logging : DEBUG for development, WARNING for production… That would simplify configuration.
Do you feel like being a spec lead ?
No, it’s not because I write this blog post that I want to be a spec lead. I’m not the right person, I’ve never implemented a logging framework, I’m just a user of theses APIs. So if you feel you know the topic well, if you know people who could help you by being part of your expert group (if you want, I could even join this expert group), then do it. Entering the JCP is not a piece of cake, you need to do a bit of administration to have your JSR approved, but it’s doable. You would need a bit of time, but it’s doable. Even if you start now I’m not sure there will be enough time to take the Java EE 7 train, but the JCP has some examples of quick JSRs.
regarding log4j. This is actively maintained. The Log4J PMC recently even released log4j-2.0 which is a huge step forward. It allows dynamically switching between TCCL logging and static log config detection for example.
You might ping Ralph Goers for more info.
LieGrue,
strub
I totally agree with this – java logging has been a pain in the arse for a decade and standardisation is way over due. I think though that the problem is that so many third party libs depend upon different logging frameworks that it is going to be difficult.
I think you should not focus so much on standardising an API but instead standardise an SPI (Service Provider Interface):
1/ after all the real issue is to have all logging messages routed to a single system.
2/ adoption by thousands of existing frameworks is not realistic (it will take years, if one agrees to use it of course). However you can have all existing logging frameworks be reimplemented to use the new SPI.
If you mean something along the lines of SLF4J (not Logback or Log4J, it wraps around each of those;-) that is probably exactly what this to be JSR could and should look like.
JUL (java.util.logging) unfortunately tried to reinvent the wheel when Log4J had already gained much more momentum, sounds a bit similar to the whole Jigsaw vs. OSGi drama, but let’s not go there;-/
For future success, any new JSR or Framework has to be least invasive, and open to at least a handful of popular implementations out there. Beside that, I know, there’s room for interesting stuff, kind of like we did in Vienna using NIO and Apache Mina for non-blocking asynchronous logging, I believe we mostly used Log4J, but also wrapped SLF4J around it.
Yes on the one hand side SLF4J goes into this direction but on the other also not. In general I like to the idea of an SPI in a component architecture. But for this topic I think it would need more than an SPI. It’s more a kind of an Adapter or Bridge the framework would have to provide to, so that your code can stay on the API it already uses. But even then I think a new framework should actually provide an API as well as an SPI and a set of adapters or bridges. Since I don’t belief that the current frameworks would deliver one and with that an SPI would be enough. But here I might be wrong.
I know a lot of guys hate the JUL API, but actually do not get the point. So for me with some adoptions the JUL can be the the envisioned API.
But what I even more would like to see is an API targeting the purpose of Audit Log. Since there is really nothing out there and it has also slightly other needs than a logging API for technical purpose. Any thoughts on this points? Others out there who think that it would be useful to have an audit log standard?
Actually logging and audit logging especially is a topics most developer think is annoying and simple. But out of my experience (and I deal since years with the topic in many different projects) it’s an interesting and challenging thing an mostly under estimated.
I agree that setting up logging in the Java world is time consuming. It would serve us well if we could come up with a standard and widely-accepted logging API.
Since it’s so pervasive, logging is very difficult to get right. Thus, I don’t think conjuring a successful logging standard is going to be a walk in the park. Do you know if Oracle/Sun would support this JSR?
The Idea is great! Every time new waste of time by switching between App. Server.
We need a mvc controller type framework before that. Do you know how many people still hate jsf ?
I agree with you. As you can see, so much as still to be done
Great Idea. Keep pushing the problem has to be solved after such a long painful path.
Instead of starting another logging effort, it would not be unreasonable to recognize SLF4J as the de facto standard.
That’s what happened to Hibernate : it was the defacto standard and it’s now called JPA. A standard is just taking the good ideas of existing frameworks (SLF4J is one of them) and going through the JCP process (spec lead, expert group, JSP, reference implementation and TCK). And there are many logging frameworks out there, with many good ideas, it’s just a matter of all agreeing and stopping the logging-api-hell.
Using JUL in apps isn’t that bad. Been there, done that, got the t-shirt and it did fit. Besides, the APIs of all mentioned logging libs are rather similar.
What is bad about JUL is the lack of integration with JEE. So, what’s IMHO missing, is a package like javax.util.logging, which would contain the JEE extensions to java.util.logging akin to JDBC and javax.sql.*.
Maybe it’s hidden in one of the mentioned logging solutions, but I have yet to see a two-level configuration, where I can configure the application-level logging (first level) within the bounds of the app-server configuration (second level). This would yield a clear separation and thereby reduce friction between ops and dev.
SLF4J would be a powerful strawman for a RI to a JSR std – if you dig into logging semantics deeply enough you’ll start to fine that logging levels don’t cut it. SLF4J effectively supports tags as well (if you look at it right) and that I think gives a powerful abstraction that implementers can create.
Putting on my JCP EC hat (Hi there – from the LJC – we have a seat) – this space is ripe for standardisation – as Antonio points out – there are lots of frameworks to draw good experiences from and merge into a std. Just the sort of thing the JCP likes.
While I think SLF4J is a good Logging API I am not in favor of having the container use it. One of the major pain points with the containers is that they use some of the same classes that the applications that run in them want to use. This creates all kinds of headaches that the application developers then have to deal with. For example, with SLF4J in JBoss you will frequently get a warning that there are multiple SLF4J bindings if you include your own logging implementation.
One reason JUL is a pain is simply that it was never updated to support locating the LogManager implementation via a ServiceLoader. A good approach would be to have the container use a standard API with a standard way to let the container provide its own implementation but with the ability to let that implementation be easily replaced. By specifically not using the same method SLF4J uses any potential conflicts should be eliminated.
I agree with Ralph! Also, I use JUL all the time with WebSphere and myBatis and it works great.
HI Antonio,
I am no JEE expert, but my personal concerns with logging frameworks is their total lack of dynamicity: You have to know the details of the underlying implementation to dynamically change at runtime something as simple as the logging level of your applicative messages. From an operational point of view this is clearly an issue. When something gets wrong, you do not want to have to restart your application (or worse its container) to get more verbose messages. And at the same time you do not want to clutter your logs, even if you can have different backends, with debug messages which can be a performance hog.
So slf4j can be a good starting point but I miss a standard way standard of changing programmatically the logs’ verbosity. I hate having to resort to casting some Slf4jLogger to a Log4JLogger to access log levels and appenders.
Of course, I may be wrong or missing something….
Anyway you are right in your call-to-arms.
Unfortunately this hell is still alive in 2016! Look for example in the persistence.xml file for hibernate, eclipselink, openjpa and datanucleus.
All this reminds me of https://xkcd.com/927/