Woa - been away over the weekend, so missed all this. Give me a moment. I'll rush in without checking code so you get an idea, - I'll polish my comments in minute if I have it wrong.
Newer clients can talk to older servers by setting the property, but not the other way round. The protocol initially had several flaws, most critical was the lack of defined serialVersionUID which can even break between runtime minor versions. It left us with broken serialization of many critical objects between runtimes. The other major issue was the misuse of a 'version' byte in all readExternal/writeExternal calls without thought given to interop between versions. I went back an generated serial id's on a 3.x checkout (using dk 1.5) for everything I could find that goes over the wire, then imported all those into corresponding objects in the 4.x - This solves serialization of objects from a 1.7 client to a 1.5/6/7 server (and any future runtime). However, this does not (and cannot) solve old clients (3.x, and snapshot 4.x) talking to a new server (4+). This is due to new calls and serialization and deserialization methods introduced to the new server that an older client has no knowledge of. New clients can still talk to older servers by setting the protocol via 'openejb.client.protocol.version' - this was nore important to get right, as this is the usual scenario - A client update, rather than a server update. If a server is updated to 4.6.0, then all clients will require an update - period. However, we now have a future safe 'ProtocolMetaData' parameter that is passed to all 'over the wire' objects, and this can now be used for backwards compatibility in 'both' directions. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/OpenEJB-Client-incompatibility-between-3-1-x-and-4-x-tp4666640p4666647.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
