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