You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by AndyG <an...@orprovision.com> on 2013/08/01 15:14:11 UTC
EJBD
Still have not got EJBD working for older clients. ProtocolMetaData gets a
useless spec string back from the newer server.
The order of write has changed on the server.
Older clients seem to be getting a serialized EJBMetaDataImpl rather than
the spec string.
Any ideas?
Andy.
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
in org.apache.openejb.client.EJBRequest#readExternal I added at the end of
the method the line:
authentication = JNDIContext.AuthenticationInfo.class.cast(in.readObject());
this is not in older versions so it fails.
I think that's one of the cause
*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 Romain Manni-Bucau <rm...@gmail.com>
> ok, i'll have a look
>
> *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 <an...@orprovision.com>
>
>> Older means ...possibly only as little as 4 weeks old snapshot. But I
>> guess
>> that 4.5.2 clients should still be able to look up ejbs on a 4.6 server
>> right?
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664455.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
>
>
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Great, thanks Andy!
*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/8 AndyG <an...@orprovision.com>
> Added initial LegacyClientTest (which is currently a ripped
> RandomConnectionStrategyTest), but does the job. We can always add more to
> the test as new features are added.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664574.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
Added initial LegacyClientTest (which is currently a ripped
RandomConnectionStrategyTest), but does the job. We can always add more to
the test as new features are added.
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664574.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
th eidea is to use StandaloneServer class:
http://svn.apache.org/repos/asf/tomee/tomee/trunk/itests/failover/src/test/java/org/apache/openejb/itest/failover/RandomConnectionStrategyTest.java
this way you can start others JVMs. Then you just need a socket, an @Remote
ejb or what you want to synchronize them.
*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/7 AndyG <an...@orprovision.com>
> I've checked in a pretty comprehensive fix for this issue that should see
> us
> safe in the future.
>
> ProtocolMetaData can be propagated into Externalizable implementations.
> This
> can then be used to determine which version the client is capable of
> accepting - Especially, we cannot write a new entry to a legacy client as
> it
> has no way of reading it.
>
> Externalizables can check for and query the metaData in readExternal and
> writeExternal:
>
> if (null == metaData || metaData.isAtLeast(4, 6)) {
> ...the client is compatible...
> }else{
> ...legacy
> }
>
> I have tested this extensively on my boxes, but not sure how to write a
> 'simple' test? - Can you point me in the right direction for an existing
> test that I can hack?
>
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664567.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
I've checked in a pretty comprehensive fix for this issue that should see us
safe in the future.
ProtocolMetaData can be propagated into Externalizable implementations. This
can then be used to determine which version the client is capable of
accepting - Especially, we cannot write a new entry to a legacy client as it
has no way of reading it.
Externalizables can check for and query the metaData in readExternal and
writeExternal:
if (null == metaData || metaData.isAtLeast(4, 6)) {
...the client is compatible...
}else{
...legacy
}
I have tested this extensively on my boxes, but not sure how to write a
'simple' test? - Can you point me in the right direction for an existing
test that I can hack?
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664567.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok,
please if you can add a test for it (even the old client/new server test
using fork, we already have such tests using StandaloneServer IIRC).
Would hopefully prevent some more regression.
*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/6 AndyG <an...@orprovision.com>
> Working on this now, the order of read write has become out of sync.
>
> Please don't rush to change anything before I commit. I have a real world
> scenario to work on here and when I have it working I will commit.
>
> I may not be ready till tomorrow, so please hang on.
>
> Andy.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664543.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
Working on this now, the order of read write has become out of sync.
Please don't rush to change anything before I commit. I have a real world
scenario to work on here and when I have it working I will commit.
I may not be ready till tomorrow, so please hang on.
Andy.
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664543.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
just commited another step, can you review it Andy please? I propagated
ProtocolMetaData to check it. I updated it to 4.6 (to match the openejb
version where it was introduced). The version field was more related to a
single object IMO and here we allow a protocol update that's why i decided
to go this way (we can still change it).
It shouldn't be a security issue since 1) before it was not, 2) the
authenticationInfo are mainly here to set a security context (permissions).
If we only expect login as security it can be an issue but it was really
not the idea of login-with-request feature.
wdyt?
*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/6 Romain Manni-Bucau <rm...@gmail.com>
> if we can just update the protocol meta data it is the best solution we
> have.
>
> *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/6 AndyG <an...@orprovision.com>
>
>> I've been trying something similar, and a new request code is probably the
>> best option. The only issue is as you state - Could this be a hole into
>> the
>> new server?
>>
>> A solution to that could be to add a server option, something like -
>> AllowOldClients = false.
>>
>> Another option that I was looking at was the impact of changing the
>> ProtocolMetaData OEJB version to 3.2 - This would give us the 'minor'
>> version to query early in the request?
>>
>>
>>
>> --
>> View this message in context:
>> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664536.html
>> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>>
>
>
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if we can just update the protocol meta data it is the best solution we
have.
*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/6 AndyG <an...@orprovision.com>
> I've been trying something similar, and a new request code is probably the
> best option. The only issue is as you state - Could this be a hole into the
> new server?
>
> A solution to that could be to add a server option, something like -
> AllowOldClients = false.
>
> Another option that I was looking at was the impact of changing the
> ProtocolMetaData OEJB version to 3.2 - This would give us the 'minor'
> version to query early in the request?
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664536.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
I've been trying something similar, and a new request code is probably the
best option. The only issue is as you state - Could this be a hole into the
new server?
A solution to that could be to add a server option, something like -
AllowOldClients = false.
Another option that I was looking at was the impact of changing the
ProtocolMetaData OEJB version to 3.2 - This would give us the 'minor'
version to query early in the request?
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664536.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if we read authenticationInfo this way:
try {
authentication =
JNDIContext.AuthenticationInfo.class.cast(in.readObject());
} catch (final Exception e) { // previous versions didn't get this
field
if (!isRequestFromOlderVersion()) {
authentication = new JNDIContext.AuthenticationInfo(null,
null, null); // will likely make the login fail
} else {
authentication = null;
}
}
it is fine but the question is how to implement isRequestFromOlderVersion()
?
a potential solution would be to add new codes
in org.apache.openejb.client.RequestMethodCode, if we
add EJB_OBJECT_BUSINESS_METHOD_WITH_AUTHENT(25) then we propagate the code
to readExternal (we add readExternal(in, code) and impl readExternal(in)
with readExternal(in, 25)) we would be able to get it.
wdyt?
DYI i tried the catch with only authentication = null; and it works with
openejb 4.5.2. I would like to force AuthenticationInfo(null, null, null)
since if the security is only the login (and then no permissions) it would
be an issue.
*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 Romain Manni-Bucau <rm...@gmail.com>
> 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 <an...@orprovision.com>
>
>> 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.
>>
>
>
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <an...@orprovision.com>
> 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.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
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.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
ok, i'll have a look
*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 <an...@orprovision.com>
> Older means ...possibly only as little as 4 weeks old snapshot. But I guess
> that 4.5.2 clients should still be able to look up ejbs on a 4.6 server
> right?
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664455.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
Older means ...possibly only as little as 4 weeks old snapshot. But I guess
that 4.5.2 clients should still be able to look up ejbs on a 4.6 server
right?
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664455.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
older means 4.5.2? 3.1.4?
*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 <an...@orprovision.com>
> I've already changed the code a bit to look for the version, but just
> missing
> something still...
>
> Start a snapshot server, and lookup any ejb from an older client.
>
> In the client on a stop just before call to
> protocolMetaData.readExternal(in); in Client.java:251
>
> Wrap stream with new BufferedReader(new InputStreamReader(in)).readLine()
>
> Which results in (less symbols):
>
> 3.1??????org.apache.openejb.client.EJBMetaDataImpl?????
>
> Looks like a serialized object.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664451.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
A bit of a pain to debug hopping from client to remote server.
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664453.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by AndyG <an...@orprovision.com>.
I've already changed the code a bit to look for the version, but just missing
something still...
Start a snapshot server, and lookup any ejb from an older client.
In the client on a stop just before call to
protocolMetaData.readExternal(in); in Client.java:251
Wrap stream with new BufferedReader(new InputStreamReader(in)).readLine()
Which results in (less symbols):
3.1??????org.apache.openejb.client.EJBMetaDataImpl?????
Looks like a serialized object.
--
View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664451.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: EJBD
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
do you have a small sample showing it? i could have a look. I think it is
linked to my latest updates :s
*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 <an...@orprovision.com>
> Still have not got EJBD working for older clients. ProtocolMetaData gets a
> useless spec string back from the newer server.
>
> The order of write has changed on the server.
>
> Older clients seem to be getting a serialized EJBMetaDataImpl rather than
> the spec string.
>
> Any ideas?
>
> Andy.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/EJBD-tp4664447.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>