So to sum up both: org.apache.openejb.client.Client#processRequest
and... org.apache.openejb.server.ejbd.RequestHandler#processRequest (4 Implementations all added various levels of complexity) Introduced calls that broke backwards compatablity between 3.x / 4.5.x and early 4.6.x-SNAPSHOT versions. org.apache.openejb.client.EJBResponse#VERSION, which was effectively never used correctly, could potentially be used to try and get some level of backwards compatibility, but I doubt it as the server has no idea if the calling client is 3.x / 4.5.x or early 4.6.x-SNAPSHOT versions (and serialization is also likely to fail). With 4.6.0+ we now have concrete means to ensure this does not happen again: Providing the de-serialized client ProtocolMetaData to each server object that goes over the wire now allows us to know on the server which client version is calling and how to respond, and serialVersionUID's are now also defined - The legacy tests will fail if someone forgets to follow the pattern when making changes at protocol level. And finally to respond to the initial topic - The system property 'openejb.client.protocol.version' is documented correctly (Allows new clients to potentially communicate with older servers), but it needs to be made more clear that this does NOT allow old clients to communicate with new servers prior to 4.6.0. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/OpenEJB-Client-incompatibility-between-3-1-x-and-4-x-tp4666640p4666650.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
