users@connector-spec.java.net

[connector-spec-users] [jsr322-experts] Re: MessageEndpointFactory

From: Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>
Date: Thu, 17 Jan 2013 13:29:56 +0530

Hi Jesper

On Monday 14 January 2013 11:33 PM, Jesper Pedersen wrote:
> Hi,
>
> On 01/14/2013 12:45 PM, Sivakumar Thyagarajan wrote:
>> As I had said in our meeting, as per the EE compat requirements
>> (http://java.net/projects/javaee-spec/pages/CompatibilityRequirements)
>> and the JLS binary compatibility requirements
>> (http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html), addition
>> of a method to a SPI is backwards compatible.
>>
>
> Correct.
>
>>> * Add a @throws NoSuchMuchException Thrown in cases where the
>>> implementation targets JCA 1.0 or JCA 1.5
>>
>> This is not needed as it is implied. A 1.6 RA that uses the new MEF
>> method could *only* be deployed against a connector container that
>> supports 1.6 or above.
>>
>
> Vendor A:
>
> public OurMEF implements MessageEndpointFactory
> {
> public MessageEndpoint createEndpoint(XAResource xaResource)
> {
> ...
> }
>
> public boolean isDeliveryTransacted(Method method)
> {
> ...
> }
> }
>
> Compile against JCA 1.5 => Works.
>
>
> EE Vendor - supplies JCA 1.6.
>
> Vendor B:
>
> public OurRA implements ResourceAdapter
> {
>
> public void endpointActivation(MessageEndpointFactory endpointFactory,
> ActivationSpec spec)
> throws ResourceException
> {
>
> MessageEndpoint me = endpointFactory.createEndpoint(xar, 1000L);
>
> ...
> }
>
> 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).

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

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

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

Thanks
--Siva.