Hi Jesper
On Thursday 17 January 2013 09:10 PM, Jesper Pedersen wrote:
> Hi,
>
> On 01/17/2013 02:59 AM, Sivakumar Thyagarajan wrote:
>>> Compile against JCA 1.6 => Works.
>>
>> This RAR must be marked as a 1.6 RA in its ra.xml as it uses the 1.6
>> Connector spec capabilities (the extra MEF method).
>>
>
> Yes.
>
>>> User:
>>>
>>> * Deploys MEF from Vendor A
>>> * Deploys RA from Vendor B
>>>
>>> on to EE Vendor.
>>
>> You can't have an arbitrary combination of MEF implementations into an
>> EE vendor. A compatible EE 6 application server (or a standalone
>> connector container that supports Message Inflow) *must* have a MEF
>> implementation as per the Connectors 1.6 spec.
>
> Correct, with the current specification text. But as Wilson pointed out we
> made a mistake to add the new createEndpoint() method to the existing
> interface.
This addition of a new method was not a mistake. Please see below.
> MessageEndpointFactory / MessageEndpoint are external to resource adapters
> and maybe even the "traditional" application server.
>
> Hence we should make sure that the specification text is updated to
> account for this mistake, where an older implementation of
> MessageEndpointFactory can be deployed on a newer version of the JCA
> specification. It is up to the newer resource adapter implementation to
> verify that the method is actually there.
This scenario is *not* a valid scenario. A compatible EE 6 application
server or a compatible Connector 1.6 standalone connector container cannot
have this combination, as the compatibility tests would not allow this
combination.
>> The resource adapter
>> marked with a 1.6 version cannot be deployed to a EE 5 implementation,
>> but must be deployable in a EE 6 implementation.
>>
>
> Correct.
>
>>> I don't know if that is 'implied' for this scenario for the 'User' - they
>>> don't know either of the implementations, they only see the
>>> NoSuchMethodException.
>>
>> A 1.5 version RAR cannot use the new MEF method, and a 1.6 version RAR
>> can. A 1.5 RAR can be deployed to a EE6 application server, but a 1.6
>> RAR can't be deployed to a EE5 application server. A 1.5 RAR when
>> deployed to a EE6 container can use the provided MEF because it only
>> uses the old methods and the MEF implementation has the old methods. A
>> 1.6 RAR when deployed to a EE6 container may use the new MEF methods and
>> they would be available in the MEF implementation provided by the EE6
>> containter. Therefore there are no valid scenarios where this
>> NoSuchMethodException case arises.
>>
>
> It is the other way around - the 1.5 MEF is deployed to EE 6 and a 1.6 RAR
> is used calling the new method.
This is not allowed, as such a combination would not pass the
compatibility tests.
> Since MEFs are external to the application server we should have added a
> TimeoutMessageEndpointFactory with the method, but we didn't. Hence we
> should update the documentation with that fact.
MEFs are /not/ external to the application server. This is where I think I
am not following the point above. One of the MEF implementation in the
case of a 'full profile' EE6 application server would be a MDB container.
If a Connector 1.6 standalone connector container chooses to support
Message Inflow, the container must provide a MEF with the new method. So,
in both of these cases though a MEF implementation is external to the
connector container implementation, it is still delivered along with the
connector implementation and hence the old-on-new scenario would not occur.
Hope this clarifies.
Thanks
--Siva.
>>> I think the additional documentation could help in this case.
>>
>> Backwards compatibility pertains to existing components
>> being supported by new implementations (not vice-versa) and so we don't
>> need to document scenarios where new components are being deployed to
>> old implementations.
>>
>
> Again, the other way around - old on new.
>
> Best regards,
> Jesper
>