On 14/07/2011 16:57, Nigel Deakin wrote:
> On 14/07/2011 14:47, John D. Ament wrote:
> > What about valid values? Do we replace enumerated values with actual java enums at this point?
>
> I'm all for avoiding quoted strings in Java code, so yes, I think we would want to follow the same approach as EJB does
> for flags such as @TransactionManagement(value=TransactionManagementType.CONTAINER), where TransactionManagementType is
> an Enum.
>
> Also, the XML schema for ejb-jar.xml should define valid values, as it currently does for, say, <transaction-type>.
>
>> I would also prefer that this denote that @ActivationConfig not be used and actually define these properties to validate
>> cross container capability. In this sense, then any not required parameter could be a defaulted value in the enum. For
>> example, destinationType: DestinationType.QUEUE, DestinationType.TOPIC, DestinationType.ANY. So the destinationType()
>> parameter would have default DestinationType.ANY.
>
> You mean that instead of using an array of ActivationConfigProperty objects we instead add new methods to
> javax.ejb.MessageDriven, so all these new attributes could be validated at compile time? I'd been wondering about that.
>
> Bearing in mind that MDBs don't have to use JMS, perhaps we need a javax.jms.JMSMessageDriven which extends
> javax.ejb.MessageDriven, and we could aim to consolidate all the JMS-specific behaviour there.
>
> We could even define that class in the JMS spec...
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 think there's a good case for adding subscriptionName and clientId to the existing list of JMS-specific activation
properties.
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