users@javaee-spec.java.net

[javaee-spec users] Re: [jsr366-experts] Standardizing logging

From: Kevin Sutter <sutter_at_us.ibm.com>
Date: Thu, 16 Apr 2015 07:55:06 -0500

> There is surely no need to have yet another logging framework in EE…

+1

----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter

 

Mark Struberg <struberg_at_yahoo.de> wrote on 04/15/2015 10:46:35 AM:

> From: Mark Struberg <struberg_at_yahoo.de>
> To: users_at_javaee-spec.java.net
> Date: 04/15/2015 05:44 PM
> Subject: [javaee-spec users] Re: [jsr366-experts] Standardizing logging
>
> You can use JUL as ‚interface‘ and delegate to e.g. log4j2
> internally. That way you can still use MDC, async appenders and all
> other neat stuff but you only have an interface where you have a
> guarantee for not getting into class clash troubles. This is not
> the case with slf4j. There have been binary incopatible changes
> between I think it was 1.5 and 1.6 which now create ugly clashes…
>
> There is surely no need to have yet another logging framework in EE…
>
> LieGrue,
> strub
>
>
> > Am 15.04.2015 um 14:50 schrieb Steve Hostettler
> <steve.hostettler_at_gmail.com>:
> >
> > Hello,
> >
> > Just a short note to confirm that JUL is used in production. We
> use WebSphere that comes with JUL integration. It is not that bad,
> as the WAS integration provides UI for changing log level at
> runtime. Nevertheless, we move now to logback + slf4j because of the
> implementation (performances, limited customization, no context
> information). Sure, the API could be improved but in my opinion it
> is not the biggest problem.
> >
> > Steve
> >
> >
> > On Apr 15, 2015, at 14:22, Yannick Majoros
> <yannick.majoros_at_gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> Who says nobody uses JUL in production? I do use it for sure ;-)
> It's what provided with Glassfish and other AS, and I wouldn't want
> to use any of the "clogging" tools that break my classloader
> isolation and introduce memory leaks with no added value.
> >>
> >> But yes, I'm convinced that a logging specification would ease
> things out. It would just specify some logging interfaces (as other
> logging abstraction framework tried to do, with no authoritative
> standard). It could also provide clues of acceptable / required
> class loading practices, e.g. in a Java EE environment.
> >>
> >> It could also be the right time to improve the APIs. Maybe some
> common expected logging facilities, too.
> >>
> >> Le mer. 15 avr. 2015 à 14:17, Antonio Goncalves
> <antonio.goncalves_at_gmail.com> a écrit :
> >> Because nobody uses JUL, the Java EE specs can't use it to define
> standard loggers. JUL is broken, yes, the JDK folks will fix it (not
> sure), but in the meantime the JPA spec can't say "to inscrease the
> JPA logs, just do javax.persistence.logger=DEBUG".
> >>
> >> Antonio
> >>
> >> On Wed, Apr 15, 2015 at 12:29 PM, Marek Potociar
> <marek.potociar_at_oracle.com> wrote:
> >> I agree that creating new logging spec will not solve any
> problems with people not using JUL. IMO, JDK folks should find out
> why people shy away from JUL and then try to fix it.
> >>
> >> Marek
> >>
> >>> On 15 Apr 2015, at 09:18, Romain Manni-Bucau
> <rmannibucau_at_gmail.com> wrote:
> >>>
> >>> Well, deprecation part doesnt affect the main topic IMO.
> >>>
> >>> Having a standard will not solve the logging aggregation if it
> is not in the JVM (ie if done at EE level). Just check how EE sub
> spec are accepted or not. They are often integrated but not the
> default - for good or bad reason.
> >>>
> >>> The fact there are so much logging frameworks on github doesn't
> mean a spec would solve it. These projects are sometimes the same
> (thanks git modularization) and moreover it mixes API and
> implementation - thing a spec can't change since it would provide API
mainly.
> >>>
> >>> My main question is what do you miss or what don't you like in
> JUL. While you say a standard it doesn't help to go further IMO.
> Creating a spec or "fixing" JUL is not the same pain at all and I
> really think JUL is not that far from being usable (in particular
> since java 8) + it is the standard since it is in the JVM.
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 2015-04-15 9:04 GMT+02:00 Antonio Goncalves
<antonio.goncalves_at_gmail.com>:
> >>> Yes, that's why I wrote *bits* of JUL will get deprecated (so
> modularization will be possible).
> >>>
> >>> We write more logs than servlets, we write more logs than
> restservices, we write more logs than entities... We then aggregate
> frameworks that use different logging frameworks, we configure them
> differently, it is a pain to manage... but let's face it, there is
> no money to be made out of standardizing logs. If you read my first
> email, you'll undersant that 6 of the top 20 git hub projects are
> related to logging. So no, there is no standard nor defacto standard !
> >>>
> >>> Antonio
> >>>
> >>> On Tue, Apr 14, 2015 at 9:42 PM, Romain Manni-Bucau
> <rmannibucau_at_gmail.com> wrote:
> >>>
> >>> 2015-04-14 21:23 GMT+02:00 Antonio Goncalves
> <antonio.goncalves_at_gmail.com>:
> >>> Gosh, we've talked about it so many times that it's becoming
> painful : no body uses JUL in a production environment. Full stop.
> So, let's do something else. The good thing is that it looks like
> bits of JULs will get deprecated [1] so it will be easier to get rid
> of it when modularization.
> >>>
> >>>
> >>> That is a wrong free assumption...and moreover not a reason to
> create another *API*.
> >>>
> >>> Side note: JUL will not get deprecated reading your link, just
> part property listener part
> >>>
> >>>
> >>> Antonio
> >>>
> >>> [1] http://openjdk.java.net/jeps/162
> >>>
> >>> On Tue, Apr 14, 2015 at 9:18 PM, Romain Manni-Bucau
> <rmannibucau_at_gmail.com> wrote:
> >>> @Antonio: can you point out what you want to standardize? Seems
> java.util.logging is here and already standard. Only missing thing
> from my point of view is "application" configuration but not sure it
> does worth a JSR, do yuo have something else in mind?
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 2015-04-14 20:00 GMT+02:00 Antonio Goncalves
> <antonio.goncalves_at_gmail.com>:
> >>> Hi all,
> >>>
> >>> I've mentioned standardizing logging so many time [1], that I'll
> make it short this time (BTW, on a day to day basis, as a
> developper, I still struggle with logs).
> >>>
> >>> But this time I saw this blog, so I couldn't stop from thinking
> about it : On the top 20 Java GitHub projects, 6 are related to
> logging [2] I know logging wasn't in the top priorities of the Java
> EE 8 survey, but I think it's also our duty to acknowledge that, if
> so many logging framework exists, then, there is a demand.
> >>>
> >>> Antonio
> >>>
> >>> [1] http://antoniogoncalves.org/2012/09/06/i-need-you-for-
> logging-api-spec-lead/
> >>> [2] http://blog.takipi.com/we-analyzed-60678-libraries-on-
> github-here-are-the-top-100/
> >>>
> >>>
> >>> --
> >>> Antonio Goncalves
> >>> Software architect, Java Champion and Pluralsight author
> >>>
> >>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Antonio Goncalves
> >>> Software architect, Java Champion and Pluralsight author
> >>>
> >>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Antonio Goncalves
> >>> Software architect, Java Champion and Pluralsight author
> >>>
> >>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Antonio Goncalves
> >> Software architect, Java Champion and Pluralsight author
> >>
> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
France
>