Hi Jesper
Thanks for your comments. Please see inline.
On Thursday 13 December 2012 07:26 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/13/2012 07:18 AM, Sivakumar Thyagarajan wrote:
>>> No matter which MessageEndpointFactory is backing this resource
>>> adapter it
>>> has to resolve "destination" somehow, since it is a required config
>>> property. Having a common base class with all required config properties
>>> doesn't add to this requirement on the MEF side. The validate() method or
>>> bean validation will make sure they are specified.
>>
>> The MDB container must still know and process JMSActivationSpecs
>> differently, right? For instance, a simple activationSpec property
>> called "destinationName" would have been set by the MDB deployer,
>> whereas in the case of JMSActivationSpec.setDestination, the MDB
>> container (and not the MDB deployer) sets the Destination.
>>
>
> 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.
>>> I don't see a problem in clarifying that there is access to JNDI during
>>> endpoint activation, if the environment in question supports this. But
>>> having a clear contract for this is better - so something we could
>>> consider is BootstrapContext.getContext().
>>
>> This is a good point.
>>
>> However, the environment naming context that is available to the RA
>> should be based on the current active invocation context. So for
>> instance, during endpointActivation of MDB1 we should have MDB1's
>> resource refs available in the context, whereas if used in during
>> RA.start may have a close-to-null (just having java:global and java:app
>> resources). So, if we provide an InitialContext reference through
>> BootstrapContext, we may need to require the container to ensure that
>> this InitialContext changes based on the context it is used in.
>>
>
> It was an idea, I didn't say it was a good one ;)
>
> And yes, java:comp wouldn't be possible with
> BootstrapContext.getContext(), as that shouldn't be changed based on
> invocations.
>
> 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.
> We need a "lite" edition for the standalone section, since there is no
> component model requirement.
>
> We can circle back to this in a later spec revision, and maybe add
> overloaded endpoint methods, that takes a datastructure that represents
> the caller's environment.
Ok, let us punt on this for now, unless we hear otherwise from others.
>>> In regards to BootstrapContect.getInstanceName(); it doesn't make much
>>> sense to me - instance name of what ? A BootstrapContext can be shared
>>> across resource adapter deployments, or they can have their own instance.
>>
>> Even if a BootstrapContext instance is shared across RA deployments in
>> an application server instance, wouldn't the value of getInstanceName()
>> be the same. The instance name is the name of the application server
>> instance that is starting the RA.
>>
>
> 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?
> A small unstable cluster - but a cluster non the less, where only the
> application classloader is shared.
>
>>> I want to iterate that having JMS 2.0 depend on specific JCA 1.7 methods
>>> would tie implementations to a Java EE 7+ environment. I see that as a
>>> problem for adoption, and it would limit JMS vendors that doesn't want
>>> their implementation tied to the EE 7 platform.
>>
>> There is the JMS 2.0 API and the mandatory JMS RA that needs to be
>> provided by the vendor. The RA must be a Connectors 1.7 RA as it would
>> need to use the new capabilities.
>
> That is what we are discussing now.
Yes, but as I had said earlier, the MoM vendor is free to provide a
Connectors 1.6 RA as well to work with earlier application servers.
Thanks
--Siva.