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.
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().
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. 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.
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.
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.
On 12/12/2012 01:16 PM, Sivakumar Thyagarajan wrote:
> Analysis:
> - The benefits that the original approach brings is that it continues
> to retain the goal that the MDB container be unaware of the
> messaging system that is represented by the RA. A side-effect of
> defining the new capabilities(such as instance name) is that non-JMS
> RAs could also leverage them.
>
> However the original approach cannot handle scenarios of
> non-MDB MEF implementations of standalone connector containers
> (that Section 3.5 of the Connectors spec allows), unless we require
> such containers to support JNDI and make the necessary objects
> available in JNDI so that the RA can perform a lookup during
> endpointActivation to get to these objects. The original approach
> requires us to support JNDI lookup during endpointActivation as
> discussed in http://java.net/jira/browse/CONNECTOR_SPEC-4.
>
> - The benefit that the new approach brings is that it bridges the JMS
> RA directly with the MDB container especially since some of the changes
> being discussed were driven from JMS requirements. By requiring the MDB
> container to handle the specifics of working with
> the JMS RA, this approach leaves it to the MEF implementation to handle
> the integration. This should work well with non-MDB based MEF
> implementations, since the JMS RA is completely unaware of the MEF
> implementation and the only interface it expects the MEF implementation
> to satisfy is the JMSActivationSpec requirements.
>
> However the new proposal results in the MDB container needing to do
> JMS-specific operations (such as populating a JMSActivationSpec), and
> prevents the use of the new capabilities by non-JMS RAs.
>
> Design considerations:
> - We must continue to keep MDB containers as generic as possible, and
> not require the MDB container to know that they are delivering to JMS
> RAs. This was the goal of the generic Message Inflow by RAs/Message
> Endpoint/MEF separation in Connectors 1.5 and the MDB enhancements in
> EJB 2.1.
> - We should optimize our design towards valid supported Java EE
> scenarios, than trying to handle corner-case scenarios such as non-MDB
> component containers in standalone connector containers.
>
> Proposal:
> I would like to suggest that we go with the original approach,
> considering the two points discussed above.
>
> To address the problem of the original approach not being able to
> handle non-MDB MEF implementations, if the EG feels that it is
> important, we could do one of the following:
> - require that any Message Inflow implementations must support JNDI or
> - leave it to the JMS RA to handle such edge-scenarios (where JNDI may
> not be available) or
> - define other schemes (that is generic for the MDB container, but
> still allows portability of the RA, such as defining special schemes
> in config property names to request lookup of objects in the container
> and have them set automatically in an ActivationSpec property etc).
>
> What do you think? Please share your comments and inputs.
Best regards,
Jesper