FELIX-6869 - Run the HTTP integration tests on a current JDK and on this framework

[paulrutter]

FELIX-6869. Was stacked on #554, which is now merged; rebased onto master and targets it directly. The second commit depends on the FilterImpl fix from #554.

1. The integration tests cannot run on JDK 27

JettySniHostCheckIT times out after 30 seconds waiting for an HttpService that never registers; the pax-exam container log gives the reason:

org.apache.aries.spifly.dynamic.bundle [Events.Framework] ERROR : FrameworkEvent ERROR
java.lang.ClassFormatError: Weaving hook failed.
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 71

AbstractJettyTestSupport.spifly() provisions ASM as separate bundles pinned to 9.7, and Aries SpiFly wires to them through its org.objectweb.asm;version="[9.6,10)" import. ASM 9.7 only knows up to class file 67 (Java 23), so on JDK 27 SpiFly's weaving hook throws for every class it is asked to weave and Jetty never finishes starting.

The five ASM bundles move 9.7 → 9.10.1, which declares V27 = 71 and still satisfies SpiFly's import range, so SpiFly itself is untouched. Bumping SpiFly to 1.3.8 instead does not work: its Import-Package changed and the container is then left with There are unresolved bundles.

Nothing here is specific to SNI or TLS — the test keystore is current (PBES2/AES-256, 2048-bit RSA, SHA384withRSA) and Jetty 12.1.14 starts normally up to the weaving failure. JettySniHostCheckIT is just the test that waits on a service that never arrives.

2. The integration tests ran on a released framework, not this one

http/jetty/pom.xml and http/jetty12/pom.xml pinned org.apache.felix.framework 7.0.5, so pax-exam always started them on that framework rather than the one built here. They therefore could not catch a framework regression — and did not:

framework the ITs run on	JettySniHostCheckIT
7.0.5 (released, pre-regression)	✅
master's 7.1.0-SNAPSHOT	❌ expected:<200> but was:<404>
master + #554's FilterImpl fix	✅

Filter.matches(Map) was throwing for any non-empty map, so the whiteboard servlet never registered. That is the regression #554 fixed. Switching the ITs to the in-repo framework before that fix landed turned them red, which is why this PR waited on it.

The version becomes a felix.framework.version property, still defaulting to the latest release so each module continues to build standalone, and CI overrides it with the version it just built:

FRAMEWORK_VERSION=$(mvn -B -q --file framework/pom.xml help:evaluate -Dexpression=project.version -DforceStdout)
mvn ... -Dfelix.framework.version=$FRAMEWORK_VERSION

For that the framework must be installed first, so the Felix Framework step moves ahead of Felix HTTP and runs when either framework or http changed — otherwise an http-only PR would find nothing to resolve. It already used install rather than verify for the TCK, for the same underlying reason.

Verification

build	result
http/jetty12 verify against framework 7.1.0-SNAPSHOT	✅ 21 integration tests
http/jetty verify against framework 7.1.0-SNAPSHOT	✅ 4 integration tests
framework FilterTest (from #554)	✅ 4 tests

JDK 27 itself is verified indirectly — I have no 27 locally — by ASM 9.7's Opcodes topping out at V23 = 67 while 9.10.1 declares V27 = 71. The original failure is this run on #433, which added 27 to the matrix and has since removed it pending this fix.

Still open

The pinning is repo-wide and worse elsewhere: scr pins framework 7.0.1, rootcause and systemready 6.0.5, eventadmin/impl 6.0.3, configadmin and healthcheck/core 7.0.5, plus siblings such as framework.security 2.8.3 — an artifact the 8.0.0 line removes. Worth its own issue; this PR only covers the two HTTP modules.

🤖 Generated with Claude Code