[javaee-spec users] [jsr342-experts] Re: Logs. Should we finally do something ?

From: Antonio Goncalves <>
Date: Fri, 9 Mar 2012 20:42:46 +0100

@Jason, for the off topic about JBoss 7.1, it's a known issue that can be
solved ( so no
worries and it looks like JBoss 7.2 will fix it.

For the javax.logging API, that would be awsome. Logging is not my area of
expertise nor I have a glimpse of time to start or be part of a JSR, but
gosh, that would be just awsome. And if all the logging framework creators
could sit around this JSR table, define just an API (a few pages long JSR,
not much) and if all the Java EE spec could follow it, the world of
auditing would be a better place. Lots of "if' in my sentence but.

@Markus, you are right about multitenancy. Another area where logs could

Antonio (just dreaming)

On Fri, Mar 9, 2012 at 18:58, Jason T. Greene <>wrote:

> On 3/9/12 8:43 AM, Antonio Goncalves wrote:
> - snip -
> Logging frameworks have been a battle since day one and it's one of
>> the things that make me feel the Java ecosystem is too complex and is
>> slowly fading from developers/ops concerns. Gosh, I just want to
>> display some logs, why do I have to choose from 10 different
>> frameworks and why should I battle with app server configuration.
>> Isn't it the role of the Java EE spec to make the other spec agree to
>> a standard ? And what about logging ?
> Hi Antonio,
> First, I just wanted to mention that I'd be happy to have an offline
> conversation with you about JBoss AS 7.1 logging, your application
> use-case, and anything we can do to improve your experience.
> Now back to the question at hand, every developer I know (myself
> included) agrees that this is a major pain point for Java EE
> development. It really can become a portability nightmare.
> I started to type up a detailed reply about my thoughts on how we should
> address this when one of my colleagues asked me to forward his feedback.
> Everything he said is entirely consistent with my thoughts yet better
> expressed. So I will simply include his response below and indicate that we
> (Red Hat) are in favor of improved standardization work in this area.
> -------- Original Message --------
> Subject: Re: [jsr342-experts] Logs. Should we finally do something ?
> Date: Fri, 09 Mar 2012 11:05:00 -0600
> From: David M. Lloyd <>
> To: Jason T. Greene <>
> Could you forward my feedback?
> There are two key aspects of logging in any Java application: the
> logging API and the logging backend (or implementation).
> There are tons of log APIs out there - java.util.logging, Apache's
> commons-logging, Apache log4j's API, SLF4J, and our own JBoss Logging
> are among the most popular. Application developers typically choose one
> of many log APIs because there is no one single best log API. They all
> have strengths and weaknesses... of course everyone (myself included)
> who has designed a log API naturally thinks theirs is the "best", in the
> end there's no telling what a user is actually going to prefer and why.
> But one common thread exists: whatever API the user chooses, they
> expect that it will *work*. And depending on the appserver, sometimes
> it does, and sometimes it doesn't, for various reasons, but by and large
> this is a very reasonable expectation.
> However, in order to realize the dream of funneling all log APIs through
> a single path, a single logging backend must be chosen. Now here's
> where the *real* trouble starts. There really are only three major
> backend infrastructures available - JUL, log4j, and Logback. All of
> these implementations use radically different configuration
> infrastructure, and every app server seems to have their own take on
> where, when, and how logging should be configured.
> So this brings us around to standardization.
> Could we standardize a log API? Absolutely. Unfortunately
> java.util.logging will probably never really fit the bill as a good
> quality end-user API, between the general clunkiness of the Logger class
> and its methods, the non-standard levels, and general defectiveness of
> the JDK implementation. One imagines we could come up with a
> javax.logging API (*just* an API, not an implementation) that has the
> best superset of features of all the popular frameworks, and if we did
> that job right (specifically, by making the API feature-complete with
> respect to existing solutions, and making the result available to all
> popular SE and EE versions in the wild), I think that the odds are good
> that it would gain a fair amount of acceptance. In the meantime though
> (and for the foreseeable future), all those other log APIs would still
> have to be supported. This would probably not be a short-term win, but
> it might be a long-term win.
> That's the easy part though. Standardizing logging configuration is a
> much taller order. Standardizing the way that the container itself
> configures its logging is likely outside the scope of what Java EE
> should do (at least I don't know of any precedent for that sort of
> thing). But for applications, it would come down to recognizing a
> standard logging deployment descriptor and doing something sensible with
> it. This can get tricky due to conceptual differences in the way that
> logging is configured between the various back ends, but I don't think
> this is insurmountable.
> All of that said, I think that it would be possible and reasonable to
> tackle this problem with the following goals in mind:
> 1. Creation of a standard, full-featured "javax.logging" API, which
> would be a part of EE 7 and also a standalone API which would
> (hopefully) come to be supported by all the major backends.
> 2. Creation of a standard deployment logging configuration descriptor
> format, which would (if present) cause that deployment's logging to be
> configured separately from any central container logging.
> I would be in favor of participating in such an effort. I think this
> puts reasonable brackets on the scope of the problem and is doable in a
> timely manner.
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat

Antonio Goncalves
Software architect and Java Champion
Web site <> |
Blog <> |
LinkedIn<>| Paris
JUG <>