On Mon, Jul 25, 2011 at 3:59 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 21/07/2011 15:38, Nigel Deakin wrote:
>
>> I've received no objections so far to either:
>> (1) defining some more JMS-specific mandatory activation config properties
>> and
>> (2) a new @JMSMessageDriven annotation with such properties available as
>> attributes.
>>
>> I'll now ask the EJB and Java EE spec leads for their views on what would
>> be appropriate.
>>
>
> I'm still discussing this with the relevant people.
>
>
> I think there's a good case for adding subscriptionName and clientId to
>> the existing list of JMS-specific activation
>> properties.
>>
>
> I've been asked why a developer needs to be able to define a
> subscriptionName and clientId on a MDB which listens on a durable
> subscription. In practice, isn't the durable subscription always unique to,
> and scoped to, the application, and in which case, why can't the container
> generate subscriptionName and clientId automatically?
>
> Any comments?
>
> I've previously asked why a developer needs to state whether an MDB is
listening on a queue or a topic. I think the container should generate,
then allow for overrides if applicable.
>
> For destination name it might be more consistent with other resources to
>> define it through an attribute of
>> @MessageDriven such as name, mappedName or lookup. I'll ask for advice.
>>
>> Making all mandatory JMS activation properties additionally available as
>> attributes of a new @JMSMessageDriven
>> annotation is a bit more racical. But I'll raise it.
>>
>
> Nigel
>
>