Hi Jesper
On Monday 17 December 2012 06:59 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/17/2012 05:23 AM, Sivakumar Thyagarajan wrote:
>>> Yes, but having a javax.jms.Destination as a config-property is a spec
>>> violation, due to "config-property-typeType".
>>>
>>> The 'destinationName' as java.lang.String should be used for the lookup -
>>> that is no different than the vendor do it today.
>>
>> ... yes, except that the MEF implementation in Approach #2 had to /know/
>> that it would need to populate the destination config property of a
>> JMSActivationSpec. I may have misunderstood you. Please correct me if
>> that is the case.
>>
>
> 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. 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.
> 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?
> No changes on our part, and MEF implementations can just choose to let the
> users do the work. ActivationSpec.validate() or bean validation should
> make sure that they are specified one way or another.
>
...
>>> Yeah, but what does that mean ?
>>>
>>> It is possible to have multiple IronJacamar containers running in the
>>> same
>>> JVM, complete with separate naming servers, transaction managers and
>>> so on.
>>
>> In this case, I am assuming that each IronJacamar container represents
>> an isolated instance, and so each of them should have different instance
>> names. In this case, the same BootstrapContext instance object must not
>> be used while bootstrapping RAs deployed against each of these
>> containers. There must one BootstrapContext instance per IronJacamar
>> instance (that is seeded with its own unique instanceName), and this
>> BootstrapContext instance can be shared by all RA instances that are
>> bootstrapped by that IronJacamar instance. Would this work?
>
> Yes, that would be one implementation. But what does 'InstanceName' buys
> us or JMS ?
The instanceName could be used by a JMS RA to come up with topic
Subscription names as described earlier.
> We have to be very careful, since BootstrapContext is central to JCA, and
> with the cloud changes coming in EE 8 I don't want us to get locked in, or
> start down the wrong path.
I agree. The BootstrapContext represents the container to the resource
adapter instance. So, the idea was to use this to provide the instanceName
to the RA.
> Sharing a BootstrapContext object between server instances makes sense on
> a single machine, since they are limited by the same number of resources.
> Of course it would require solving by special classloader semantics (OSGi
> / JBoss Modules / ...).
>
> And if 'InstanceName' can be solved by a possible required config
> property, then we should leave BootstrapContext alone in this revision.
I agree, but I can't think of a way for the required config property to be
set by a MEF unless the MEF 'knows' about the particular property and that
is what Approach #1 offers.
Thanks
--Siva.