2015-04-16 9:53 GMT+02:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
> 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 ?
>
>
You don't speak of a spec anymore here but implementations. There is place
for the DEBUG (all "JUL as API" implemention prooves it) so let
implementation do maybe and just define at spec level it should use FINEST
(that said I see a usage for a bit more, typically for JPA FINE = sql
query, FINER = with binding parameters, FINEST = with binding parameters
values even for lobs - in practise these 3 levels will be DEBUG for most of
other framework and that is not a real issue while they read the same
config).
> 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)
>
>
Not sure, while you accept to restrict yourself to JUL you just need to
have a "by app" configuration. being aligned on EARs for rules is simple
IMO - but right it would be a great feature for multi-container users and
for EE.
> 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>
>