fix: suppress SLF4J startup warning in Tycho test runtime#1299
Draft
joaodinissf wants to merge 2 commits intodsldevkit:masterfrom
Draft
fix: suppress SLF4J startup warning in Tycho test runtime#1299joaodinissf wants to merge 2 commits intodsldevkit:masterfrom
joaodinissf wants to merge 2 commits intodsldevkit:masterfrom
Conversation
Add slf4j.nop 2.0.17 from Eclipse Orbit aggregation 4.39.0 to the DDK target platform. This makes the SLF4J NOP binding available to the OSGi runtime, though due to classloader isolation in OSGi the startup warning cannot be fully suppressed — slf4j.nop is a standalone bundle (not a fragment of slf4j.api), so ServiceLoader-based provider discovery does not find it before SLF4J's first initialization. This is a known limitation shared by Eclipse Platform itself. References: - qos-ch/slf4j#427 - https://github.com/orgs/eclipse-orbit/discussions/24 Also removes unused Import-Package: org.slf4j from three test bundle manifests where no source file references org.slf4j: - com.avaloq.tools.ddk.check.ui.test - com.avaloq.tools.ddk.xtext.test - com.avaloq.tools.ddk.xtext.test.core Retains org.slf4j in com.avaloq.tools.ddk.test.ui — its SwtBot wrapper classes directly use org.slf4j.Logger. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Set -Dslf4j.internal.verbosity=ERROR in the Tycho Surefire argLine to suppress the "No SLF4J providers were found" warning during OSGi test execution. Why this warning occurs: SLF4J 2.x discovers providers via java.util.ServiceLoader, which does not work across OSGi bundle classloaders — slf4j.api's classloader cannot see META-INF/services in the separate slf4j.nop bundle. This is a known limitation shared by Eclipse Platform itself (qos-ch/slf4j#427, eclipse-platform#588). The warning is cosmetic: SLF4J defaults to NOP regardless, which is the desired behaviour for a plugin test suite. Why this approach: The official fix for Eclipse RCP products is to configure start levels in the .product file so that the OSGi Service Loader Mediator (Apache Aries SPI Fly) bridges ServiceLoader across bundle boundaries: <plugin id="org.apache.aries.spifly.dynamic.bundle" autoStart="true" startLevel="2" /> <plugin id="slf4j.nop" autoStart="true" startLevel="2" /> Downstream projects assembling DDK plugins into an RCP product should add these entries to their .product Configuration tab. This wires the NOP provider properly at the product level. For the Tycho Surefire test runtime (which has no .product file), the start-level approach was tested but does not fully work — SPI Fly's asynchronous bundle scanning completes after the first LoggerFactory.getLogger() call, producing the warning before the provider is registered. The slf4j.internal.verbosity system property (available since SLF4J 2.0.10) is the documented way to control SLF4J's internal reporting level, suppressing WARN-level diagnostics while preserving ERROR-level messages. References: - https://www.slf4j.org/faq.html (slf4j.internal.verbosity) - qos-ch/slf4j#427 - https://github.com/orgs/eclipse-orbit/discussions/24 - eclipse-platform/eclipse.platform.releng.aggregator#588 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
rubenporras
approved these changes
Apr 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #1280.
What
Suppress the
SLF4J(W): No SLF4J providers were foundwarning during Tycho Surefire test execution by setting-Dslf4j.internal.verbosity=ERRORin the test JVM arguments.Why
SLF4J 2.x discovers providers via
java.util.ServiceLoader, which does not work across OSGi bundle classloaders —slf4j.api's classloader cannot seeMETA-INF/services/org.slf4j.spi.SLF4JServiceProviderinside the separateslf4j.nopbundle. The warning is cosmetic: SLF4J defaults to NOP regardless, which is the desired behaviour for a plugin test suite.The
slf4j.internal.verbositysystem property (available since SLF4J 2.0.10) is the documented mechanism for controlling SLF4J's internal reporting level. Setting it toERRORsuppressesWARN-level diagnostics while preserving error messages.Downstream RCP products
For projects assembling DDK plugins into an Eclipse RCP product, the proper fix is configuring start levels in the
.productfile so that Apache Aries SPI Fly (the OSGi Service Loader Mediator, shipped with Eclipse Platform) bridgesServiceLoaderacross bundle boundaries:This approach was tested in the Tycho Surefire context but does not fully work there — SPI Fly's asynchronous bundle scanning completes after the first
LoggerFactory.getLogger()call, producing the warning before the provider is registered. The.productconfiguration does not have this timing issue because the product launch sequence ensures proper ordering.Why not fix it in OSGi directly?
The only way to make
ServiceLoaderwork without SPI Fly would be packagingslf4j.nopas a fragment ofslf4j.api(shared classloader). This is an upstream Eclipse Orbit packaging decision. See investigation details in #1280.References
slf4j.internal.verbosity)