John,
On 14/07/2011 14:47, John D. Ament wrote:
> 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?
Good question. I mentioned this because the EJB spec already mentions it.
> maybe it would be best that this is optional and the container will determine.
Yes, perhaps.
> Furthermore, would it now be possible to raise some type of warning when two MDBs
> subscribe to a queue?
That seems to me to be an unrelated feature. App servers could do this now, if they wanted to. Perhaps I've misunderstood...
> 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...
Nigel
>
> John
>
> On Thu, Jul 14, 2011 at 8:07 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto: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
>
>