Hi,
On 01/02/2013 11:55 PM, Jun, Byung-Woo wrote:
> Initially I was leaning toward the approach #2, but I like the original approach because I have issues/questions with approach #2 for the following reasons:
>
> 1. due to the restriction of config-property-typeType (not allowing pass the javax.jms.Destination), the RA still needs to look up the Destination in JNDI during endpointActivation even though we use the JMSActivationSpec. I agree with Siva's question, how is this different from original Approach #1, except that we now have a specialized JmsActivationSpec.
Approach #1 is more than the ActivationSpec discussion.
We should basically not care if the JMS group decides to create a
JmsActivationSpec - as long as it is spec compliant.
I think we should do a round of discussion on this during our call and
post the outcome for further discussion and feedback from the community.
> 2. there is no compelling reason to break the design principle in this release, decoupling between the MEF container and the RA.
>
Agree, we should only break the SPI if there is a real need for it.
> To me, JCA specifications were written mostly for Java EE scenarios in practice, and non-MDB component container handling is corner-case scenarios as Siva mentioned. So, for non-MDB component scenarios, we can leave it to the JMS RA to handle, but we recommend JNDI support (I am checking if there is a better way).
Yes, I don't see any issues in allowing access to JNDI during
endpointActivation() / endpointDeactivation(). We just need to clearly
state which contexts there are access to.
Best regards,
Jesper