users@javaee-spec.java.net

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

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Wed, 15 Apr 2015 14:19:53 +0200

Antonio: this is fully wrong, any spec can use JUL *today* the way you
describe it. That said being able to do javax.persistence.logger=DEBUG
doesnt help at all while you dont define what the provider should log.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-04-15 14:16 GMT+02:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:

> 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 <https://twitter.com/rmannibucau> | Blog
>> <http://rmannibucau.wordpress.com/> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com/>
>>
>> 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 <https://twitter.com/rmannibucau> | Blog
>>>>>> <http://rmannibucau.wordpress.com/> | Github
>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>> <http://www.tomitribe.com/>
>>>>>>
>>>>>> 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 <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/>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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/>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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/>
>>>
>>
>>
>>
>
>
> --
> 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>
>