Hi,
Initially I was leaning toward the approach #2, but I like the original approach because I have issues/questions with approach #2 for the following reasons:
1. due to the restriction of config-property-typeType (not allowing pass the javax.jms.Destination), the RA still needs to look up the Destination in JNDI during endpointActivation even though we use the JMSActivationSpec. I agree with Siva's question, how is this different from original Approach #1, except that we now have a specialized JmsActivationSpec.
2. there is no compelling reason to break the design principle in this release, decoupling between the MEF container and the RA.
To me, JCA specifications were written mostly for Java EE scenarios in practice, and non-MDB component container handling is corner-case scenarios as Siva mentioned. So, for non-MDB component scenarios, we can leave it to the JMS RA to handle, but we recommend JNDI support (I am checking if there is a better way).
Byung
________________________________________
From: Jesper Pedersen [jesper.pedersen_at_redhat.com]
Sent: Wednesday, January 02, 2013 10:04 AM
To: jsr322-experts_at_connector-spec.java.net
Subject: [jsr322-experts] Re: [connector-spec-users] Re: JMS RA requirements (Discussion on CONNECTOR_SPEC-1 and CONNECTOR_SPEC-5)
Hi,
On 12/28/2012 12:48 PM, Sivakumar Thyagarajan wrote:
>>> In MEFs that support JMSActivationSpec, we would have the MEF container
>>> looking up a Destination (based on some configuration that was specified
>>> by the user during deployment of that endpoint) in JNDI, and setting
>>> that looked up 'javax.jms.Destination' object in the JMSActivationSpec
>>> bean instance. In the cases where MEF doesn't support JMSActivationSpec,
>>> we expect the user to specify the value for the "javax.jms.Destination"
>>> java object, not a "String" that a container/RA then looksup, because we
>>> expect the RA to be unaware of whether the MEF container supports
>>> JMSActivationSpec or not.
>>>
>>
>> So the lookup has to be done using the spec defined types,
>>
>> interface JmsActivationSpec extends ActivationSpec
>> {
>> public String getDestination();
>> public void setDestination(String v);
>> }
>>
>>
>> ::endpointActivation(MEF, AS)
>> {
>> if (!(AS instanceof JmsActivationSpec))
>> throw ...;
>>
>> JmsActivationSpec jas = (JmsActivationSpec)AS;
>> Context context = null;
>> try
>> {
>> context = new InitialContext();
>> javax.jms.Destination d = context.lookup(jas.getDestination());
>> ...
>> }
>
>
> Ok, so even in Approach #2, IIUC from what you describe above, we would
> have the component deployer provide the location in JNDI during
> component deployment, and the RA would then look up this Destination in
> JNDI during endpointActivation.
That is how the users do it today, yes.
> If this is true, how is this different
> from Approach #1, except that we now have a specialized JmsActivationSpec?
>
From a JCA PoV we don't care if there will be a JmsActivationSpec in
JMS 2.0 - if there is; they can only use the approved config-property
types though.
We are discussing if we need additional functionality in JCA in order to
support their scenarios - beyond supporting JNDI lookup in
endpointActivation()/ endpointDeactivation().
>> Plus the ManagedConnectionFactory's knows which destination/topic they
>> control,
>
> The MCF is not tied to the administered objects that are created for
> that RA (though a RA could internally keep track of them).
>
>> so using ResourceAdapterAssociation could simplify configuration
>> for the user even further, e.g. why enter the destination name twice ?
>> Having an unique identifier would be less error prone.
>
> Sorry, could you please elaborate on this? I did not understand how the
> unique identifier would be specified.
I'm just saying that a JNDI name isn't always the best option, here only
a unique needs to be entered on the AS / AO side, so the JNDI on the MCF
could change without the Id value.
ActivationSpec -\ /- MCF (Id: 1)
Id | |
|--> RA <-|- MCF (Id: 2)
AdminObject ----/ |
Id ...
Best regards,
Jesper