Hi,
On 12/20/2012 08:13 AM, Sivakumar Thyagarajan wrote:
>> It is just like it is today - all properties in JmsActivationSpec are
>> marked as required config property's for the activation (ra.xml /
>> @NotNull).
>>
>> Those have to come from some place - today the user specifies them in
>> their setup, f.ex. in their MDB
>>
>> @Activation("destination", "java:/queue/MyQueue")
>
> Today a container doesn't discriminate or perform any special action for
> any of the configuration properties of an ActivationSpec. The container
> just sets the configuration properties specified during endpoint
> deployment on the ActivationSpec JavaBean of the RA.
Correct.
> With the new
> standardized JmsActivationSpec in approach #2, we would require the MDB
> container (the MEF implementation), to set a bunch of specific
> properties. This brings a tight binding between the MEF container and
> the RA, that the MDB and Connector spec have tried to prevent since
> Connector 1.5.
>
If the MEF chooses not to support any specific ActivationSpec's it is up
to the user to specify all properties.
However, if a MEF chooses to support specific types it could be done as
below.
>> The MEF can choose to support identifying the JmsActivationSpec and
>> provide the necessary properties:
>>
>> MDBContainerImpl:
>>
>> ActivationSpec as = getActivationSpec(...);
>>
>> if (as instanceof JmsActivationSpec)
>> {
>> JmsActivationSpec jas = (JmsActivationSpec)as;
>>
>> if (!userProvidedProperties.containsKey("clustered"))
>> {
>> // Use container level default
>> jas.setClustered(isClustered());
>> }
>> }
>>
>> Or the user will provide them, like
>>
>> @Activation("clustered", "false")
>>
>
> How could the user provide the Destination object in the JMSActivationSpec?
>
A javax.jms.Destination object isn't a valid config-property for an
ActivationSpec.
Valid types are:
<xsd:restriction base="javaee:string">
<xsd:enumeration value="java.lang.Boolean"/>
<xsd:enumeration value="java.lang.String"/>
<xsd:enumeration value="java.lang.Integer"/>
<xsd:enumeration value="java.lang.Double"/>
<xsd:enumeration value="java.lang.Byte"/>
<xsd:enumeration value="java.lang.Short"/>
<xsd:enumeration value="java.lang.Long"/>
<xsd:enumeration value="java.lang.Float"/>
<xsd:enumeration value="java.lang.Character"/>
</xsd:restriction>
and all of these can be set by a user.
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.
Best regards,
Jesper