https://github.com/wildfly/wildfly-client-interoperability
Tests for the javax <--> jakarta interoperability handshake protocol used in EJB client and Naming client libraries
https://github.com/wildfly/wildfly-client-interoperability
Last synced: 10 months ago
JSON representation
Tests for the javax <--> jakarta interoperability handshake protocol used in EJB client and Naming client libraries
- Host: GitHub
- URL: https://github.com/wildfly/wildfly-client-interoperability
- Owner: wildfly
- Created: 2023-06-09T19:58:12.000Z (about 3 years ago)
- Default Branch: master
- Last Pushed: 2025-07-14T22:00:21.000Z (about 1 year ago)
- Last Synced: 2025-07-22T09:55:04.206Z (about 1 year ago)
- Language: Java
- Homepage:
- Size: 39.1 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
This repo contains tests for the javax <--> jakarta interoperability handshake protocol used in EJB client and
Naming client libraries.
## Introduction
The interoperability handshake establishes an agreed version (1 or 2) between client and server and the
version is used to determine which marshallers to provide: the legacy marshaller or the interoperability marshaller.
It contains the following maven modules:
* sampleApp-ee8 - a module containing a sample EE8 EJB application to be deployed on the legacy server
* sampleApp-ee10 - a module containing a sample EE10 EJB application to be deployed on the current server
* legacy2Current - a module which starts a current Wildfly server and runs legacy EJB client tests against it
* current2Legacy - a module which starts a legacy Wildfly server and runs current EJB client tests against it
* current2current - a module which starts a current Wildfly server and runs current EJB client tests against it
where:
* legacy => Wildfly 26.1.3 (Wildfly HTTP client 1.1.12.Final, penultimate release without the interoperability handshake)
* current => Wildfly 28.0.0 (Wildfly HTTP client 2.0.2.Final, first release with the interoperability handshake)
## Tests
The tests are integration tests (managed by the failsafe-maven-plugin) which gives us the opportunity to start and
stop independent server instances (managed by the wildfly-maven-plugin) before and after the tests.
The deployments are simple stateful and stateless EJBs which the clients may use to lookup and invoke upon. Because
Wildfly does not support out-of-the-box bytecode transformation when deploying EE8 deployments on EE10 servers,
we need to tailor the deployment to the EE version of the server in question.
The tests should cover the following scenarios where the handshake protocol is used:
* EJB client using remote/remote+http protocol
* EJB client using http protocol
* Naming client using remote/remote+http protocol
* Naming client using http protocol
NOTE: the tests only currently cover the EJB client using http protocol.
## Byteman instrumentation
These tests depend on using Byteman for validating the test criteria, as the state of the protocol handshake is not
easily accessible via methods of the relevant classes.
### Client side
On the client side, Byteman rules (@BMRule) are used to define the event specification conditions (targetClass,
targetMethod and targetLocation) as well as the condition and action to be evaluated at that point in the code.
The rules are annotations on the test case itself.
### Server side
On the server side, Byteman scripts (script.btm) are used to define the event specification conditions (targetClass,
targetMethod and targetLocation) as well as the condition and action to be evaluated at that point in the code.
The server-side scripts are located in the reources/byteman directory.