Re: [slf4j-user] slf4j for Java 17?

[Joakim Erdfelt]

Excellent news!

Thanks for keeping this project alive and up to date with modern java.

- Joakim

On Sat, Aug 6, 2022 at 3:58 PM Ceki Gülcü  wrote:

>
> Hello,
>
> SLF4J 2.0.0-beta0 was released yesterday. Version 2.0.0-beta1 will be
> released shortly and 2.0.0-RC0 should follow towards the end of the month.
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
>
>
>
> On 7/12/2022 5:37 PM, Daniel Krügler wrote:
> > Am 12.07.2022 um 17:31 schrieb Joakim Erdfelt:
> >> Eclipse Jetty dev here.
> >>
> >> We've been using slf4j 2.0.x for production servers since Dec 2020
> >> without issue.
> >> It's been highly reliable for the millions of servers that use Eclipse
> >> Jetty 10+.
> >>
> >> We chose slf4j 2.0.x as it properly supported JPMS, which is an
> >> optional execution mode for our server that many folks use.
> >>
> >> - Joakim
> >>
> >
> > That really makes me wonder why slf4j 2.0 has never been released as
> > stable version? The current non-stable situation is a show-stopper for
> > us, we are not allowed to use it in productive code.
> >
> > Thanks,
> >
> > - Daniel
> >
> >> On Tue, Jul 12, 2022 at 9:28 AM Christoph Briem
> >>  wrote:
> >>
> >> Hi all,
> >>
> >> sorry if this has been answered already anywhere else. But I
> >> couldn't find an answer so far.
> >>
> >> We're currently evaluating moving further from Java 11 to Java 17.
> >> We've realized that we also have to update slf4j, to either 1.8.x
> >> or 2.0.x.
> >>
> >> Right now, both minor versions are not marked as stable, and we're
> >> somehow reluctant using an alpha or beta version.
> >>
> >> My question is: What is your recommendation for people moving on
> >> to Java 17? Use 1.8.x or 2.0.0.x? Or wait until a stable release
> >> is out? Or is there a way to get 1.7.x running on Java 17?
> >>
> >> Thanks for your help,
> >> Chris
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [slf4j-user] slf4j for Java 17?

[Joakim Erdfelt]

Eclipse Jetty dev here.

We've been using slf4j 2.0.x for production servers since Dec 2020 without
issue.
It's been highly reliable for the millions of servers that use Eclipse
Jetty 10+.

We chose slf4j 2.0.x as it properly supported JPMS, which is an optional
execution mode for our server that many folks use.

- Joakim

On Tue, Jul 12, 2022 at 9:28 AM Christoph Briem 
wrote:

> Hi all,
>
> sorry if this has been answered already anywhere else. But I couldn't find
> an answer so far.
>
> We're currently evaluating moving further from Java 11 to Java 17. We've
> realized that we also have to update slf4j, to either 1.8.x or 2.0.x.
>
> Right now, both minor versions are not marked as stable, and we're somehow
> reluctant using an alpha or beta version.
>
> My question is: What is your recommendation for people moving on to Java
> 17? Use 1.8.x or 2.0.0.x? Or wait until a stable release is out? Or is
> there a way to get 1.7.x running on Java 17?
>
> Thanks for your help,
> Chris
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [slf4j-user] Question: supporting ALL, OFF level

[Joakim Erdfelt]

While slf4j is just a facade, there's a growing group of features in
various projects that put configuration at the slf4j api level (both at
startup and runtime), not at the slf4j implementation level.

Am I wrong in assuming that the stated scope of this was for this proposal
to have slf4j api level ability?

- Joakim

On Thu, Jan 27, 2022 at 8:42 AM Ceki Gülcü  wrote:

