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