paulrutter opened a new pull request, #571: URL: https://github.com/apache/felix-dev/pull/571
[FELIX-6869](https://issues.apache.org/jira/browse/FELIX-6869). The Felix HTTP 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 change The five ASM bundles move **9.7 → 9.10.1** in both `http/jetty` and `http/jetty12`. 9.10.1 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 substantially and the test container is then left with `There are unresolved bundles`. Keeping SpiFly at 1.3.7 and moving only ASM is the smaller and working fix. 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 simply the test that waits on a service that never arrives. ### Verification | build | result | |---|---| | `http/jetty12` full `verify` on JDK 21 | ✅ 21 integration tests | | `http/jetty` full `verify` on JDK 21 | ✅ 4 integration tests | I have no JDK 27 locally, so the 71 path itself is verified indirectly: ASM 9.7's `Opcodes` tops out at `V23 = 67` while 9.10.1 declares `V27 = 71`. CI on a 27 job would confirm it end to end — the failure was originally seen in [this run](https://github.com/apache/felix-dev/actions/runs/37895895493/job/113707041240) on #433, which added 27 to the matrix and has since taken it back out pending this fix. ### Not addressed here FELIX-6869 also records that the HTTP ITs pin `org.apache.felix.framework` **7.0.5** in `http/jetty12/pom.xml` and `http/jetty/pom.xml`, so pax-exam always runs them against that released framework rather than the one in the repo. Worth noting 7.0.5 is still the *latest release* (May 2022), so this is not a stale pin so much as a choice to test against the last release. Changing it to the reactor version would mean the framework has to be built and installed first, which the per-module CI layout does not currently do, and it would change what these ITs actually cover. That seems worth deciding separately, so I have left it and the issue open for it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
