[javaee-spec users] Re: [jsr366-experts] Standardizing logging

From: Yannick Majoros <>
Date: Thu, 16 Apr 2015 20:07:13 +0000

> @Yannick If JUL is being used and you think it's sufficient, then why so
many Logging frameworks ?

Because JUL sucked some 15 years ago and people kept their alternative?
Same reasons as Spring, I guess, but I still think specifications matter. I
guess those frameworks don't exist because of the hypothetical speed gain
for the 0.2% max you should spend in logging. I guess it isn't for the
quasi similar, boring features, nor the memory leaks most of those
frameworks introduce.

I didn't say it's sufficient, though. But I think a basic spec with any RI
would really be a blessing.

On Thu, Apr 16, 2015 at 7:28 AM, Yannick Majoros <>

Hi all,

This looks like Hibernate vs Toplink 10 years ago. And yet, it was solved
with JPA.

I'm convinced that an API that would be based on most common features
(probably not all), with extension points, could be quite successful. It
wouldn't add any feature, the goal is just to standardize (further than
JUL) all those logging frameworks. It's been tried before (see various
logging facades), but without any standardization authority. This matters

It could be integrated with Java EE: CDI, bean validation, ... Maybe some
requirements for asynchronous operations too. Class loading restrictions to
have some common guarantees against memory leaks.

Some people would probably still use specific features, occasionally or
exclusively, but they have a migration path. Anyway, changing logging
implementation would be easy for applications that are coded to the
standard. Others would have a simple migration path to it.

Just my two cents as a random Java EE user...

Yannick Majoros

Le 15-04-15 23:34, David M. Lloyd a écrit :

 In WildFly and JBoss EAP, we have a (fairly complex) system which uses our
own log manager based on JUL and also has special API stubs for log4j,
log4j2, slf4j, and Apache commons-logging, which means that logging for all
these systems all get merged into one output that supports most features of
all the frameworks and APIs. But that doesn't mean it's a good thing: this
solution took an inordinate amount of effort to accomplish, and definitely
isn't practical for your average standalone application which maybe pulls
in libraries using three or four differnt and possibly incompatible logging
systems. I'd love to see some sensible API to replace all the logging
APIs, but there are the two primary practical difficulties:

1. Nobody will ever agree what the "right" logging API would look like
(this is why we have so many of them: slf4j, jcl/Apache cl, log4j, log4j2,
JUL, and our own JBoss Logging API).
2. Nobody will ever agree what the "right" logging backend configuration
capabilities would be (this is why we have so many of them: logback, log4j,
log4j2, JUL, and our own JBoss Log Manager).

Even if these two problems would be solved, you'd really have to get buy-in
from all the primary logging backends (logback, log4j, log4j2, and of
course JUL) if you really want it to be successful, which is a difficult
proposition. The effects could end up making the problem worse: existing
logging facades would start shipping backends to the new API, which in turn
would forward to the API for the chosen backend, adding yet more layers to
an already overly-complex situation.

It's hard to see a clear plan that starts with "let's create a new log API"
and actually ends up with any kind of standardization on that API, at least
in under 5+ years time, given the sheer quantity of legacy code using all
the other existing and popular log APIs - even assuming that the API
satisfied everyone, which it definitely won't, because with logging there's
always people with oddball use cases that exploit specific behaviors of
specific frameworks. If someone has such a plan, then let's hear it.

On 04/15/2015 10:46 AM, Mark Struberg wrote:

 You can use JUL as ‚interface‘ and delegate to e.g. log4j2 internally.
That way you can still use MDC, async appenders and all other neat stuff
but you only have an interface where you have a guarantee for not getting
into class clash troubles. This is not the case with slf4j. There have been
binary incopatible changes between I think it was 1.5 and 1.6 which now
create ugly clashes…

There is surely no need to have yet another logging framework in EE…


  Am 15.04.2015 um 14:50 schrieb Steve Hostettler <>:


Just a short note to confirm that JUL is used in production. We use
WebSphere that comes with JUL integration. It is not that bad, as the WAS
integration provides UI for changing log level at runtime. Nevertheless, we
move now to logback + slf4j because of the implementation (performances,
limited customization, no context information). Sure, the API could be
improved but in my opinion it is not the biggest problem.


