[rishabhdaim]

Summary

Compile Oak libraries against SLF4J 1.7.36 to prevent accidental use of 2.x-only APIs. Preserve the modern logging stack introduced by OAK-10339 for runnable tools, benchmarks and examples.

Changes

• Let bnd infer ordinary 1.7 package imports; remove the shared wildcard and child import overrides.
• Use Logback 1.2.13 for library tests. Runtime modules retain SLF4J 2.0.20 and Logback 1.6.4.
• Preserve embedded dependency logging requirements: oak-blob-cloud imports org.slf4j.event with [1.7,3), and oak-search-elastic preserves Commons Logging 1.3.5's declared org.slf4j.spi range [1.7,3). These are dependency-specific exceptions, not a claim that SLF4J guarantees compatibility for the entire SPI package.
• Exercise the embedded Commons Logging bridge through LogFactory.getLog and the actual SLF4J provider, including enabled/disabled levels, throwable identity, and caller location. Start the logging provider before framework consumers and prevent Maven-classpath provider leakage in the OSGi fixture.
• CI reruns selected 1.7-compiled library tests on the modern stack without recompilation.

Test Plan

• Whole-project clean build/install with tests skipped. Child RAT checks passed; only the root aggregate check was bypassed for unrelated workspace files.
• Focused logging tests on both stacks, including the modern runnable logging initializer.
• Ordinary library import-contract checks on both stacks.
• Strengthened OSGiIT: all 9 tests pass on SLF4J 1.7.36 / Logback 1.2.13 and SLF4J 2.0.20 / Logback 1.6.4. Removing the SPI override reproduces two LocationAwareLogger loading errors; restoring it passes.
• Regression reproduced before the cloud exception; cloud mandatory logging requirements match the actual SLF4J provider alone on both stacks afterward.

The cloud check validates logging requirements, not configured S3 activation or optional SDK SPI linkage.

Links

• https://issues.apache.org/jira/browse/OAK-12503
• https://issues.apache.org/jira/browse/OAK-10339

Co-Authored-By: GitHub Copilot copilot@github.com

Co-Authored-By: OpenAI Codex noreply@openai.com

[kwin]

Widening the import version range is not reasonable. Either you leverage 1.x API or 2.x. The latter is largely backwards compatible therefore SLf4J 2.x also exports 1.x package versions. However 2.x adds new API clearly not provided by 1.x. So in order to be compatible with both you should:

• depend on 1.x API only
• import 1.x package versions only

otherwise an Oak bundle may non deliberately depend on SLF4j (but incorrectly resolve with SLF4J 1.x) and fail at run time.

[reschke]

Having to override this in all POMs is not really attractive.

We need to understand why we got here. @mbaedke - given that we know that we can run with SLF4J, do we really need to compile against 2.x?

[mbaedke]

@reschke, no we don't have to compile against 2.x. We just migrated to 2.x because we could.

[reschke]

ok, so just go back to slf4j 1.x

[mbaedke]

ok, so just go back to slf4j 1.x

That's what this PR does, right? (plus testing with 2.x).
@rishabhdaim I'm wondering how we know for sure that commons-logging (requiring 1.x) will work with the LocationAwareLogger from 2.x? Same for aws and the Level API.

[rishabhdaim]

@mbaedke thanks for review.
Your concern was valid i.e. widening the import ranges alone does not demonstrate runtime compatibility.
I have added an regression in f492b58 exercising the embedded Commons Logging location-aware adapter and AWS SDK Level logging against a test-owned Logback backend, asserting delivery and severity at all five levels with SLF4J 1.7.36 and 2.0.20; CI covers both, while library compilation remains on 1.7.

[kwin]

This increased import range I consider still wrong. The default one from Bnd is correct and SLF4J still exports package version 1.x.

[rishabhdaim]

I checked the generated manifests and ran the OSGi tests with and without the override.

With SLF4J 1.7.36, bnd 6.3.1 generates org.slf4j.spi;version="[1.7,2)" by default.

SLF4J 2.0.20 exports org.slf4j.spi only at version 2.0.20.
Its additional 1.7.36 compatibility exports cover org.slf4j and org.slf4j.helpers, but not org.slf4j.spi.

See SLF4J’s export configuration.

Without the override, bnd generates [1.7,2), which rejects SLF4J 2.0’s SPI package.

I reproduced the resulting LocationAwareLogger loading failure; restoring [1.7,3) made the tests pass.

[kwin]

org.slf4j.spi is not backwards compatible, only org.slf4j. Widening the import version range doesn't make it magically backwards compatible either. That the test don't run into issues probably just proofs that they are not complete. See discussion at qos-ch/slf4j#358 and https://jira.qos.ch/browse/SLF4J-579.
Particularly pay attention to

The package-info for org.slf4j.spi states that this package should not be used by clients.

[rishabhdaim]

Agreed that SLF4J does not guarantee compatibility for the entire SPI package; this exception preserves the embedded Commons Logging 1.3.5 bundle's own optional [1.7,3) SPI import.

In 110fe7d0c0, I clarified the POM comment and changed the test to use LogFactory.getLog with the real OSGi provider, checking enabled/disabled levels, throwable identity and caller location: all 9 OSGi tests pass on both SLF4J 1.7.36 / Logback 1.2.13 and SLF4J 2.0.20 / Logback 1.6.4, while removing the override reproduces two LocationAwareLogger loading errors.

[mbaedke]

Ok, so commons-logging itself has a widened import range there, no problem. The AWS SDK apparently only uses org.slf4j.event.Level without calling any 2.x-specific methods, so it will work de facto with the widened range (and apparently it used to work in Oak with 1.x in the past and 2.x now), so I guess we can do this. But I'd really prefer if we keep this temporary and go fully 2.x ASAP.

[rishabhdaim]

@mbaedke, yes, the goal is that this is a temporary arrangement, and we would probably remove the support for 1.x in future releases.

[rishabhdaim]

@kwin @mbaedke if the changes looks fine, can we go ahead and merge this PR now ?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud