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 <[email protected]>

> 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.
>>
>
>

Reply via email to