users@connector-spec.java.net

[connector-spec-users] [jsr322-experts] Re: Re: JMS RA requirements (Discussion on CONNECTOR_SPEC-1 and CONNECTOR_SPEC-5)

From: Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>
Date: Thu, 13 Dec 2012 17:48:38 +0530

Hi Jesper

Thanks for your comments. Please see inline.

On Thursday 13 December 2012 01:17 AM, Jesper Pedersen wrote:
> Hi,
>
> Having a JmsActivationSpec requirement is a non-issue, since all resource
> adapters that supports inflow provide their <inbound-resourceadapter>
> configuration.
>
> That is based on an ActivationSpec which is specific to the resource
> adapter, f.ex.
>
> <inbound-resourceadapter>
> <messageadapter>
> <messagelistener>
>
> <messagelistener-type>javax.jms.MessageListener</messagelistener-type>
> <activationspec>
>
> <activationspec-class>org.hornetq.ra.inflow.HornetQActivationSpec</activationspec-class>
>
> <required-config-property>
> <config-property-name>destination</config-property-name>
> </required-config-property>
> </activationspec>
> </messagelistener>
> </messageadapter>
> </inbound-resourceadapter>
>
> Having HornetQActivationSpec extend JmsActivationSpec doesn't require
> changes to the JCA specification.
>
> No matter which MessageEndpointFactory is backing this resource adapter it
> has to resolve "destination" somehow, since it is a required config
> property. Having a common base class with all required config properties
> doesn't add to this requirement on the MEF side. The validate() method or
> bean validation will make sure they are specified.

The MDB container must still know and process JMSActivationSpecs
differently, right? For instance, a simple activationSpec property called
"destinationName" would have been set by the MDB deployer, whereas in the
case of JMSActivationSpec.setDestination, the MDB container (and not the
MDB deployer) sets the Destination.

> If the value of the "ActivationName" could change during the lifecycle
> there could be a use-case. However, that would also mean the method needed
> to be on MessageEndpoint - not MessageEndpointFactory. I don't see that
> use-case though.
>
> I don't see a problem in clarifying that there is access to JNDI during
> endpoint activation, if the environment in question supports this. But
> having a clear contract for this is better - so something we could
> consider is BootstrapContext.getContext().

This is a good point.

However, the environment naming context that is available to the RA should
be based on the current active invocation context. So for instance, during
endpointActivation of MDB1 we should have MDB1's resource refs available
in the context, whereas if used in during RA.start may have a
close-to-null (just having java:global and java:app resources). So, if we
provide an InitialContext reference through BootstrapContext, we may need
to require the container to ensure that this InitialContext changes based
on the context it is used in.

What do others think?

> In regards to BootstrapContect.getInstanceName(); it doesn't make much
> sense to me - instance name of what ? A BootstrapContext can be shared
> across resource adapter deployments, or they can have their own instance.

Even if a BootstrapContext instance is shared across RA deployments in an
application server instance, wouldn't the value of getInstanceName() be
the same. The instance name is the name of the application server instance
that is starting the RA.

> Both for a single application server, or across a cluster. The same
> resource adapter deployment maybe configured differently on the nodes in a
> cluster due to limited resources, yet share "instance name".
>
> We havn't seen these requirements coming elsewhere, since they can be
> solved by having required config properties for the ActivationSpec.
>
> We can't require that all message inflow implementation supports JNDI.
> That would part of the contract of a possible
> BootstrapContext.getContext() method.

Ok, please see above.

> And, no - we shouldn't optimize our design towards MDB containers - they
> are just one implementation type of MessageEndpointFactory. We need to
> drill down to the actual requirements and provide a solution that will
> work in all scenarios.

Exactly. This is why we are not requiring the MDB container to do
JMS-specific operations (like we expect other MEF implementations to not
have such JMS-specific operations)

> I want to iterate that having JMS 2.0 depend on specific JCA 1.7 methods
> would tie implementations to a Java EE 7+ environment. I see that as a
> problem for adoption, and it would limit JMS vendors that doesn't want
> their implementation tied to the EE 7 platform.

There is the JMS 2.0 API and the mandatory JMS RA that needs to be
provided by the vendor. The RA must be a Connectors 1.7 RA as it would
need to use the new capabilities. However the MoM vendor who implements
JMS 2.0 may provide a Connectors 1.6 RA to work with earlier application
servers. This 1.6 RA would not be able to use the Connector 1.7
capabilities, though. Does this help?

Thanks
--Siva.