I guess Log4J could be seen as "de facto standard", but allowing a certain
level of flexibility or mapping sounds good.
It may not have to go as far as the example from Seam where custom
categories are used, I remember just one maybe two clients who ever
demanded that, and at least in one case, the Business could never agree
WHICH categories would be used by which department or project;-)
Having even just some form of mapping or "decorator" also goes in similar
directions as my point about JSF2 strict stage names not being flexible
enough for most real life projects, not to mention the Cloud.
Werner
Am 11.09.2012 01:20 schrieb "Werner Keil" <werner.keil_at_gmail.com>:
> 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.
>>>
>>
>>