Forwarding for David...
-------- Original Message --------
Subject: Re: [javaee-spec users] [jsr342-experts] Re: Logs. Should we finally do
something ?
Date: Mon, 10 Sep 2012 19:01:26 -0500
From: David M. Lloyd <david.lloyd_at_redhat.com>
To: jsr342-experts_at_javaee-spec.java.net
CC: bill.shannon_at_oracle.com, "Jason T. Greene" <jason.greene_at_redhat.com>
I'm replying to the list as well as CCing Bill and Jason, though I'm not
subscribed so someone will have to push it along for it to show up.
On 09/10/2012 06:17 PM, Bill Shannon wrote:
> Jason, thanks for forwarding these comments...
>
>>> From: "David M. Lloyd" <david.lloyd_at_redhat.com>
>>> Subject: Re: [javaee-spec users] [jsr342-experts] Re: Logs. Should we finally
> do something ?
>>> Date: September 7, 2012 3:37:37 PM CDT
>>> To: "Jason T. Greene" <jason.greene_at_redhat.com>
>>>
>>> As a user API, java.util.logging is so broken that it can't be made
>>> better and has to be replaced. The log levels it defines do not
>>> correspond to the industry standard; the logging API itself was
>>> already clunky, limited, and outdated when it was originally
>>> introduced.
>
> Which industry standard are you referring to?
These existing logging APIs - some of which predate JUL - including
Apache log4j and commons-logging, slf4j and logback, and our own JBoss
logging API - represent, I believe, the most pervasive logging APIs in
use in the Java world today; all of them use the
TRACE/DEBUG/INFO/WARNING/ERROR/FATAL convention. I believe this
constitutes a de facto standard, and I recall this to have been the case
in the time of SE 1.4 as well.
>>> As a backend, java.util.logging has a number of problems as well.
>>> It is extremely difficult to plug in customized providers (I have
>>> developed what seems to be the only widely used alternative
>>> logmanager implementation in existence in JBoss LogManager). The
>>> configuration infrastructure is highly limited and all but useless
>>> in the context of any nontrivial applications.
>
> It seems like the configuration infrastructure could be extended or
> augmented without throwing away what's there.
It's possible, but I don't believe that is actually at issue here.
>>> Now all that said, nobody is proposing a new logging framework to
>>> replace java.util.logging (though perhaps someone should, at some
>>> later point!); you are right that this would be the domain of the
>>> OpenJDK team and any such discussion should begin and end there.
>>>
>>> The first part of what is being proposed independently and
>>> repeatedly by myself and others, is an independent logging API
>>> *only* without specifying the corresponding implementation framework
>>> (JUL could suffice as a default). This API would have features such
>>> as the following:
>>>
>>> * Industry-standard log level methods (TRACE/DEBUG/INFO/WARNING/ERROR/FATAL)
>
> We could easily add aliases for TRACE and DEBUG. Ditto ERROR.
>
> We could probably add a level above SEVERE for FATAL.
That would a be good enhancement for JUL, sure.
>>> * Modern formatting options (String.format in addition to MessageFormat style)
>
> It might be ugly, but we could add "logf" and similar methods to Logger.
It is *probably* doable, though there are some caveats. We have
multiple formatting options in our LogManager implementation, as well as
other features which brought JUL up to (more or less) feature
equivalence with log4j but in order to do so we had to extend LogRecord.
Making these same changes in the platform JUL API would be tricky to
get right due to this compatibility difficulty.
See this link for that and the other extra fields we had to add:
https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/java/org/jboss/logmanager/ExtLogRecord.java
>>> * Varargs support
>>> * MDC and NDC APIs
>
> What are "MDC" and "NDC"?
Here's a recent article:
http://wiki.apache.org/logging-log4j/NDCvsMDC
Though I believe the concept to be about 10 years old or so. This
enhancement also requires changes to LogRecord. Many projects rely on
the presence of MDC/NDC, and all of the log facade APIs I know of
provide it (though it is usually emulated when JUL is the chosen backend).
>>> * ServiceLoader-style provider location to allow container and/or
>>> user selection of implementation
>
> It definitely needs to be more convenient for the container to provide
> its own LogManager, but we really don't expect user applications to do so.
No, of course not, though a user (or a container) might want to use
something existing like log4j, which is nearly impossible with JUL today
because the Logger API is bound up directly with the way that
LogManagers work. I do not see how it would be possible to solve this
problem with JUL, which is why we treat it not as an API with a
pluggable implementation but as just an implementation which one would
add an API to. Many users feel the same way, explaining the ubiquity of
slf4j- and commons-logging-type facade APIs. The proposed javax.logging
API would be a standardized replacement for these APIs; JUL would be a
single implementation choice.
It is my belief that while it would be nice to expand JUL into a
widely-used API by adding the missing features, it is just not possible
without some potentially major breakage, because the implementers have
painted themselves into a corner in a lot of respects. It's been over
10 years now since this API was released into the wild and it simply has
failed to catch hold.
>>> Such an API would have a very good chance at becoming a de-facto
>>> logging API, bringing some order to the chaos in that space. The
>>> reason is that, because it is standard, authors of the popular
>>> backends (beyond JUL, there's log4j and logback) would be motivated
>>> to implement providers for the API. If these projects do so then it
>>> would become the best choice for anyone from framework developers to
>>> end-users, because it just works in any environment. And that makes
>>> life easier for container vendors since they can move towards
>>> supporting one single ubiquitous API instead of trying to support
>>> many, each with their own warts.
>>>
>>> The second part of what is being proposed is a standardized way to
>>> express logging configuration information within user deployments in
>>> a Java EE container. I think this is fairly self-explanatory; it
>>> amounts to a standard descriptor format that defines category
>>> levels, filters, handlers, etc.
>
> This could probably be done as a Java EE-specific JSR, or addition to the
> platform spec.
>
>>> I think at least the first part is comparatively simple and
>>> achievable and potentially very beneficial to the entire Java
>>> community. The second part might or might not be; defining handlers
>>> which potentially write to the filesystem might not be a great fit
>>> for the way that Java EE is presently defined.
>
> While the application might want to control logging levels and such, in
> a managed environment I would expect the container to control where and
> how the log messages are written.
Seems reasonable to me.
--
- DML