Support client-side and server-side version handling for EJB/HTTP, Naming/HTTP an Transactions/HTTP

[rachmatowicz]

This is a PR to add client-side and server-side version handling in the Wildfly HTTP client libraries.

EAP RFE: EAP7-2298
Wildfly issue: WFLY-20532
Wildfly HTTP Client Project issue: WEJBHTTP-153

[rachmatowicz]

Content is finalized. Reviews please.

[ropalka]

There are two problems that need to be addressed:

• ABI compatibility is not guaranteed for non-existing fields, methods, classes
• backward compatible mode is off by default (documentation how to enable it is needed)

The remaining typos are irrelevant.

[ropalka]

It have to be mentioned in this document that compatibility is not guaranteed for:
https://github.com/wildfly/wildfly-proposals/blob/main/backward-compatibility/WFLY-16296_JavaEE_And_JakartaEE_Compatibility.adoc#none-requirements

[rachmatowicz]

I included a reference to the two "none" backward compatibility requirements you highlighted, and mentioned that the compatibility they describe does likewise not apply here.

[ropalka]

This section collides with: https://github.com/wildfly/wildfly-proposals/blob/main/backward-compatibility/WFLY-16296_JavaEE_And_JakartaEE_Compatibility.adoc#hard-requirements namely: "Backward compatibility mode is off by default".

[rachmatowicz]

Thanks for noting this. I assume the default is off as it represents the most common case (clients and servers both using recent versions of Wildfly - in other words, those that are based on Jakarta EE). In the case of handler versioning, there may be a higher chance of incompatibility between clients and servers as features are added to the HTTP client and require handler version changes, but you could argue that the default case would again be when client and server software have the same versions, so keeping the default as off makes sense.

[rachmatowicz]

I'm debating wth myself about the validity of the interoperability section I have written here.

In that section, i'm classifying the shift from Java EE to Jakarta EE is an interoperability issue, in that Wildfly for Java EE and Wildfly from Jakarta EE, although from the same sofware vendor, are from different architectures (the set of specifications interpreted as an architecture).

However, the Wildfly HTTP client (or EJB client for that matter) cannot interoperate with different server vendors.

I'm wondering if this distinction is worth including or whether I should just incorporate it all into the backward compatibility section.