[slf4j-user] Slf4j 2.0 future

[Joakim Erdfelt]

Jetty includes slf4j-api-2.0.0.alpha.jar in it's jetty-home (distribution),
and we've built it specifically against the slf4j version 2.0.0 series.

https://github.com/eclipse/jetty.project/blob/jetty-11.0.5/pom.xml#L22

https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-home/10.0.5/jetty-home-10.0.5.tar.gz

[jetty-home-10.0.5]$ find . -name "*slf4j*"
./lib/logging/jetty-slf4j-impl-10.0.5.jar
./lib/logging/slf4j-api-2.0.0-alpha1.jar
./modules/logging/slf4j.mod

We don't use the fluent logging API, as we were unhappy with the extra GC
it seems to be generating.

We have full JPMS support with slf4j-api-2.0.0-alph1.jar without any extra
work on our part.
Works well, even with the alternate bridge APIs.

https://github.com/eclipse/jetty.project/blob/jetty-11.0.5/jetty-slf4j-impl/src/main/java/module-info.java#L22
https://github.com/eclipse/jetty.project/blob/jetty-11.0.5/jetty-server/src/main/java/module-info.java#L25
https://github.com/eclipse/jetty.project/blob/jetty-11.0.5/jetty-deploy/src/main/java/module-info.java#L25

We even have automated unit testing of our JPMS layers with logging
enabled! :-)

As for OSGI, the sfl4j-api-2.0.0-alpha1.jar lacks the OSGI manifest
`Requires-Capability` for the ServiceLoader layer.
That's an unfortunate missing piece in the 2.0.0-alpha1 release.

We hacked in that missing serviceloader manifest entry into our own
jetty-slf4j-impl.jar.
https://github.com/eclipse/jetty.project/blob/jetty-11.0.5/jetty-slf4j-impl/pom.xml#L42-L45

And we have an osgi bundle fragment that we can hack the manifest into for
testing reasons.
Also, for our paxweb testing, we have a snippet that adds that service
loader requirement.

https://github.com/eclipse/jetty.project/blob/jetty-10.0.3/jetty-osgi/test-jetty-osgi/src/test/java/org/eclipse/jetty/osgi/test/TestOSGiUtil.java#L164-L167

        //the slf4j-api jar does not have support for ServiceLoader in osgi
in its manifest, so add it now

res.add(wrappedBundle(mavenBundle().groupId("org.slf4j").artifactId("slf4j-api").versionAsInProject())

.instructions("Require-Capability=osgi.serviceloader;filter:=\"(osgi.serviceloader=org.slf4j.spi.SLF4JServiceProvider)\",osgi.extender;filter:=\"(osgi.extender=osgi.serviceloader.processor)\"")
            .overwriteManifest(OverwriteMode.MERGE)
            .start());

The work done in SLF4J-457 for OSGi is right on the money, and the
associated PR and commit fix it nicely.

As for Eclipse IDE and slf4j-api-2.0.0-alpha1, they had to recently (this
week) yank it out due to both some conflicts in other libraries (i'm
unclear what those conflicts entailed), and the general "we think slf4j is
an abandoned project" attitude.
You can see some of the conversations around this at
https://www.eclipse.org/lists/cross-project-issues-dev/threads.html#18493
We, Eclipse Jetty, had to even expand our declared Import-Package to allow
using 1.7.x upwards of slf4j to allow Eclipse IDE to get past these issues
for their current release.
Thankfully, our main codebase isn't using the slf4j fluent API which means
we are still backwards compatible with slf4j 1.7 for OSGi users, but we'd
like to encourage & foster slf4j 2.0.0 as the future direction, even there.

- Joakim


On Mon, Jun 14, 2021 at 4:33 AM Ceki <ceki at qos.ch> wrote:

>
> Hi Joakim,
>
> Indeed, I am aware that Jetty has been supporting/using slf4j since
> early on. Thank you!
>
> I was not aware that Jetty and Eclipse IDE was using slf4j 2.0.0-alpha.
>
> As you are probably aware, slf4j 2.0 introduces a fluent logging API
> which is quite an enhancement with respect to the traditional logging
> API. Are you using the fluent API at all?
>
> Thank you for your offer to help. It is much appreciated.
>
> Do you see any issues that are blocking on your end? With slf4j's JPMS
> support perhaps? Maybe OSGi?
>
> More concretely, in SLF4J-457, see [1], the MANIFEST.MF file was
> modified [2] by adding a "Require-Capability:" statement, see [2]. How
> safe is this addition in OSGi environments? In non-OSGi environments?
>
> Best regards,
>
>
> [1] https://jira.qos.ch/browse/SLF4J-457
> [2] https://github.com/qos-ch/slf4j/commit/4a1d5194fe
>
> --
> Ceki
>
>
>
>
> On 10.06.2021 14:41, Joakim Erdfelt wrote:
> > Hey Ceki,
> >
> > Hi from the Eclipse Jetty project.
> > We've been supporting slf4j in Eclipse Jetty since Jetty 5.x (and slf4j
> > 1.1.0)
> >
> > Recently (in the past 2 years), we moved to slf4j 2.0 because it was our
> > favorite logging facade and had support for JPMS. (proper JPMS support
> > was the huge deciding factor)
> > We did this with our Jetty 10.x series (and Jetty 11.x series), which
> > have had 4 stable releases each so far.
> > We have a JPMS web server with a JPMS based logging facade.
> >
> > We've had great success, and even wrote our own minimal implementation
> > of slf4j-api 2.0 that we use for our minimal deployments (even
> > supporting JPMS).
> >
> https://github.com/eclipse/jetty.project/tree/jetty-10.0.x/jetty-slf4j-impl
> > <
> https://github.com/eclipse/jetty.project/tree/jetty-10.0.x/jetty-slf4j-impl
> >
> >
> > This in turn has encouraged others to adopt slf4j 2.0 as well, including
> > the Eclipse IDE itself.
> > This means we now have an OSGi manifest requirement that is being worked
> > out as I write this.
> >
> > We have hundreds of thousands of installations of Eclipse Jetty 10+
> > active around the world now, all with slf4j 2.0 running.
> >
> > However, there's been a slow drum beat of criticism that says slf4j
> > looks like a dead project with an absent developer community.
> >
> > I want to see slf4j survive and continue to be the awesome project we've
> > grown to love.
> >
> > Is there anything you need help with?
> > I'll be happy to help.
> > Do you need help addressing or verifying anything from the JIRA issues
> > to progress?
> >
> > Thanks again,
> > Joakim Erdfelt (Eclipse Jetty committer)
> >
>
> --
> Ceki Gülcü
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20210614/9996e1b5/attachment.html>