Nigel,
I think it is still a fine-grained detail at this point, but I see no
reason to have yet another top level annotation when a much more
forward-looking, flexible and powerful CDI event based model is
perfectly viable and aligned with the general direction of Java EE. To
be more specific, I think a model like this would be far better:
@ManagedBean // Could also be a plain POJO managed by CDI
public class SomeBean {
...
public void listenToSomeMessage(@Observes
@JmsDestination("jms/SomeQueue") Message someMessage)
...
}
This is just the tip of the iceberg as to the strength of this model. It
enables much more powerful/flexible OO-based abstractions that we can
discuss in detail when more appropriate.
Cheers,
Reza
On 7/21/2011 10:38 AM, Nigel Deakin wrote:
> 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3776 - Release Date: 07/20/11
>
>