The EE interoperability mode of the Wildfly HTTP client library allows clients and servers using different versions of the Java EE package naming convention (javax or jakarta) to interoperate: a javax client can talk to a jakarta server and vice versa. EE interoperability mode is enabled by setting the system property org.wildfly.ee.namespace.interop to true on both the client and server.

The interoperability handshake can provide incorrect results for the agreed protocol version if the wildfly-config.xml setting <eagerly-acquire-session value/> is set to true. This causes the client to connect to the server before any invocations are made to establish the affinity of the HttpTargetContext. It appears that this handler, defined in the Undertow subsystem class org.wildfly.subsystem.undertow.RemoteHttpInvokerService, is not aware of the EE interoperability handshake and results in an incorrect handshake result.

How To Reproduce:

• make sure that the system property org.wildfly.ee.namespace.interop is set to true in the maven execution "ee-interoperable" in the pom.xml file for the project
• add in a RequestDumpingHandler to the TestServer in the method TestServer.getRootHandler()
• verify that the wildfly-config.xml instance used for the test has <eagerly-acquire-session/> set to true
• run the testsuite using mvn clean install
• look at the test results for the ejb maven module in the surefire-ee-interoperable-reports directory, taking SimpleInvocationTestCase as an example

You should see that although both client and server have system property org.wildfly.ee.namespace.interop=true, the client sends a x-wf-version value of 2 to the server, and the server does not respond with a x-wf-version header which sets the agreed protocol version to 1 for all subsequent invocations. This is likely the effect of the call to set the affinity eagerly which is not aware of the EE interop protocol.