Hi,
On 01/11/2013 05:29 AM, Sivakumar Thyagarajan wrote:
>>> Could you please provide more information on the exact usecase that
>>> would need this capability? I had tried to summarize
>>> the usecase as I understood it at [2], but I am sure you would be able
>>> to help us understand the requirements better and
>>> see if we can come up with an alternative.
>>
>> This is an ease of use feature. Currently when a user configures a MDB to
>> consume messages from a durable topic subscription they have to set the
>> subscriptionName to a name which is unique to the deployed MDB they are
>> using. This could be any name, so long as it is the same on each instance
>> in the app server cluster (which is why it can't be generated by the
>> RA or
>> JMS provider itself). A common convention it to base the name on the MDB
>> name to make the name user-readable in tools.
>>
>> The reason for this new feature is to allow users to leave
>> subscriptionName unset rather than set it manually to a value that the
>> container already knows. Some vendors (e.g. WebLogic) already allow this
>> as a non-standard feature.
>
> Jesper/Fred, could you share your inputs on this?
>
>> I don't mind whether the MDB name is passed to the RA by the JCA runtime
>> or by the MDB container. Several months ago the Java EE and EJB spec
>> leads
>> agreed that the EJB spec would specify that this information would be
>> made
>> available as a JNDI entity at java:comp/UniqueMDBName, and it was
>> added to
>> the draft EJB 3.2 spec. However Siva commented more recently that it was
>> not possible to lookup such entities during endpoint activation, which is
>> why it was suggested passing in this information via the
>> MessageEndpointFactory. This feature was therefore removed from the draft
>> EJB 3.2 spec on the basis that it would be added to the JCA spec.
>
> Yes, it was removed earlier from the EJB 3.2 spec because the connector
> spec so far didn't require the availability of a naming context during
> endpointActivation. Now that this would be fixed through
> CONNECTOR-SPEC_4 in Connectors 1.7, this approach (of the MDB container
> setting a java:comp/UniqueMDBName that the RA can then lookup and use)
> could work.
I think based on this we can remove the
MessageEndpointFactory::getActivationName() method.
The use-case should be covered by allowing JNDI lookup during
endpointActivation() and endpointDeactivation() based on the callers
context. And a possible required config-property for the ActivationSpec.
Best regards,
Jesper