users@javaee-spec.java.net

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

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
Date: Thu, 16 Apr 2015 09:53:53 +0200

JUL levels are : SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST...
There is no DEBUG here (likewise the other logging frameworks). So if Java
EE can "impose" log levels to other specs, which levels will we impose ?
What about the implementations that use JUL ? What will they do with DEBUG
level ?

Basically, Java EE should define log configuration (levels, defining
loggers...) and each spec should use it and specify which logger it uses,
and what is logged when. No need to have a new Logging JSR, but agreeing on
log configuration (and we all know this looks simple, but it's harly doable)

Antonio

On Thu, Apr 16, 2015 at 9:33 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:

>
> Le 16 avr. 2015 09:22, "Antonio Goncalves" <antonio.goncalves_at_gmail.com>
> a écrit :
> >
> > @Romain "That said being able to do javax.persistence.logger=DEBUG
> doesnt help at all while you dont define what the provider should log."
> That's exactly why we create specification : to define things. We have :
> >
> > <property name = "hibernate.show_sql" value = "true" />
> > <property name="eclipselink.logging.level" value="FINE"/>
> > <property name="openjpa.Log" value="DefaultLevel=WARN, Runtime=INFO,
> Tool=INFO, SQL=TRACE"/>
> >
> > Well, let's all agree on a javax.persistence.query = DEBUG, explain what
> it does in the spec, and we are done. Each specification can define what it
> logged at a certain level (JSF has a <ui:debug> tag)
> >
>
> Makes sense but already doable with JUL (ie not a reason to redo a spec).
>
> >
> > @Yannick If JUL is being used and you think it's sufficient, then why so
> many Logging frameworks ?
> >
>
> Same for web. New needs, policies, dependencies etc...
>
> >
> > I'm not even talking about an API for the developper (who can still use
> whateven he/she wants), I'm talking about being able to increase logs in
> the internals of Java EE APIs. Today, because logs are such a mess, we
> can't even agree on configuration (that's the important point). Shall we
> use DEBUG ? FINEST ? Is the configuration in XML ? Properties ? What's the
> syntax to define a logger ? I really don't care about business logs (using
> JUL, Log4J or whatever), I'm more concerned about easily chaging the Java
> EE log levels.
> >
>
> Hmm, let go on my side 1mn, suppose you have a EELogManager, what do you
> miss then? Format logging.properties is already standard. So EE umbrella
> can just mandates an application aware log manager - no need of a spec IMO
> - then I join you each spec can define specific loggers.
>
> Wdyt?
>
> > Antonio
> >
> > On Thu, Apr 16, 2015 at 7:28 AM, Yannick Majoros <
> yannick.majoros_at_gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> This looks like Hibernate vs Toplink 10 years ago. And yet, it was
> solved with JPA.
> >>
> >> I'm convinced that an API that would be based on most common features
> (probably not all), with extension points, could be quite successful. It
> wouldn't add any feature, the goal is just to standardize (further than
> JUL) all those logging frameworks. It's been tried before (see various
> logging facades), but without any standardization authority. This matters
> much.
> >>
> >> It could be integrated with Java EE: CDI, bean validation, ... Maybe
> some requirements for asynchronous operations too. Class loading
> restrictions to have some common guarantees against memory leaks.
> >>
> >> Some people would probably still use specific features, occasionally or
> exclusively, but they have a migration path. Anyway, changing logging
> implementation would be easy for applications that are coded to the
> standard. Others would have a simple migration path to it.
> >>
> >> Just my two cents as a random Java EE user...
> >>
> >> Yannick Majoros
> >>
> >> Le 15-04-15 23:34, David M. Lloyd a écrit :
> >>
> >>> In WildFly and JBoss EAP, we have a (fairly complex) system which uses
> our own log manager based on JUL and also has special API stubs for log4j,
> log4j2, slf4j, and Apache commons-logging, which means that logging for all
> these systems all get merged into one output that supports most features of
> all the frameworks and APIs. But that doesn't mean it's a good thing: this
> solution took an inordinate amount of effort to accomplish, and definitely
> isn't practical for your average standalone application which maybe pulls
> in libraries using three or four differnt and possibly incompatible logging
> systems. I'd love to see some sensible API to replace all the logging
> APIs, but there are the two primary practical difficulties:
> >>>
> >>> 1. Nobody will ever agree what the "right" logging API would look like
> (this is why we have so many of them: slf4j, jcl/Apache cl, log4j, log4j2,
> JUL, and our own JBoss Logging API).
> >>> 2. Nobody will ever agree what the "right" logging backend
> configuration capabilities would be (this is why we have so many of them:
> logback, log4j, log4j2, JUL, and our own JBoss Log Manager).
> >>>
> >>> Even if these two problems would be solved, you'd really have to get
> buy-in from all the primary logging backends (logback, log4j, log4j2, and
> of course JUL) if you really want it to be successful, which is a difficult
> proposition. The effects could end up making the problem worse: existing
> logging facades would start shipping backends to the new API, which in turn
> would forward to the API for the chosen backend, adding yet more layers to
> an already overly-complex situation.
> >>>
> >>> It's hard to see a clear plan that starts with "let's create a new log
> API" and actually ends up with any kind of standardization on that API, at
> least in under 5+ years time, given the sheer quantity of legacy code using
> all the other existing and popular log APIs - even assuming that the API
> satisfied everyone, which it definitely won't, because with logging there's
> always people with oddball use cases that exploit specific behaviors of
> specific frameworks. If someone has such a plan, then let's hear it.
> >>>
> >>> On 04/15/2015 10:46 AM, Mark Struberg wrote:
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>
> >>
> >
> >
> >
> > --
> > 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 <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>