Nigel,
On 3/13/13 1:07 PM, Nigel Deakin wrote:
> Marina,
>
> On 13/03/2013 18:00, Marina Vatkina wrote:
>> Guys,
>>
>> May be resource adapters will become so cool, that everybody will be
>> writing them :). The hope is that in EE 8 we would
>> not even need a marker interface, and there will be other (e.g.
>> annotations-based) ways to match an MDB to the RA.
>
> Sounds good.
>
> > I think that it will be the JMS spec that would define standard
> annotations, and the RA if used, will do its job, and if
>> not used, some other container tools will do it.
>
> Right. So you're suggesting that we would require all application
> servers to support them, even if they don't use a resource adapter to
> support their built-in JMS provider. This means that we would need to
> define them carefully so that they can be implemented without using a
> resource adapter (just like the EJB spec already defines JMS MDBs in
> this manner). This shouldn't be difficult, but it needs to be
> established as a principle.
I would expect that a non-RA JMS implementation can as easily introspect
MDB classes and get all the necessary metadata from them as would a RA.
-marina
>
>> And the EJB 3.3 spec will document those annotations (or if the list
>> becomes too long) we will replace those sections
>> with the references to the corresponding sections of the JMS spec.
>
> Yes, agreed. I look forward to talking about EJB 3.3, just as soon as
> we've got the current release done...
>
> Nigel
>
>
>> Best,
>> -marina
>>
>> On 3/13/13 10:00 AM, Nigel Deakin wrote:
>>> John,
>>> On 13/03/2013 12:59, John D. Ament wrote:
>>>> 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.
>>>
>>> The EJB spec also defines a set of standard JMS activation properties.
>>>>
>>>> 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.
>>>
>>> Indeed.
>>>
>>> The question I'm asking 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.
>>>
>>> The alternative is to require application servers to use JCA to
>>> integrate with their built-in JMS provider. That's not
>>> something the EJB spec has required so far.
>>>
>>> Nigel
>>>
>>>>
>>>> John
>>>>
>>>>
>>>> On Wed, Mar 13, 2013 at 8:34 AM, Nigel Deakin
>>>> <nigel.deakin_at_oracle.com <mailto: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
>>>>
>>>>
>>