Hi Jesper
On Wednesday 13 March 2013 12:08 AM, Jesper Pedersen wrote:
> Hi,
>
> On 03/12/2013 02:16 PM, Sivakumar Thyagarajan wrote:
>>> However, we can't break the existing contracts defined in the message
>>> inflow chapter. So chapter 13 needs to updated in the spirit of the
>>> compromise text - empty message listener interface and business methods.
>>
>> 13.4.8 defines a message listener inteface structure. AFAICS, we haven't
>> prevented an empty MLI. We could clarify this though.
>>
>
> Well, the idea behind EJB_SPEC-60 is that there is no message listener
> at all. That won't work with our current inflow model, we depend on a
> message listener being defined.
I think there is a misunderstanding. We are still requiring a
MessageListenerInterface. There is no change to the Message Inflow
contract.
Please see Bill's email at
http://java.net/projects/javaee-spec/lists/users/archive/2013-03/message/2.
The proposal is to only handle the case when MLIs that have no methods
(a marker interface) in a special manner. When the MLI has no methods,
the MessageEndpointFactory must provide a proxy returned from the
createEndpoint method that implements all the public methods of the MDB
class, as well as the message listener interface.
The change in Chapter 13 would be to introduce the new method to
MessageEndpointFactory.
> So I think it is ok to state in cases where getEndpointClass() is meant
> to being used an empty message listener is required.
>>> One thing to be careful about is not to tie the resource adapter
>>> implementation to a specific endpoint implementation.
>>
>> Sure, do you see anything in the current proposal that leans in that
>> direction? The proposal allows a resource adapter to introspect the MDB
>> class (the message endpoint).
>>
>
> No, but having the interaction being based on reflection is a lot more
> loose contract, and since there is no defined method to invoke you could
> end up in scenarios where the resource adapter assumes one thing, and
> the endpoint developer another.
>
> E.g. documentation about the resource adapter inflow model becomes much
> more important.
>
>>> Also the expected
>>> use-case of having the resource adapter using reflection to "resolve"
>>> the interaction pattern needs to be discussed in more detail in a future
>>> specification.
>>
>> Ok. Yes, it should be easier for a RA to find the right method to
>> deliver a message to. We could add it to our list for a future spec.
>>
>
> Agreed.
>
>>> So lets start by adding the method, updating all of chapter 13 to take
>>> it into account and update 13.7 with a new JMS scenario where the spec
>>> text targets the compromise scenario.
>>
>> 13.7 is a non-normative code example that showcases how Message Inflow
>> works in general. The current example in 13.7 is good even with the new
>> proposal.
>>
>
> Yeah, but I meant add another additional example that shows the usage of
> the empty message listener, and the getEndpointClass() class.
>
>>> Then we can get feedback from JMS and other inflow vendors on how we
>>> should proceed from here in the next spec update.
>>>
>>> We should mandate that the returned Class<?> is the actual endpoint, and
>>> not the proxy. And that its ClassLoader has visibility to the needed
>>> class definitions.
>>
>> The current proposed javadoc clarifies that the class to be returned
>> from MEF.getEndpointClass() is the class corresponding to the Message
>> Endpoint class. Is that sufficient?
>>
>
> Well, that is the question. The JavaDoc is likely enough, but it should
> probably be expanded in the spec text.
The EJB (MDB) spec would describe in detail the requirements around the
proxy that implements the message listener interface and all message
listener methods of the bean. The
MessageEndpointFactory.getEndpointClass method would just have the
current proposed javadoc.
Thanks
--Siva.
> Best regards,
> Jesper
>
>