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.
>> 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.
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.
>> 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.
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.
Best regards,
Jesper