On 25/07/2011 22:05, John D. Ament wrote:
>
>
> On Mon, Jul 25, 2011 at 3:59 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto: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.
I don't think the spec requires that they do, though if they do they should use the destinationType activation property.
The EJB 3.2 spec (5.4.17) states that "the bean provider may provide advice to the deployer as to whether a [MDB] is
intended to be associated with a queue or topic...the property name...is destinationType".
Nigel
>
>
> 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
>
>