In my work on WFLY-16619 (convert testsuite/integration/legacy-ejb-client to jakarta.* namespace) there are two aspects I'm handling:

1) Server side code. This is straightforward; it needs to migrate to jakarta.*, compile against EE 10 APIs etc.

2) Client side code. This aspect is the question. It needs to compile/run against jboss-ejb-client-legacy; that's the whole point of the TS. But otherwise should it use 'legacy' (EE 8 / javax) deps, or move to jakarta.* For WFLY-16619 I chose to use 'legacy' deps. This JIRA is to track validating that choice and adjusting accordingly.

The choice depends on what the intended use case of jboss-ejb-client-legacy is in an EE 10+ world.

Option A is it's for users who have an existing EE < 9 client-side app and they want it to run unchanged. And then the server side is responsible for detecting such a client and not sending jakarta.* types to it. We have JIRAs for that. So if that's the intended use case, the client side code in testsuite/integration/legacy-ejb-client would stay on java.*. This is the route I chose when doing WFLY-16619.

Option B is we'd expect users to update source for javax->jakarta or bytecode transform their app using Batavia or Eclipse Transformer directly. In that case the testsuite/integration/legacy-ejb-client client-side could should be updated to use jakarta.*, to mimic what we'd expect users to do.

Note that if we go with Option A, there are two methods in EJBClientAPIUsageTestCase that should have an @Ignore removed. Those two fail because they are testing exception handling and expect javax.ejb.EJBException to be thrown, but currently jakarta.ejb.EJBException is thrown. IOW, I chose Option A for WFLY-16619, but the needed server-side support is not in place. Once it is those tests can be enabled. Or with Option B we change the expect exception type and remove the ignore.

An interesting case is a couple exception types in the testsuite are annotated with @ApplicationException. I changed those to jakarta.ejb.ApplicationException, as the relevance of that annotation is server-side so it needs to use EE 10 API. But the class itself is also used client-side. I think that's ok with Option A. For such cases the user either updates their client-side code or uses two variants of the exception class, identical except for the annotation.

Yet another twist is EJBClientInterceptorTestCase.testEJBClientInterceptionFromInVMClient(). That test is building a client app using jboss-ejb-client-legacy but running it inside the server vm (where it uses jboss-ejb-client). It works, but is an edge case. And it only works because the 'client side' code isn't compiling against any java.* types. So, as part of this work we should think about that use case.