Nigel,
My only concern is what properties we're actually tracking. For example, do
we need destinationType in any case or is this something that the container
can identify for the application tier? maybe it would be best that this is
optional and the container will determine. Furthermore, would it now be
possible to raise some type of warning when two MDBs subscribe to a queue?
What about valid values? Do we replace enumerated values with actual java
enums at this point?
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.
John
On Thu, Jul 14, 2011 at 8:07 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> I logged this issue
> http://java.net/jira/browse/**JMS_SPEC-30<http://java.net/jira/browse/JMS_SPEC-30>
> which was first raised by Emran, but which I definitely support.
> Any comments? If we can get agreement on this we can raise it with the EJB
> 3.2 EG.
>
> This is a request for the JMS and/or EJB specifications to define
> additional mandatory activation config properties for JMS MDBs. Although
> MDBs are specified in the EJB specification, this request should be
> considered first by the JMS 2.0 expert group who may then want to raise it
> with the EJB 3.2 expert group.
>
> The EJB 3.1 spec is distinctly vague about how a MDB is defined. The
> relevant sections are 5.4.15, 5.4.16 and 5.4.17.1. The only activation
> config properties defined are acknowledgeMode (only used when transactions
> are bean-managed, and which must be either Auto-acknowledge or
> Dups-ok-acknowledge), messageSelector, destinationType (which must be must
> be either javax.jms.Queue or javax.jms.Topic) and subscriptionDurability
> (which must be either Durable or NonDurable). But it doesn't specify how the
> destination is defined or, when subscriptionDurability is Durable, how the
> subscription name and client identifier are defined.
>
> The JCA 1.6 spec has some additional guidance, at least for MDBs that use a
> resource adapter. Section B2 states that providers are "strongly encouraged"
> to provide the properties mentioned above and also destination,
> subscriptionName and clientId, with destination and destinationType as
> "required" properties.
>
> Whatever else we do, there seems to be a clear need to make these mandatory
> for JMS MDBs, whether or not they use JCA.
>
> The JMS 2.0 and EJB 3.2 expert groups should also decide whether the EJB
> spec is the best place to list such JMS-specific details. Although MDBs
> (which are not just for JMS) should remain in the EJB spec, perhaps any
> additional specification for JMS MDBs should be in the JMS spec.
>
> Nigel
>
>