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.
> 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
>>>
>>>
>