users@javaee-spec.java.net

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

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Mon, 10 Sep 2012 16:17:07 -0700

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?

>> 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.

>> 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.

>> * Modern formatting options (String.format in addition to MessageFormat style)

It might be ugly, but we could add "logf" and similar methods to Logger.

>> * Varargs support
>> * MDC and NDC APIs

What are "MDC" and "NDC"?

>> * 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.

>> 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.