[HannesWell]

Using a default default log level of TRACE (or comparable) by default leads to very verbose logging in cases where the logger is not configured further. Other logging backends usually use higher log-levels by default too.
For example slf4j.simple uses INFO by default:
https://github.com/qos-ch/slf4j/blob/69d28be9fba7a9c0072dfbac8cbee8e40bb965d5/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L188-L189

This surfaced recently since equinox.slf4j recently became activated automatically and seems to be the preferred choice of the Equinox Resolver used for PDE target platforms, if no SLF4J logging backend is added to a runtime:

• JGit runtime logs are spamming debugger console eclipse-platform/eclipse.platform#3022

Using a higher log-level by default would also make it more convenient in the cases a developer is happy with any backend and doesn't want to configure it further.

Fixes eclipse-platform/eclipse.platform#3022

[github-actions]

Test Results

  234 files  +   78    234 suites  +78   50m 26s ⏱️ + 16m 52s
2 231 tests ±    0  2 182 ✅ ±    0   49 💤 ± 0  0 ❌ ±0 
6 456 runs  +2 152  6 343 ✅ +2 114  113 💤 +38  0 ❌ ±0 

Results for commit c5ce84c. ± Comparison against base commit 5608d5d.

♻️ This comment has been updated with latest results.

[HannesWell]

@tjwatson could you please have a look?
If you're fine with this or parts of it, I'll adapt the tests.

[laeubi]

For example slf4j.simple uses INFO by default:

So probably we should use INFO as default then as well? Given that users by default has not much influence about it the Eclipse-Log is often the only way to get some information usually.

[merks]

I too wondered about the info status because I do see info status logged for "normal logging"...

[HannesWell]

For example slf4j.simple uses INFO by default:

So probably we should use INFO as default then as well? Given that users by default has not much influence about it the Eclipse-Log is often the only way to get some information usually.

Ok, lets do that. It also fixes one of the two test failures without further changes.

In the meantime I've also adapted the only remaining failing test, so the new build should be successful.

@tjwatson could you please have a look at this?
If there are no objections I suggest to submit this tomorrow, Thursday CET evening in time for the M2 build.

[tjwatson]

I think this change is going to remove details out of the eclipse log that we are use to seeing. I think the real problem here is the Equinox slf4j bundle and its use of the Equiniox logger named org.eclipse.core.internal.runtime.PlatformLogWriter.EQUINOX_LOGGER_NAME which has always had all levels enabled for persistent to the eclipse log by default.

equinox/bundles/org.eclipse.equinox.slf4j/src/org/eclipse/equinox/slf4j/EquinoxLoggerFactory.java

Line 49 in 53e3dbb

: service.getLogger(b, PlatformLogWriter.EQUINOX_LOGGER_NAME, Logger.class);

It is unclear to me why that line is not using the logger name passed in by the slf4j user.

[tjwatson]

I don't think the right fix is to default the equinox logger named org.eclipse.equinox.logger to INFO as I think that may have unexpected behavior from before for eclipse plugins using the Eclipse Log class. Instead I think the Equinox slf4j bundle should use the logger names passed from the slf4j APIs so they can be configured independently of the org.eclipse.equinox.logger logger.

[tjwatson]

I don't think this does anything useful as the default because this ends up getting set by the LoggerContext settings which, if not set at all then it defaults to WARN from

equinox/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/log/EquinoxLogServices.java

Line 93 in 53e3dbb

LogLevel defaultLevel = LogLevel.WARN;

[tjwatson]

Note that the Eclipse logger writer currently only persists ERROR log entries from other logger names. See

equinox/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/log/EquinoxLogWriter.java

Line 764 in 53e3dbb

return loggableLevel == LogService.LOG_ERROR;

So if slf4j does use its own names then only errors will be persisted in the Eclipse log file no matter what, unless we change this.

[laeubi]

Instead I think the Equinox slf4j bundle should use the logger names passed from the slf4j APIs so they can be configured independently of the org.eclipse.equinox.logger logger.

To clarify, the purpose of the equinox.slf4j actually is to use the org.eclipse.equinox.logger so it behaves like if one is using for example ILog so one can integrate libraries that do not use this facility. If one just wants generic OSGi Logger integration then there is already slf4j-osgi. Still independently it would be good to have a bit more fine grained control as obviously any Eclipse Plugin can spam the log using ILog anyways.

