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")
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")
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.
>> I think that in this revision of the spec it would be good enough to
>> clarify that a JNDI context is available during endpointActivation /
>> endpointDeactivation; the JNDI context of the caller.
>
> Ok, thanks. This is what http://java.net/jira/browse/CONNECTOR_SPEC-4
> wants us to do, and this is something we can do in this version of the
> spec.
>
Agreed.
>> 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 ?
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.
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.
Best regards,
Jesper