Update EPP for SLF4J v2 changes coming from platform

[jonahgraham]

I am not sure exactly what needs to be done in EPP yet, see eclipse-platform/eclipse.platform.releng.aggregator#588 (comment) for a starting point and the N&N entry https://www.eclipse.org/eclipse/news/4.28/platform.php#slf4j.api-version-2

[jonahgraham]

@HannesWell in the N&N entry it says this:

To fulfill this requirement Eclipse Platform ships org.apache.aries.spifly.dynamic.bundle by default. If you assemble a final application you have to ensure that this bundle is automatically activated during startup. For an Eclipse Product this can be achieved by assigning the Plug-in org.apache.aries.spifly.dynamic.bundle a suitable start-level in the Configuration section of your product.

But in the bundles.info the entry in RC1 is:

org.apache.aries.spifly.dynamic.bundle,1.3.6,plugins/org.apache.aries.spifly.dynamic.bundle_1.3.6.jar,4,false

with the false meaning no autostart which lines up with the product file (sdk, platform).

So does Eclipse Platform achieve this a different way? At the moment EPP is not shipping with any of the 2.x versions of SLF4J as AFAICT the 1.x versions are fufulling requirements and since some of the requirements are strictly on 1.x version the 2.x don't get selected at all.

(Part of my EPP release process is to track changes in the Eclipse Platform files to make sure I match configuration changes - but I didn't notice any changes in this area)

[jcompagner]

that doesn't seem correct to me, not sure when the slf4j stuff are loaded when starting the normal eclipse

But we use aries in our product already for years, and we now ship both slf4j (1.7 and 2.0.x) because 1.7 is forced by eclipse and we use already 2.x our self because also the latest log4j has only bindings for the 2.0.x

If i download the RC1 of eclipse and i start it with:

eclipse.exe -console

i don't see the correct stuff

because if i do that with our product i right away see:

May 31, 2023 5:14:37 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.apache.logging.log4j.jcl.LogFactoryImpl of service org.apache.commons.logging.LogFactory in bundle org.apache.logging.log4j.jcl
May 31, 2023 5:14:37 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.apache.logging.slf4j.SLF4JServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle org.apache.logging.log4j.slf4j2-impl
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
!SESSION 2023-05-31 17:14:35.545 -----------------------------------------------

those are 2 bridges that are installed 1 is apache commons logging to log4j
and the other is slf4j (2.0) to log4j..

The "failed" one that you see is the SLF4J 1.7 because there we don't have any bindings..

But eclipse by default i think installs slf4j-nop ?
So i really wonder how in eclipse itself all the logging works that use slf4j (1.7 or 2.0) it seems that that is to a void?

But currently eclipse itself doesn't really use it at all i think

[jcompagner]

if i change in the RC1 install this:

org.apache.aries.spifly.dynamic.bundle,1.3.6,plugins/org.apache.aries.spifly.dynamic.bundle_1.3.6.jar,4,true

and

slf4j.api,2.0.7,plugins/slf4j.api_2.0.7.jar,4,true
slf4j.nop,2.0.7,plugins/slf4j.nop_2.0.7.jar,4,true

so i just auto start all 3

and then i start with -console:

jun. 01, 2023 9:35:14 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.slf4j.nop.NOPServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle slf4j.nop

my feeling is that eclipse kind of means that to happen?

[HannesWell]

which lines up with the product file (sdk, platform).
So does Eclipse Platform achieve this a different way?

I have to admit that I just forgot that those products are created by Platform directly and have to be updated. I can do that when back from vacation in about 1.5 weeks.

In the meantime it is probably not a too big Deal for the SDK product since it is shipped with the no-op Binding by default, so no logging happens anyway. One probably only gets a extra warning that no provider was found.

Nevertheless at least for those EPPs that have another Backend included (e.g. logback from m2e), should have it to have a working logging.

Regarding the two SLF4J versions in SimRel, I actually started efforts to make slf4j-1 obsolete a while ago, but I don't recall If all changes in other projects are already merged. But I cannot tell it for sure on the Phone.

@jcompagner with the upcomming release there should be much less Plugins/Features that require slf4j-1 (I thought none, but as Jonah said it is still there). Maybe you can already remove it from your product respectivly don't get it added.

And yes as usual there should be only one provider for slf4j-2. But adding one to a product explicitly should be sufficient to not get the no-op included implicitly.

[merks]

FYI, this is what I see in terms of dependencies in SimRel at the moment...

These are the things that strictly require the older version:

And these are the things that require the thing that requires the older version:

So if I read this correctly it's m2e that is is keeping the older version around...

[jcompagner]

yes they ship a older logging implementation that is build for slf4j 1.7
they should upgrade https://mvnrepository.com/artifact/ch.qos.logback/logback-classic/1.4.7

1.4.7 is build for 2.x i see.

i have a bit of a feeling that eclipse should ship something standard? (maybe that logs to the ,log file of eclipse itself?)

[jonahgraham]

I don't think I will be able to do anything for the 2023-06 release. I think we are going to have the same default no-op logger that has been the case for quite a while now:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

In response to both:

I have to admit that I just forgot that those products are created by Platform directly and have to be updated. I can do that when back from vacation in about 1.5 weeks.

and

i have a bit of a feeling that eclipse should ship something standard? (maybe that logs to the ,log file of eclipse itself?)

I think this should start in Eclipse Platform and then EPP should follow that lead. I have raised eclipse-platform/eclipse.platform.releng.aggregator#1094

[HannesWell]

So if I read this correctly it's m2e that is is keeping the older version around...

Thanks Ed. Indeed, the blame is on me 😅
But in my defense, we have to wait for the upcomming Platform release to be able to upgrade to slf4j-2. Then we can also update logback and contribute that to simrel.
But the good news is that this means that application/product builders can use a newer logback version in their TP (or an entirely another Backend) and don't get SLF4J-1 included.

But as Jonah said for the current SimRel we have to live with that situation, but it isn't that bad because consumers can easily overrule the delivered defaults.

and

i have a bit of a feeling that eclipse should ship something standard? (maybe that logs to the ,log file of eclipse itself?)

I think this should start in Eclipse Platform and then EPP should follow that lead. I have raised eclipse-platform/eclipse.platform.releng.aggregator#1094

Yes that is probably a good Idea. We also had the 'problem' that logback shipped with m2e-logback was understood as generell purpose logging Backend for Eclipse. But it was never meant to be that and ist actually only there to catch Maven logs.

[jcompagner]

Just wondering, why is it that if i download the SDK of eclipse (4.28) that aries is included and also the "objectweb.asm" stuff
But if i have a target file that included the Eclipse Platform SDK aries and also suddenly the objectweb.asm jars are not getting there?

most asm stuff was already in eclipse for years, i think i only needed to include myself the "asm.commons" because that one wasn't shipped

The thing is aries does need those, not sure where for (but aries is more a 'weaving' jar right, but we kind of only use it for service loader wiring? i guess it doesn't really need asm for that?)

now i am onl that topic, i always wondered why Equinox doesn't have its own simple implementation for this service loader stuff? Why do we need (kind of an obscure. hidden) external jar for this?

Provide-Capability: osgi.service;objectClass:List<String>="org.slf4j.spi .SLF4JServiceProvider";type=nop;effective:=active,osgi.serviceloader;os gi.serviceloader="org.slf4j.spi.SLF4JServiceProvider";register:="org.sl f4j.nop.NOPServiceProvider";type=nop Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.service loader.registrar)(version>=1.0.0)(!(version>=2.0.0)))",osgi.ee;filter:= "(&(osgi.ee=JavaSE)(version=1.8))"
and

Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.service loader.processor)(version>=1.0.0)(!(version>=2.0.0)))",osgi.serviceload er;filter:="(osgi.serviceloader=org.slf4j.spi.SLF4JServiceProvider)";os gi.serviceloader="org.slf4j.spi.SLF4JServiceProvider",osgi.ee;filter:=" (&(osgi.ee=JavaSE)(version=1.8))"