So we just got into the situation, because previously spifly was active only when started (what usually is not the case by default) and our implementation is more lenient regarding lazy bundles (see osgi/osgi#973). So in general one would say everything works as expsected here anyways.

The real culprit is that neither PDE nor P2 currently has a strategy to ask the user if there are multiple possible choices for a capability and then choose just one randomly, while e.g. a user could actually already influence this by explicitly choosing e.g. slf4j-noop or slf4j-simple explicitly. equinox.slf4j on the other hand is not included in any feature so we do not enforce it in any way.

What I can think about to possibly improve the situation is that equinox.slf4j itself defines a threshold level (e.g. INFO by default) where it ignores the log before forwarding it to the Equinox logger (regardless of whats enabled there). This also has the advantage that we only change in that area and can leave the actual implementation alone.

[tjwatson]

It is strange that the org.eclipse.equinox.logger logger name is used to send all slf4j named loggers to the osgi log and the original slf4j logger name is ignored and lost in the persisted eclipse log. Also the org.eclipse.equinox.logger logger name can be configured for using the option eclipse.log.level.

But now we need a threshold level configuration for equinox.slf4j? What should happen if that conflicts with the eclipse.log.level value? I feels like we should enhance the equinox log writer to allow other logger names be forwarded to it and the slf4j lets it know the logger names it should listen to.

For the current release we likely will need to do what you suggest to get something done for the short-term. But I do think there is a better way we can get slf4j to map to the osgi logger and if there is already one that does map to the osgi logger then perhaps we just need to enhance the equinox log writer to properly listen to other logger names when configured.

[laeubi]

It is strange that the org.eclipse.equinox.logger logger name is used to send all slf4j named loggers to the osgi log and the original slf4j logger name is ignored and lost in the persisted eclipse log.

As said this is meant really as a bridge between ILog (what has no concept of logger name either and we just mention the plugin that logs the message) and slf4j so given the context it makes somehow sense to me and this is also shown in my example here:

!ENTRY my.logging.bundle 2 0 2025-02-09 08:49:42.376
!MESSAGE I warn you!

!ENTRY my.logging.bundle 1 0 2025-02-09 08:49:42.377
!MESSAGE This is an info

!ENTRY my.logging.bundle 0 0 2025-02-09 08:49:42.377
!MESSAGE Debug

Maybe there are other ways but at least this is consistent with how log messages appear when using logging from an usual eclipse plugin.

But now we need a threshold level configuration for equinox.slf4j?

I would not say we strictly need it, as mentioned elsewhere, a user/product should simply choose what fits best, if equinox.slf4j narrow use-case does not fit there a numerous alternatives. It was just an idea (and nothing speak against this in my opinion) that it might be practical to allow configuration of what messages the bridge forward if we do not want (yet) supply any further configuration among a global logging level for the Equinox logger itself.

What should happen if that conflicts with the eclipse.log.level value?

Just to clarify, as of today the user has no way to silence eg. jdt verus pde or egit or ... It just has shown that libraries using slf4j make much more use of TRACE messages than usual ILog users, so capping this a bit given it is not otherwise configurable seems a valid solution and being independently e.g lets say I set the threshold higher I will just get less things logged e.g. I set it to ERROR because I'm mostly interested in error messages from other plugins. On the other hand if I set it to a lower level then they will just be filtered on the equinox logger level - what also is valid, so they do not really compete, they just work on a different layer of abstraction.

[eclipse-equinox-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.equinox.slf4j/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From fe6045390dfb78380007ada27378cde5731248e5 Mon Sep 17 00:00:00 2001
From: Eclipse Equinox Bot <equinox-bot@eclipse.org>
Date: Thu, 12 Nov 2026 07:21:09 +0000
Subject: [PATCH] Version bump(s) for 4.42 stream


diff --git a/bundles/org.eclipse.equinox.slf4j/META-INF/MANIFEST.MF b/bundles/org.eclipse.equinox.slf4j/META-INF/MANIFEST.MF
index fa53bdf3d..23e413156 100644
--- a/bundles/org.eclipse.equinox.slf4j/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.equinox.slf4j/META-INF/MANIFEST.MF
@@ -4,7 +4,7 @@ Bundle-Name: %bundleName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
 Bundle-SymbolicName: org.eclipse.equinox.slf4j
-Bundle-Version: 1.0.300.qualifier
+Bundle-Version: 1.0.400.qualifier
 Import-Package: org.eclipse.equinox.log;version="[1.1.0,2.0.0)",
  org.osgi.framework;version="[1.10.0,2.0.0)",
  org.osgi.service.log;version="[1.5.0,2.0.0)",
-- 
2.56.0

Further information are available in Common Build Issues - Missing version increments.

[HannesWell]

As discussed (also in private conversations) I've changed this PR to just introduce a defaultLogLevel in equinox.slf4j which acts as first filter. This way no logger in org.eclipse.osgi is changed.
I've introduced a system property named equinox.slf4j.defaultLogLevel to control it, whose default is INFO.
To restore the previous behavior one can consequently set on the CLI or in the ini -Dequinox.slf4j.defaultLogLevel=TRACE.

This is similar to slf4j-simple:

• https://github.com/qos-ch/slf4j/blob/69d28be9fba7a9c0072dfbac8cbee8e40bb965d5/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L221
• https://github.com/qos-ch/slf4j/blob/69d28be9fba7a9c0072dfbac8cbee8e40bb965d5/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLoggerConfiguration.java#L31

[laeubi]

Looks all fine to me and only changes the slf4j part so it seems safe.