On Apr 15, 2015, at 14:22, Yannick Majoros <>

  Hi all,

Who says nobody uses JUL in production? I do use it for sure ;-) It's what
provided with Glassfish and other AS, and I wouldn't want to use any of the
"clogging" tools that break my classloader isolation and introduce memory
leaks with no added value.

But yes, I'm convinced that a logging specification would ease things out.
It would just specify some logging interfaces (as other logging abstraction
framework tried to do, with no authoritative standard). It could also
provide clues of acceptable / required class loading practices, e.g. in a
Java EE environment.

It could also be the right time to improve the APIs. Maybe some common
expected logging facilities, too.

Le mer. 15 avr. 2015 à 14:17, Antonio Goncalves <>
a écrit :
Because nobody uses JUL, the Java EE specs can't use it to define standard
loggers. JUL is broken, yes, the JDK folks will fix it (not sure), but in
the meantime the JPA spec can't say "to inscrease the JPA logs, just do


On Wed, Apr 15, 2015 at 12:29 PM, Marek Potociar <>
I agree that creating new logging spec will not solve any problems with
people not using JUL. IMO, JDK folks should find out why people shy away
from JUL and then try to fix it.


   On 15 Apr 2015, at 09:18, Romain Manni-Bucau <>

Well, deprecation part doesnt affect the main topic IMO.

Having a standard will not solve the logging aggregation if it is not in
the JVM (ie if done at EE level). Just check how EE sub spec are accepted
or not. They are often integrated but not the default - for good or bad

The fact there are so much logging frameworks on github doesn't mean a spec
would solve it. These projects are sometimes the same (thanks git
modularization) and moreover it mixes API and implementation - thing a spec
can't change since it would provide API mainly.

My main question is what do you miss or what don't you like in JUL. While
you say a standard it doesn't help to go further IMO. Creating a spec or
"fixing" JUL is not the same pain at all and I really think JUL is not that
far from being usable (in particular since java 8) + it is the standard
since it is in the JVM.

Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber

2015-04-15 9:04 GMT+02:00 Antonio Goncalves <>:
Yes, that's why I wrote *bits* of JUL will get deprecated (so
modularization will be possible).

We write more logs than servlets, we write more logs than restservices, we
write more logs than entities... We then aggregate frameworks that use
different logging frameworks, we configure them differently, it is a pain
to manage... but let's face it, there is no money to be made out of
standardizing logs. If you read my first email, you'll undersant that 6 of
the top 20 git hub projects are related to logging. So no, there is no
standard nor defacto standard !


On Tue, Apr 14, 2015 at 9:42 PM, Romain Manni-Bucau <>

2015-04-14 21:23 GMT+02:00 Antonio Goncalves <antonio.goncalves
<> <>>:
Gosh, we've talked about it so many times that it's becoming painful : no
body uses JUL in a production environment. Full stop. So, let's do
something else. The good thing is that it looks like bits of JULs will get
deprecated [1] so it will be easier to get rid of it when modularization.

That is a wrong free assumption...and moreover not a reason to create
another *API*.

Side note: JUL will not get deprecated reading your link, just part
property listener part


[1] http:// <>
<>/ <>jeps
<>/162 <>

On Tue, Apr 14, 2015 at 9:18 PM, Romain Manni-Bucau <>
@Antonio: can you point out what you want to standardize? Seems
java.util.logging is here and already standard. Only missing thing from my
point of view is "application" configuration but not sure it does worth a
JSR, do yuo have something else in mind?

Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber

2015-04-14 20:00 GMT+02:00 Antonio Goncalves <>:
Hi all,

I've mentioned standardizing logging so many time [1], that I'll make it
short this time (BTW, on a day to day basis, as a developper, I still
struggle with logs).

But this time I saw this blog, so I couldn't stop from thinking about it :
On the top 20 Java GitHub projects, 6 are related to logging [2] I know
logging wasn't in the top priorities of the Java EE 8 survey, but I think
it's also our duty to acknowledge that, if so many logging framework
exists, then, there is a demand.


[1] http://
[2] http://

Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <> | Twitter
<> | LinkedIn <> |
<> | Paris
JUG <> | Devoxx <> France