well if both doesnt run with same java version it woudln't have worked
before too...so not a new issue ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/18 AndyG :
> S
Shading is not not going to resolve the situation, as serialization will
break and 3.1 - early 4.6-SNAPSHOT had virtually no serialVersionUID's at
all. Serialization between runtime 1.6- and 1.7+ was/is completely broken at
many levels.
The only hope we had was the byte 'version', but that needed
What about Java Serialization Romain. Something is not clear in my mind.
Shading ends with renaming packages basically. So when creating the intial
context, the factory must be adapted, not a big deal.
But a.MyClass does not serialize to b.MyClass, isn't it?
So it will allow to have 2 different ve
if you shade the 3.1 you'll be able to use it to contact 3.1 servers
and there would be no conflicts with the version 4...but not an
elegant solution
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://gith
Thanks a lot Andy for summarizing the whole story :)
That really helps.
Ok so the conclusion, is that we can not have any backward compatibility
from 4.x client to 3.1.x servers.
@Romain, I don't see how a shaded version of the 3.1 client could help, btw
So the only way is just to do like you did
Adding some notes as the person who made this mess :)
What we had there was very much the case of "someday we can use this", but
someday never came till Andy finished it. We've historically told users the
exact server and client version needed to match.
Didn't say it at the time, but *huge* th
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 versi
Check for usage of org.apache.openejb.client.ProtocolMetaData#isAtLeast.
The chances of getting 3.x to 4.x working are slim (to none), and will
require action on the byte 'version', and this is even more useless with a
.eg 1.6 to 1.7 runtime communication due to the missing serial id's - You'll
ju
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 initia
We only support the opposite in degraded mode. The easier way to do the
other is to shade old client jar.
We loose key features if we want to support full bckwd compatibility since
the protocol was not design to be updated.
Now that's done and we can enhance it keeping compatibility for next
vers
I've found a discussion between you and Andy to add backward compatibility
between 4.5.x and 4.6.x using a property.
But that is currently not possible to call a 3.1.x server with a 4.6.x
client.
Is there any way to restore backward compatibility?
Jean-Louis
2013/12/9 Romain Manni-Bucau
> Hi
Hi
Was tested (and is used) by at least 2 users + we have a test for it
(itests -> LegacyTest iirc)so would need more details
Le 9 déc. 2013 13:17, "Jean-Louis MONTEIRO" a écrit :
> Guys,
>
>
> Remember Romain doing some changes in the client part in order to make the
> serialization pluggea
Guys,
Remember Romain doing some changes in the client part in order to make the
serialization pluggeable.
He broke somehow the compatibility and Andy did some fixes by introducing
the property *openejb.client.protocol.version* (
http://tomee.apache.org/properties-listing.html) .
It looks like
13 matches
Mail list logo
