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 <david.lloyd_at_redhat.com>
To: Jason T. Greene <jason.greene_at_redhat.com>
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