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