Date: Wed, 18 Jul 2012 11:19:05 +0200
Good point, but the whole logging mechanism would have to be drastically
rewritten, more or less like SLF4J[?]
http://www.slf4j.org/legacy.html
There you can chose Log4J, java.util.logging, commons-logging or Ceci's own
LogBack as the underlying implementation. This is a true logging "spec"
while java.util.logging:
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/logging/package-summary.html
relies almost entirely on concrete classes.
Unfortunately while well-respected for some stuff they did, people like
Stephen, the JSR 310 Spec Lead prefers a hard-wired API based entirely on
concrete classes, which tends towards how java.util.logging looks like
(except making most classes *final*, so they're "Immutable", instead of
defining e.g. a reasonable set of interfaces with just a *getter *and* no
setter* making the spec API immutable, but extendible)
People with a similar mind and understanding, probably under a lot of time
pressure, too created this mess as part of a previous Java SE version.
Logging was done in 2001, around the time, the JCP started to exist, and
unfortunately there has been no true "Logging JSR" ever since. And unless
you forced all app server vendors to use only java.util.logging (many use
one or several others) you can't even assume the log levels of some
components to be things like FINER, as that's e.g. specific to JDK Logging
and others have different names or these levels don't even exist.
So I'm afraid, with true Java Modularity pushed to Java 9 this would be
very hard, unless some brave Spec Lead proposes a Logging JSR to replace
the old mess. I'd say that clearly exceeds both SE and EE Umbrella scope
right now.
SLF4J does not contain a lot more packages and elements than small JSRs
like 330:
SLF4J packages*org.slf4j<http://www.slf4j.org/apidocs/org/slf4j/package-summary.html>
*Core logging interfaces.*org.slf4j.cal10n<http://www.slf4j.org/apidocs/org/slf4j/cal10n/package-summary.html>
* *org.slf4j.helpers<http://www.slf4j.org/apidocs/org/slf4j/helpers/package-summary.html>
*Helper classes.*org.slf4j.impl<http://www.slf4j.org/apidocs/org/slf4j/impl/package-summary.html>
*Implementations of core logging interfaces defined in the
org.slf4j<http://www.slf4j.org/apidocs/org/slf4j/package-summary.html>
package.*org.slf4j.spi<http://www.slf4j.org/apidocs/org/slf4j/spi/package-summary.html>
*Classes and interfaces which are internal to SLF4J.
Unless of course a Logging JSR (or all JSRs and servers using something
like SLF4J instead[?]) was in place and legacy packages can be pruned thanks
to modularity, you won't be able to scale down and get rid of the old
stuff.
Clearly EE could benefit more if a Logging JSR existed.
Thoughts, takers?[?]
Werner
On Wed, Jul 18, 2012 at 8:24 AM, Markus Eisele <myfear_at_web.de> wrote:
> Popping this up again because of the missing feedback from Linda/Bill.
>
> - Markus
>
> On 16 April 2012 19:49, Antonio Goncalves <antonio.goncalves_at_gmail.com>
> wrote:
> > I like the idea of standardizing staging in all the specs (and not just
> JSF)
> > and I also like the idea of using this staging for log levels (instead of
> > FINEST, TRACE or whatever). But again, that would mean having a standard
> way
> > accross Java EE to define staging and log levels
> >
> >
> > On Sunday, April 15, 2012, Adam Bien wrote:
> >>
> >> Hi Antonio,
> >>
> >> whats about coupling the log settings to "run levels"?
> >>
> >> Every application server I know comes with "development" and
> "production"
> >> stage.
> >>
> >> We could rely on the spec packages and use then something like:
> >>
> >> javax.ejb=production (whatever it means for Log4j -> mapping would be
> >> server-specific)
> >> javax.rs=development
> >> javax.enterprise.inject (but now org.weld)
> >>
> >> etc.
> >>
> >> I see a problem with your proposals, that the specifiied log levels do
> not
> >> have to be available for each framework (log4j, java logging, etc.).
> >>
> >> thoughts?
> >>
> >> adam
> >> On 09.03.2012, at 15:43, Antonio Goncalves wrote:
> >>
> >> > Hi all,
> >> >
> >> > We are in 2012 and I just spent a few hours trying to display the logs
> >> > of an application on GlassFish 3.1.2 and JBoss 7.1.0 (and it's not
> the first
> >> > time in my career). Modules to exclude in one, jars to add in the
> >> > WEB-INF/lib on the other... or to exclude. And of course, that's just
> my
> >> > application Log4j logs. If I want to have more logs on javax.ejb I
> need to
> >> > setup a different file in JBoss and another one in GlassFish.
> >> >
> >> > I know javax.util.logging exists in Java SE but nobody tends to use it
> >> > (despite GlassFish uses it and JBoss has a brand new logger that wraps
> >> > java.util.logging), I know we can happily choose from 10 fashionable
> brand
> >> > new logging frameworks... but really, it's a pain. Every application
> uses
> >> > logs. Every framework uses logs. Every Java EE spec implementation
> uses
> >> > logs. For an application to be portable across app servers, for a
> >> > configuration file to be portable across Java EE specs, we should do
> >> > something.
> >> >
> >> > I would love to write :
> >> >
> >> > javax.ejb.level = debug
> >> > javax.persistence.level = debug
> >> > org.weld.level = debug
> >> > my.app.level = debug
> >> >
> >> > Add this config file under WEB-INF/classes and don't worry about
> >> > anything else... and have the same behavior under GlassFish, JBoss or
> >> > whatever.
> >> >
> >> > Logging frameworks have been a battle since day one and it's one of
> the
> >> > things that make me feel the Java ecosystem is too complex and is
> slowly
> >> > fading from developers/ops concerns. Gosh, I just want to display
> some logs,
> >> > why do I have to choose from 10 different frameworks and why should I
> battle
> >> > with app server configuration.
> >> >
> >> > Isn't it the role of the Java EE spec to make the other spec agree to
> a
> >> > standard ? And what about logging ?
> >> >
> >> > Antonio
> >>
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | Blog | LinkedIn | Paris JUG
>
-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera. Werner Keil, JCP Executive Committee, JSR-321 EG Member will present "Trusted Computing API for Java™" * Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil, Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E class Continuous Delivery with Hudson, Maven and Mylyn"
