jsr342-experts@javaee-spec.java.net

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

From: Pete Muir <pmuir_at_bleepbleep.org.uk>
Date: Tue, 11 Sep 2012 13:04:59 +0100

Yes, this is trivial, see https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/kitchensink/src/main/java/org/jboss/as/quickstarts/kitchensink/util/Resources.java#L48 for a simple example that just uses the class declaring the logger as the category.

On 11 Sep 2012, at 13:00, Werner Keil wrote:

> Could java.util.logging also be made injectable that way?
>
> Thanks,
> Werner
>
> On Tue, Sep 11, 2012 at 1:56 PM, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
> The logging in Solder is basically JBoss Logging, but made injectable.
>
> On 11 Sep 2012, at 00:20, Werner Keil wrote:
>
> > Oh and Jason, please correct me, but most of that CDI Logging, Seam/Solder does (based on DeltaSpike we might even see the Log4J team contributing?;-) also looks unlikely with bare bone JUL alone?
> > http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-logging.html
> >
> > There seem to be wrappers here, too, so various loggers are supported, including that from JDK.
> >
> > Am 11.09.2012 00:22 schrieb "Werner Keil" <werner.keil_at_gmail.com>:
> > +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.
> >
>