>
>
> On 1/27/2022 2:55 PM, Joakim Erdfelt wrote:
> > I like it.
> >
> > OFF is definitely useful, and should be there.
> >
> > ALL on the other hand seems redundant.
> > Just setting the most noisy level (TRACE in slf4j terms) would be the
> > equivalent end result.
>
> Unless I am forgetting something or getting forgetful, SLF4J does not
> allow users to set levels.
>
> > - Joakim
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [slf4j-user] Question: supporting ALL, OFF level

[Joakim Erdfelt]

I like it.

OFF is definitely useful, and should be there.

ALL on the other hand seems redundant.
Just setting the most noisy level (TRACE in slf4j terms) would be the
equivalent end result.

- Joakim

On Thu, Jan 27, 2022 at 7:37 AM Dongjin Lee  wrote:

> Hi, slf4j community,
>
> I have a question on slf4j-api's Level definition.
>
> As far as I know, the slf4j community is planning to support the dynamic
> logging level change feature with https://jira.qos.ch/browse/SLF4J-124.
> However, since slf4j-api only defines five levels, omitting `ALL` and `OFF`
> (below), we can't call a method like `logger.setLevel(Level.OFF)` - which
> is available in other logging frameworks.
>
>
> https://github.com/qos-ch/slf4j/blob/master/slf4j-api/src/main/java/org/slf4j/event/EventConstants.java
>
> For example, logback supports seven levels (i.e., five common ones + ALL,
> OFF):
>
>
> https://github.com/qos-ch/logback/blob/master/logback-classic/src/main/java/ch/qos/logback/classic/Level.java
>
> Log4j supports 8 levels (i.e., five common ones + FATAL, ALL, OFF):
>
>
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Level.html
>
> Java's official logging level definition is a little bit different, but
> they also support ALL, OFF:
>
> https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html
>
> So, in my humble opinion, to make the dynamic logging level change feature
> more complete, slf4j-api is much better to support ALL and OFF levels. What
> do you think?
>
> If you agree and open an issue, I am willing to contribute.
>
> Best,
> Dongjin
>
> --
>
> Dongjin Lee
>
> A hitchhiker in the mathematical world.
>
> github: github.com/dongjinleekr
> keybase: https://keybase.io/dongjinleekr
> linkedin: kr.linkedin.com/in/dongjinleekr
> speakerdeck: speakerdeck.com/dongjin
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [slf4j-user] slf4j-api.jar

[Joakim Erdfelt]

No version of the slf4j-api jar is impacted by the two recent log4j2
vulnerabilities (CVE-2021-44228 and CVE-2021-45046)

- Joakim

On Fri, Dec 17, 2021 at 4:34 AM EDMONDO SENA  wrote:

> Good Morning,
>
> I wanted to know if the following jar version slf4j-api 1.5.2 is impacted
> by the log4j 2.13.0 vulnerability.
>
> Kind regards.
> //Edmondo.
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [slf4j-user] Release of SLF4J version 2.0.0-alpha5

[Joakim Erdfelt]

Thank you for the release.

Eclipse Jetty has been at 2.0.0-alpha4 since it was released.
We've been using it successfully on classpath and module-path.

Started the upgrade to 2.0.0-alpha5 now -
https://github.com/eclipse/jetty.project/pull/6684

- Joakim

On Mon, Aug 30, 2021 at 11:35 AM Ceki Gülcü  wrote:

