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:20:51 +0200

@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)


@Yannick If JUL is being used and you think it's sufficient, then why so
many Logging frameworks ?


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.

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