TOMEE-4643 - discover Feature/DynamicFeature from META-INF/services

[jungm]

Jakarta REST requires Feature and DynamicFeature implementations declared in META-INF/services to be registered through the JDK ServiceLoader at deploy time ("Services", Providers / Lifecycle and Environment).

CXF does not implement this lookup itself — it relies on the container to hand it already resolved providers, which is why the CXF TCK run stays green on GlassFish. TomEE assembles its provider list on its own, so features packaged this way never registered.

Changes

• CxfRsHttpListener scans both SPIs while assembling the provider list.
• Service loading is skipped when the Application maps jakarta.ws.rs.loadServices to Boolean.FALSE, as the spec mandates, and the existing cxf.jaxrs.skip-provider-scanning property is still honoured.
• Entries are loaded one at a time so a single broken descriptor entry is logged and skipped instead of discarding the remaining providers of that type.
• Discovered instances flow through the existing providers(...) path, so the @ConstrainedTo and deactivation checks still apply.
• Drops the now-passing TCK exclusion for jaxrs31/spec/extensions/JAXRSClientIT.

Testing

• New ServiceLoaderProviderDiscoveryTest (8 tests) exercises discovery through a throwaway URLClassLoader, so it does not register these features into other tests in the module. Each assertion was confirmed to fail when the corresponding production change is reverted.
• ee.jakarta.tck.ws.rs.jaxrs31.spec.extensions.JAXRSClientIT passes 2/2 unexcluded against a rebuilt TomEE plus distribution; the wider jaxrs31.** slice passes 4/4.
• Full openejb-cxf-rs suite: 123 tests, the only failure being EJBExceptionMapperTest.security, which fails identically on a clean checkout of main.

🤖 Generated with Claude Code

[jungm]

https://ci-builds.apache.org/job/Tomee/view/tomee-11.x/job/pull-request-manual-with-tck/57/

[rzo1]

@jungm Can you check on ee.jakarta.tck.ws.rs.jaxrs21.ee.sse.ssebroadcaster.JAXRSClientIT.sseBroadcastTest ? Is this a regression?

[jungm]

@rzo1 think its flaky but will check

[jungm]

its flaky, sseBroadcastTest starts 5 SSE clients on threads, waits a fixed 2.5s for them to connect, broadcasts 7 messages, then waits only on the first client before asserting all 5 received exactly 8 events. Clients could not be connecting in time or still be processing evens on a crowded machine

Also seems to have failed in other runs I did here and there