Repository navigation
JGit runtime logs are spamming debugger console #3022
Description
Likely regression from recent equinox related changes, something like eclipse-platform/eclipse.platform.releng.aggregator@21a4baf.
Probably related similar problem: 4576939
Start Eclipse application from debugger (with JGit in the target platform). The workspace in the debuggee should have a project connected to git.
Almost every click in that project connected to git results in multiple logs printed to console, so that seeing relevant output is not possible anymore.
!ENTRY org.eclipse.jgit 0 0 2026-10-13 12:01:10.218
!MESSAGE file=/home/aloskuto/.config.kde5/jgit/config, isRacyClean=false, read=2026-10-13 12:01:08.025084294, lastModified=2026-10-13 07:30:56.842116324, delta=16211182967970 ns, racy<=2500000000 ns
!ENTRY org.eclipse.jgit 0 0 2026-10-13 12:01:10.218
!MESSAGE file=/home/aloskuto/.config.kde5/jgit/config, is unmodified
!ENTRY org.eclipse.jgit 0 0 2026-10-13 12:01:10.218
!MESSAGE file=/home/aloskuto/.gitconfig, isRacyClean=false, read=2026-10-13 12:01:08.036311362, lastModified=2026-03-03 13:54:18.125214000, delta=19343209911097362 ns, racy<=2500000000 ns
!ENTRY org.eclipse.jgit 0 0 2026-10-13 12:01:10.218
!MESSAGE file=/home/aloskuto/.gitconfig, is unmodified
!ENTRY org.eclipse.jgit 0 0 2026-10-13 12:01:10.218
!MESSAGE file=/data/git/org.eclipse.emf/.git/config, isRacyClean=false, read=2026-10-13 12:01:08.094109207, lastModified=2024-05-13 09:06:34.210298795, delta=76301673883810412 ns, racy<=2500000000 ns
Activity
iloveeclipse commentedon Oct 13, 2026
@HannesWell : could you please check?
iloveeclipse commentedon Oct 13, 2026
OK, closing
org.eclipse.equinox.slf4jproject I had opened in my "SDK" workspace fixed the issue. Not sure if it was always there and I just per occasion opened the project recently? I usually had most of SDK projects opened to see possible errors after nightly builds.laeubi commentedon Oct 13, 2026
I always planned to add support for configuring log levels for the Equinox Log but until now not gotten time for it. Apart from that it might be a bit random (unless you use a product) what log provider is chosen if there are multiple and do not configure wich one should be preferred and sometimes PDE is/was a bit to greedy here see eclipse-pde/eclipse.pde#1618
merks commentedon Oct 13, 2026
Yes, it's the identical problem. This happens opening help:
Using
-Declipse.log.level=WARNINGworks well too.I believe some slf4j provided is required and I'm not sure how one is chosen. Maybe all providers are chosen...
laeubi commentedon Oct 13, 2026
Technically slf4j want at least one, if multiple are provided I think it chooses the first (and maybe gives a warning) unless you specify a system property https://www.slf4j.org/faq.html#explicitProvider
merks commentedon Oct 13, 2026
Yes, Hannes explained some of the details around this with our problems over the weekend.
Thee are two "choices" here
I was more alluding to the former rather than the latter. The launch I'm using only specifies features:
I don't think any features include any slf4j service provider bundle.
laeubi commentedon Oct 13, 2026
Contrary to the name you can also add bundles to a feature launch
merks commentedon Oct 13, 2026
I know. But I want to remove equinox slf4j. 🤪
laeubi commentedon Oct 13, 2026
Not sure I understand... It should not be part of any feature (so not selected by default) but might get picked up (randomly) if you have not chosen an SLF4J provider in the run as PDE wants to satisfy the requirement of the API. If you now select your preferred one (e.g.
simpleas in my screenshot ornoop) it should not bother to include theequinoxone.HannesWell commentedon Oct 13, 2026
Yes! That's a very important point to highlight in this discussion and we should push-pack on any idea in this direction to solve such issues. Adding any logging implementation to a feature force all users of that feature to use that logging impl, but it's very likely not suitable for everyone.
Yes, that's what's happing. Basically PDE choses one among all slf4j providers in the TP. But it seems to prefer org.eclipse.equinox.slf4j over slf4j.simpl, probably because it's alphabetically lower. I've described the details in
Yes that works well and solve it.
Yes. Since
equinox.slf4jseems to be choose often, I propose to set the default log level of it to WARNING. Many other log impls are often relatively quiet by default.HannesWell commentedon Oct 13, 2026
Like suggested in #3008 (comment), one can also just set the VM argument
-Dslf4j.provider=org.slf4j.helpers.NOP_FallbackServiceProvider.iloveeclipse commentedon Oct 13, 2026
Where should it be set?
laeubi commentedon Oct 14, 2026
Thanks for asking, Andrey, and thanks Hannes for collecting the workarounds.
I'm not convinced a new default level is the right fix:
INFO, that may deserve a look on its side instead.equinox.slf4jis a bridge for libraries that use SLF4J and were silent so far. It enables us to improve this further, so I'd like to avoid a quick fix that mostly helps platform development and that regular users hardly face.As for where it could live, there is already a proposal for the proper solution: eclipse-equinox/equinox#26 (and related discussion eclipse-equinox/equinox#20).
It asks for an Equinox property to provide default levels per logger, overridable via Config Admin/
LoggerAdmin.With that, the debug launch could e.g. set the JGit logger to
WARNINGwithout touching the globaleclipse.log.level.I think that would be the better investment (and I'm happy to look into it).
Meanwhile the existing workarounds apply:
slf4j.simple/slf4j.nop)-Dslf4j.provider=org.slf4j.helpers.NOP_FallbackServiceProvider-Declipse.log.level=WARNINGA longer-term improvement could be that PDE asks the user to choose when several providers are candidates, but that is more complex and should be tracked separately.
merks commentedon Oct 14, 2026
As a reminder so that it's not forgotten in the JGit focus of this issue,
Jetty is also doing a lot of info logging, we see this opening the help system:
#3022 (comment)
Also client5 as used by p2/ECF:
I spent hours "fixing" this problem without understanding the cause of the logging because I didn't realize the Eclipse Installer was pulling in an arbitrary logging providing. The copious logs ended up killing my ci instance. The build job logs where full of noise that the jobs didn't finish (logging takes long) and left enough garbage behind in the job logs that the instance exhausted storage. This was a seriously big waste of my time...
So I wonder if there are other IDE/RCP products out there that will end up with a logging implementation that kicks in automatically now with the new spi implementation and will do trace level logging. There's no way to know...
laeubi commentedon Oct 14, 2026
I understand that this can be frustrating, and tracking down where unexpected logging comes from can cost a lot of time (and even CI resources).
There is certainly room for improvement here.
I'd still like to separate a few things:
INFO.It is not the task of a logging provider to "fix" that, what is important enough differs between projects, so any default will be wrong for someone.
slf4j-apionly requires at least one provider.The provisioning/launch tooling resolves that requirement and has to pick one of the candidates, if several are available and nothing constrains the choice.
org.eclipse.equinox.slf4jexists since January 2025 (eclipse-equinox/equinox@b2d950e, released with 4.35), so it is not something recent.The Installer is provisioned by p2, which has to make the same choice, so this is a general problem with different possible solutions.
The general rule is that whoever ships
slf4j-apishould explicitly choose the backend.EPP did that already in 2023:
eclipse-packaging/packages#43 and eclipse-packaging/packages#48 (always include
slf4j.simpleorm2e.logback).For the Installer the same should be possible, i.e. explicitly include the backend you want.
What I agree is a problem is discoverability, nothing told you where the logs came from.
Ideas to track separately:
laeubi commentedon Oct 14, 2026
A correction to my previous comment: the new SPI support is part of the story, I missed a subtle difference.
ACTIVE.RESOLVED.So
org.eclipse.equinox.slf4jwas most likely already picked by PDE/p2 before, but as it was never started, SLF4J did not find the provider and silently ran without one.Nobody noticed that the "wrong" backend was installed.
Now the provider is found, and its output becomes visible.
The root cause is unchanged:
slf4j-apionly requires at least one provider, and the tooling picks an arbitrary candidate if the choice is not constrained.But it explains why this appears now, and that is a fair point to be surprised about.
What it means for next steps:
One option for the framework would be a property to control this behavior (started vs. only resolved providers).
It could default to the old behavior, but @HannesWell, I leave it to you to decide whether that is worth it.
HannesWell commentedon Oct 14, 2026
Yes. But just for completeness, according to its OSGi metadata it requires exactly one provider:
I don't think we should do anything specifically about SLF4J in PDE. Eventually it boils down to managing the runtime and its content.
To make a arbitrary selection of equinox.slf4j less problematic, I proposed to set increase default log-level of the Equinox OSGi Logger:
The addition of equinox.spi is indeed related but not because equinox.slf4j wasn't activated before. It is because apache.aries.spifly needs to be started in order to make ServiceLoader work across OSGi bundle boundaries, while
equinox.spiworks immediately as soon as its in the runtime.Your statement about the difference is still correct.
Yes, we could do that. But in this particular case it wouldn't help because
equinox.slf4jis lazy activated and therefore automatically put inSTARTINGstate by Equinox:https://github.com/eclipse-equinox/equinox/blob/4199391ecf88c6e6d74a9c902d2762f237507475/bundles/org.eclipse.equinox.slf4j/META-INF/MANIFEST.MF#L18
So I think the best solution is to increase the default log-level of the Equinox Logger.