Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Why was there never another Logging JSR?

Actually it looks like he tried that on GitHub already, so that could be a starting point for those Jakarta EE containers that build on top of Log4J, SLF4J or another logger.

Werner





On Sun, Apr 26, 2020 at 2:18 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
It is pluggable though, not sure, if any vendor already tried that, but by definition of the JEP it should allow replacing JUL with other loggers, therefore I doubt a new JSR or Jakarta Spec for logging as such makes sense because Jakarta EE 9 will already be based on Java 9, 10 or 11, so it can use that now.

It may be a very small API but at least it allows other implementations unlike e.g. JSR 310.

Werner 





On Sun, Apr 26, 2020 at 12:32 AM Ken Fogel <omniprof@xxxxxxxxx> wrote:

When I spotted the System logger I remarked that it was about time for an update. I was very quickly informed that this logger is for a very narrow purpose and not for general purpose logging. That is still the domain of JUL. See https://www.baeldung.com/java-9-logging-api to see what you could do with it.

 

Ken

 

 

From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Joakim Erdfelt
Sent: April 25, 2020 5:02 PM
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Why was there never another Logging JSR?

 

>  could be an interesting extension to the JDK logging API

 

Which JDK logging API?

 

The old school java.util.logging introduced in Java 1.4?

 

On Sat, Apr 25, 2020 at 3:07 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:

I think there were CDI examples for logging once, maybe in Weld or DeltaSpike, don't know, maybe some sort of annotations could be an interesting extension to the JDK logging API, but I very much hope, it ends up in Jakarta EE, whether a in Jakarta Annotions or another spec, but not a "MicroProfile solo" I'd hope in this case ;-)

 

Maybe you and your students could help?

 

Werner 

 

 

 

 

On Sat, Apr 25, 2020 at 3:13 PM <omniprof@xxxxxxxxx> wrote:

Hi,

 

I’m working on both updating existing code and adding new code to the Examples project. In my courses I dissuade my students from using JUL, preferring SLF4J with Log4j. For example, in creating an example of coding servlets I place log messages in all the overridden methods and the Constructor. I can’t use the logger from the servlet context in the constructor. While using Log4j or any other framework adds to the individual dependencies for the project it is worth the cost and you can log anywhere. What I’d love to see is a logging tag for JSF though I should just write my own. All of this to say that I don’t believe creating a JSR and introducing a new logging framework is worth the effort. Logging is like shoes, we each have a comfortable pair and as long as its output ends up in the server log we are happy.

 

Ken

 

 

From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Werner Keil
Sent: April 13, 2020 4:23 PM
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Why was there never another Logging JSR?

 

Yes, this was the time I mentioned, Markus was involved but he may have responded to what Antonio raised.

 

There were also brief discussions about a MP feature but quite frankly now that the JDK offered at least a very basic abstraction layer I think it makes more sense to use the new Java 9 feature where possible. As soon as a Jakarta EE version has the minimal JDK to be 9 (which could be already the case for Jakarta EE 9) it should be changed to something similar as we did in the JSR 385 API in a Multi-Release-JAR: https://github.com/unitsofmeasurement/unit-api/blob/master/src/main/jdk9/javax/measure/spi/ServiceProvider.java#L381  so the API is still backward compatible with Java 8.

 

Werner

 

 

 

On Mon, Apr 13, 2020 at 10:00 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

 

There were some more discussions for a Logging JSR. I think Antonio Goncalves started multiple discussions about it as well, and wrote some blogs. See e.g.

 

 

I remember the requirements for a potential Logging JSR were twofold: the ability to set the logging level of logical APIs (like set Faces logging, independent of whether it's implemented by MyFaces or Mojarra and whatever they are using for logging), and an API for applications running on Java EE to use for logging.

 

Kind regards,

Arjan

 

 

 

 

On Mon, Apr 13, 2020 at 9:48 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:

Hi,

 

There was an interesting question on Twitter the other day, why beside configuration there had never been a JSR for logging which is also a fundamental aspect of many enterprise applications.

 

There was in the very early days of the JCP:  https://jcp.org/en/jsr/detail?id=47, but java.util.logging never was vendor-neutral or extendable and unlike the Collections Framework which has many different implementations also at Eclipse I'm not aware any alternate implementation outside the JDK ever existed.

 

Markus Eisele thought about this when he worked at Red Hat for the first time, several years ago about a decade or so. 

However, the idea never got beyond initial discussions with involved vendors. And from what I heard back then it was a similar kind of vanity and pride by authors of several frameworks like Log4J, LogBack/SLF4J or Apache Commons Logging and of course the JDK team behind JUL. 

Every committer or team insisted, only their project could be the RI for such JSR, so eventually Markus gave up the idea.

Interestingly the JDK picked up the idea mostly to make itself a little more modular and simplify the dependency graph with Java 9: http://openjdk.java.net/jeps/264

I am not sure, what exact TCK support exists for this API, but it aims to be easily adoptable by applications which use external logging framework, such as SLF4J or Log4J, so that'll have to do for now, and it does not seem like a Jakarta standard or MP feature is really worth the effort in this case.

 

Werner 

 

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

Back to the top