> Hello all,
>
> I am pleased to announce SLF4J 2.0.0-alpha5.  This release fixes
> an issue with Java Platform Logging API (JEP 264) support when
> running under the class-path (but not the module-path). JEP 264
> support is new in SLF4J 2.0.0-alpha4.
>
> The 2.0.x series introduces a backward-compatible fluent logging
> API.  By backward-compatible, we mean that existing logging
> frameworks do not have to be changed in order for the user to
> benefit from the fluent logging API. However, existing frameworks
> *must* migrate to the ServiceLoader mechanism. The resulting
> internal changes are detailed in the FAQ page.
>
>http://www.slf4j.org/faq.html#changesInVersion200
>
> The  2.0.x series  builds upon  the  the 1.8.x  series which  was
> modularized per Java Platform Module System (JPMS/Jigsaw).
>
> The 2.0.x series requires Java 8.
>
> Please  refer to  the  the news  page for  more  details on  this
> release:
>
>  http://www.slf4j.org/news.html
>
> Binary compatibility:
>
> Mixing mixing different versions of slf4j-api.jar and SLF4J
> provider can cause problems.  For example, if you are using
> slf4j-api-2.0.0.jar, then you should also use
> slf4j-simple-2.0.0.jar, using slf4j-simple-1.5.5.jar will not
> work.
>
> With the exception of the fluent API (new in SLF4J 2.0.x), from
> the client's perspective all versions of slf4j-api are
> compatible. Client code compiled with slf4j-api-N.jar will run
> perfectly fine with slf4j-api-M.jar for any N and M.  You only
> need to ensure that the version of your provider matches that of
> the slf4j-api.jar. You do not have to worry about the version of
> slf4j-api.jar used to compile a given dependency in your
> project. You can always use *any* version of slf4j-api.jar, and
> as long as the version of slf4j-api.jar and its provider match,
> you should be fine.
>
> Downloading SLF4J:
>
> You can download SLF4J, including full source code, class files
> and documentation on our download page:
>
>   http://www.slf4j.org/download.html
>
> Announcement mailing list:
>
> You can receive SLF4J related announcements by subscribing to the
> SLF4J announce mailing list.  To subscribe to QOS.ch announce
> list, please visit the following URL.
>
> http://www.qos.ch/mailman/listinfo/announce
>
> You may also receive announcements via twitter:
>
> https://twitter.com/qos_ch
>
> Enjoy,
>
> --
> Ceki Gülcü
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [slf4j-user] Signatures for verifying Slf4j

[Joakim Erdfelt]

In light of all of the effort to mitigate and/or track supply chain
vulnerabilities, and the fact that you are currently using pgp, perhaps you
should also sign your git commits?

git config --global user.signingKey 
git config --global commit.gpgSign true

https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/signing-commits


- Joakim

On Thu, Jul 8, 2021 at 7:42 AM Ceki  wrote:

>
> Hi Elisha,
>
>
> All SLF4J artifacts published on Maven central are signed. For each
> artifact, there is an associated signature file with the
> ".asc" suffix.
>
> To verify the signature use the key found at
>
> www.slf4j.org/public-keys/ceki-public-key.pgp. It has the
> following fingerprint:
>
> pub   2048R/A511E325 2012-04-26
> Key fingerprint = 475F 3B8E 59E6 E63A A780  6748 2C7B 12F2 A511 E325
> uid   Ceki Gulcu 
> sub   2048R/7FBFA159 2012-04-26
>
> See gnupg documentation on how to verify signatures.
>
> Best regards,
>
> --
> Ceki Gülcü
>
> On 07.05.2010 09:26, Elisha Ebenezer wrote:
> > Hi Ceki,
> > I'm trying to push to use Slf4j and logback in our project and my
> > company wants me to get the MD5 or SHA1 hashes or the code-signing certs
> > to verify the integrity of downloaded files.
> >
> > Though repo1.maven.org  site provides the
> > hashes, we are not sure whether the war and the hash are uploaded by
> > genuine party or not.
> >
> > As you are the owner of the project, I request you to kindly publish the
> > hashes or certs on website's download page.. which can be cross-checked
> > with the downloaded war and/or also with the maven repository.
> >
> > Kindly do the needful and oblige.
> >
> > Thanks,
> > Elisha Ebenezer.
>
>
> ___
> slf4j-user mailing list
> slf4j-user@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user

Re: [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  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 

[slf4j-user] Slf4j 2.0 future

[Joakim Erdfelt]

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

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)
___
slf4j-user mailing list
slf4j-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-user