Nigel,
On Thu, Jul 14, 2011 at 11:57 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> 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...
Well, except that the queue behavior is more or less specific to JMS. It
may be more implementation specific.
>
>
> > 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>.
So just thinking, is the idea that we would still build upon EJB's
bootstrapping in an EE world? No jms.xml? I figure I'm still assuming that
JMS would standardized on a deployment descriptor to work in both EE and SE
environments.
>
>
>> 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
>
I guess I was already presupposing a JMSMessageDriven in the JMS spec to
replace the EJB spec's implementation in the case of a JMS MDB, for whatever
ends up replacing MDBs.
John
>
>
>> John
>>
>>
>> On Thu, Jul 14, 2011 at 8:07 AM, Nigel Deakin <nigel.deakin_at_oracle.com<mailto:
>> nigel.deakin_at_oracle.**com <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><
>> 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
>>
>>
>>