Hi Jesper
On Friday 21 December 2012 01:58 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/20/2012 09:05 AM, Sivakumar Thyagarajan wrote:
>>> So 'destination' would be a java.lang.String (as it is today), and a JNDI
>>> lookup would take place in endpointActivation() to resolve the
>>> javax.jms.Destination object.
>>
>> Sorry, I didn't quite understand this. Could you please help me
>> understand this?
>>
>> In Approach #2, we would have defined a standard ActivationSpec, as
>> follows:
>> [as shown in Table #2 of
>> jmsra-connectors-mdb-spec-enhancements-in-ee7-a-comparison.pdf attached
>> earlier in this thread]
>>
>> class JMSActivationSpec implements ActivationSpec{
>> ...
>> javax.jms.Destination getDestination();
>> void setDestination(Destination d);
>> ...
>> }
>>
>
> Yes, but javax.jms.Destination isn't a valid config-property type, so you
> can't use that.
Ok.
> All properties on the ActivationSpec has to follow the restrictions set
> forth by the XSD, as defined by 'config-property-typeType', e.g. all the
> simple Java types.
>
> Having complex objects would create a strong dependency, as users doesn't
> have a possibility to set those, as configuration is done by strings.
Ok.
>> 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. If this is true, how is this different from Approach
#1, except that we now have a specialized JmsActivationSpec?
> 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.
Thanks
--Siva.