users@connector-spec.java.net

[connector-spec-users] [jsr322-experts] Re: proposed MDB improvements

From: Jesper Pedersen <jesper.pedersen_at_redhat.com>
Date: Tue, 12 Mar 2013 14:38:33 -0400

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.

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.

Best regards,
  Jesper