+1
Beside pointing out a couple of differences between most Specs that include
far more interfaces or at least a few abstract base classes (e.g. like
java.util.Calendar) which JUL lacks, flexibility, portability and
scalability become even more important, once you look at a Cloud/PaaS
enabled Future for JavaEE. Another reason to look at some of these issues,
allowing them to get into at least EE8, with a prospect, of adoption by
future Java SE versions like 9, too.
Werner
On Mon, Sep 10, 2012 at 10:34 PM, Jason Greene <jason.greene_at_redhat.com>wrote:
> On Sep 7, 2012, at 2:47 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> > I'm not sure I fully understand what you're proposing...
> >
> > If you're proposing a new logging framework to replace
> java.util.logging, then, well, I can't speak for the JDK team but I think
> you need to engage with them in the OpenJDK project to see what they
> would think of that. I have a hard time believing that java.util.logging
> is so broken it can't be made better and has to be replaced.
> >
> > If you're proposing something specific to Java EE that works with or
> layers on java.util.logging, then I need to understand it better before I
> can support it.
>
>
> I think Antonio is on to something here. Logging is a pretty big
> portability problems for Java EE containers. In our case we have attempted
> to address the issue in JBoss AS by trying to be compatible with every
> logging framework under the sun (usually rerouting the API). I am sure all
> of the other venders will concur that supporting the framework soup out
> there is a fun challenge (especially when they cause things like class
> loader leaks). So if someone ever does start a JSR in this area, we would
> certainly like to participate.
>
> I have included some additional pertinent thoughts from a colleague below:
>
>
> > 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.
> >
> > 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.
> >
> > 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)
> > * Modern formatting options (String.format in addition to MessageFormat
> style)
> > * Varargs support
> > * MDC and NDC APIs
> > * ServiceLoader-style provider location to allow container and/or user
> selection of implementation
> >
> > 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.
> >
> > 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.
>