I didn't find a workaround for this additional field, if you have one please hack it, this is due to an important update so i wouldn't lost it. The alternative for old clients compatibility is i think to replace openejb-ejb by the old jar, no?
If there is an issue with version reading we need to fix them for next release, because we can't break the compatibility too often. That said it doesn't shock me we do it now, that's a proprietary protocol and i perfectly understand we shouldn't do it if we can but important updates can needs it. PS: i still hope you see a workaround ;) *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/8/1 AndyG <[email protected]> > Cool, thanks Romain. > > The whole version concept seems to have been introduced adhoc, which has > made this much harder than it should be. > > Newer clients will not be able to talk to older servers as they must send > the current version (3), but older servers still have code that basically > does 'if version == 2 do something', but should really have been 'if > version > >= 2 do something'. > > I still think it is a real requirement for older clients to be able to talk > to a newer server though. > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664458.html > Sent from the OpenEJB Dev mailing list archive at Nabble.com. >