that stuff "osgi.service", "osgi.extender" and "osgi.serviceloader" that is specified in the specification of osgi right? so i kind of expect that a osgi implementation as Equinox would already have build in support for that.
In the end if you look at it from an Eclipse perspective ServiceLoader stuff is just a simplified extension point mechanism

P.S. if i include now my own slf4j (2.0.x) then with 4.28 1.7 is not there anymore.

[jonahgraham]

With the changes in Platfrom this change will be made in EPP 2023-09 M3 (#40).

Useful xrefs:

• Add silent slf4j-simple to Platform/SDK-products and auto-start Aries SPI Fly and slf4j-simple eclipse-platform/eclipse.platform.releng.aggregator#1195 (comment)
• Move Aries SPIFly bundle after simpleconfigurator to start it afterwards eclipse-platform/eclipse.platform.releng.aggregator#1252

[HannesWell]

@jonahgraham should I provide a PR for the packages, since the exact configuration depends on what is installed (i.e. slf4j-simple oder logback through m2e.logback)?

[jonahgraham]

A PR would be most welcome, I will be looking at this Friday (after M3 contribution from platform to SimRel) and next Thursday which is my EPP day.

[HannesWell]

A PR would be most welcome, I will be looking at this Friday (after M3 contribution from platform to SimRel) and next Thursday which is my EPP day.

Ok, I'll try to provide one at the weekend. But I'll have to do some adjustments in m2e too.

[jonahgraham]

A PR would be most welcome, I will be looking at this Friday (after M3 contribution from platform to SimRel) and next Thursday which is my EPP day.

Ok, I'll try to provide one at the weekend. But I'll have to do some adjustments in m2e too.

Thanks Hannes

[jonahgraham]

The php, committers and scout packages/products are not complete - see a196924 which should be reverted + the necessary fixes to resolve.

[jonahgraham]

This work is now complete - but today on Planning Council call we identified that we should publish this information somewhere - perhaps in a N&N entry for EPP at least (perhaps for Platform too)?

The java, dsl, jee, rcp packages use logback, the rest of the packages use slf4j - for maintainers this is how to tell which is which:

$ git grep -B1 org.eclipse.m2e.logback.feature **/epp.product
packages/org.eclipse.epp.package.dsl.product/epp.product-      <!-- either m2e.logback or slf4j.simple should be provided in each package -->
packages/org.eclipse.epp.package.dsl.product/epp.product:      <feature id="org.eclipse.m2e.logback.feature" installMode="root"/>
--
packages/org.eclipse.epp.package.java.product/epp.product-      <!-- either m2e.logback or slf4j.simple should be provided in each package -->
packages/org.eclipse.epp.package.java.product/epp.product:      <feature id="org.eclipse.m2e.logback.feature" installMode="root"/>
--
packages/org.eclipse.epp.package.jee.product/epp.product-      <!-- either m2e.logback or slf4j.simple should be provided in each package -->
packages/org.eclipse.epp.package.jee.product/epp.product:      <feature id="org.eclipse.m2e.logback.feature" installMode="root"/>
--
packages/org.eclipse.epp.package.rcp.product/epp.product-      <!-- either m2e.logback or slf4j.simple should be provided in each package -->
packages/org.eclipse.epp.package.rcp.product/epp.product:      <feature id="org.eclipse.m2e.logback.feature" installMode="root"/>

In addition, if you run eclipsec.exe (or in a terminal on non-Windows) you should see with logback:

Aug. 26, 2023 9:40:59 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
Aug. 26, 2023 9:40:59 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic

and with slf4j:

Aug. 26, 2023 9:41:44 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.slf4j.simple.SimpleServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle slf4j.simple

Which replaces the long standing message:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

[jonahgraham]

[...] perhaps in a N&N entry for EPP at least (perhaps for Platform too)?

The platform has a N&N entry for what adopters need to do, with EPP being one of them. The N&N is from 4.28 and EPP (and Platform's own products, such as SDK) did the change in 4.29.

The EPP N&N page is tracked in #55

[HannesWell]

This work is now complete - but today on Planning Council call we identified that we should publish this information somewhere - perhaps in a N&N entry for EPP at least (perhaps for Platform too)?

In general I agree but as mentioned in eclipse-platform/eclipse.platform.releng.aggregator#1252 (comment) I'm currently a bit hesitating about that since I don't want to advertise m2e.logback as an 'official' provider and configurator of logback for Eclipse.
Actually logback is just an implementation detail required to make m2e's Maven Console work.
But in the future (hopefully for the december release) I would like to make that more flexible that especially the logback configuration supplied with m2e.logback is not required anymore and that the Maven Console can just work on top of logback bundle configured ordinarily by the provider of the product.
And until then I would like to avoid to give the impression that m2e is committed to manage a logback configuration for Eclipse installations.
If that's desired it should happen in a more neutral location.
In general it might be of interest to provide different features for different logging back-ends (e.g. logback, slf4j-simple, log4j-2) that contain all the necessary bridges to re-direct all other logging APIs (slf4j, log4j-1, log4j-2, jul, apache-commons logging, maybe no-op to cleanly silent logging?) to that particular backend. Besides the logging-backend and the bridges those features could also ensure the proper start configuration of all included bundles and should supply a good default configuration.
Such features could also include means to bridge those usually 'Console'-logs to the Eclipse-Log.
A product builder would then just need to select the Feature for the desired back-end and everthing should just work.
I've started do that for logback at my work, but as far as I can tell it is not yet possible to redirect all logging APIs to any backend, but we are getting better. The last time I checked there were some Plug-ins in the SimRel that still require (and even re-export) log4j-1 or the apache commons logging bundle.
It would be doable if all Plug-ins that need logging would just Import their chosen Logging-API's packages.
And I'm not sure where such Features should be hosted. Eclipse Platform is probably the wrong place since Platform uses its own logging. Maybe even EPP would be a good place.

To make a long-story short, if it is mentioned it would be great if it is focused on slf4j.simple and/or that it is made clear that the m2e.logback feature is probably subject to change in the future.

In addition, if you run eclipsec.exe (or in a terminal on non-Windows) you should see with logback:

Aug. 26, 2023 9:40:59 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
Aug. 26, 2023 9:40:59 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service 

I would not mention the LogbackServletContainerInitializer since it is usually not necessary within the Eclipse IDE and only available due to apache/aries#233.

[jonahgraham]

Thanks @HannesWell - I'll add you to reviewers before it gets published so we don't promise things we don't want to maintain!

[GeekOffTheStreet]

@jonahgraham

and with slf4j:

Aug. 26, 2023 9:41:44 A.M. org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.slf4j.simple.SimpleServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle slf4j.simple

Which replaces the long standing message:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

Is there any way to disable

Feb 09, 2024 5:03:39 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.slf4j.simple.SimpleServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle slf4j.simple

when running from a terminal? None of these did anything:

-Dlog4j.debug=false -Dorg.slf4j.simpleLogger.defaultLogLevel=off -Dorg.slf4j.simpleLogger.log.org.eclipse.jgit=error -Dorg.slf4j.simpleLogger.log.org.apache.aries.spifly=error -Dorg.slf4j.simpleLogger.log.org.slf4j.simple=error -Dorg.slf4j.simpleLogger.defaultLogLevel=off

We use some features of eclipse headless as part of builds and those messages can add a lot of clutter when invoked multiple times.

[merks]

I think this is controlled by org.slf4j.helpers.Reporter.initVerbosity() where I think it's not possible to specify something that will ignore info messages:

    static private Level initVerbosity() {
        String verbosityStr = System.getProperty(SLF4J_INTERNAL_VERBOSITY_KEY);

        if(verbosityStr == null || verbosityStr.isEmpty()) {
            return Level.INFO;
        }

        if(verbosityStr.equalsIgnoreCase("ERROR")) {
            return Level.ERROR;
        }


        if(verbosityStr.equalsIgnoreCase("WARN")) {
            return Level.WARN;
        }

        return Level.INFO;
    }

I suggest using the debugger to see if there is some way, but it appears to me there isn't....