Hi Jesper
On Thursday 20 December 2012 07:21 PM, Jesper Pedersen wrote:
> 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.
Agreed, but this still aligns with what I was saying, right. The MEF(MDB
container) is now /tied/ to a messaging system (JMS) represented by the
RA. With Approach #2 we would require(or atleast recommend) that the MEF
container in a Java EE application server (the MDB container) support
JMSActivationSpec.
>>> 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.
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);
...
}
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.
Is this understanding right? If yes, I can't follow what you had described
above.
Thanks
--Siva.
>
> Best regards,
> Jesper
>