Nigel,
The only difference I see is that currently, the endpoint interface is
defined by the JMS spec. The fact that it's the endpoint interface is
defined by the EJB spec.
So, I think to make it consistently used, JMS should define a marker
interface that could represent this type of MDB, likewise try to push EJB
spec to define some standard JMS/MDB annotations for dealing with
queues/topics using this approach.
John
On Wed, Mar 13, 2013 at 8:34 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 11/03/2013 17:57, John D. Ament wrote:
>
>> All,
>>
>> Sorry, I responded only to David RE this. Here's my email, but with an
>> extra line.
>>
>> David,
>>
>> Thanks. I think the big issue is that the RA is stuck taking ownership
>> of instantiating the MDB. It would be ideal if
>> it's moved up a level. Probably not a big push for this in this given
>> iteration.
>>
>> Also, I think your point RE queues is somewhat moot. I haven't checked
>> with all app servers, but I believe I can
>> consistently define multiple MDBs that point to the same queue, with the
>> limitation that the message only gets delivered
>> once. I think the difference is that it's delivered to the RA once now,
>> and now the RA has to distribute the message to
>> an appropriate listener. Might be none, in which nothing happens or it
>> could be several and now they all receive it.
>> Since we might consider these MDBs as components in the same
>> application it's not in conflict with the JMS spec to
>> distribute to multiple listeners.
>>
>> Also, need to reiterate a point. Who would be responsible for defining
>> annotations if say we wanted to create a JMS RA
>> based on this approach for MDBs?
>>
>
> Once this feature is added to Java EE there will be nothing to stop users
> creating resource adapters that take advantage of it. However since the
> annotations would be non-standard and non-mandatory then any MDB
> implementation would be tied to that specific resource adapter.
>
> I think it should be a goal of both JMS and EJB to allow MDBs to be
> written which take advantage of this new feature which are portable between
> different application servers and between different JMS providers, just
> like JMS MDBs are now.
>
> The EJB 3.2 spec (and the CTS tests) requires an application server to
> support JMS MDBs which implement javax.jms.MessageListener and which are
> configured using the activation properties defined in section 5.4.16 "JMS
> Message-Driven Beans". However it does not require application servers to
> support this using a resource adapter, at least for the built-in JMS
> provider. (Oracle's WebLogic is an example of an application server which
> does not use a resource adapter to implement MDBs for its built-in JMS
> provider)
>
> So the issue I'd like to ask is: when we define the new marker interface
> and annotations for this new type of JMS MDB, will the EJB spec require
> that they be supported for *all* application servers, or only for those
> which use the JCA API to integrate with their built-in JMS provider?
>
> My view is that if we want these new JMS MDBs to be portable between
> application servers then we must require all application servers to support
> them, whether or not they use JCA to integrate with their built-in JMS
> provider.
>
> Nigel
>