Hi Jesper
On Monday 11 March 2013 10:24 PM, Jesper Pedersen wrote:
> Hi,
>
> First of all let me say that I like the idea of giving the resource
> adapter more information to work from an endpoint point of view.
>
> Adding the
>
> MessageEndpointFactory::getEndpointClass()
>
> method fits this nicely.
Thanks for your detailed inputs. Please see inline.
> 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.
> 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).
> 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.
> Using different message listeners and mandatory config
> properties for the activation spec is a more strict contract, which is
> better.
Agreed. The current proposal enhances the current approach, allowing
more freedom to the RA developer and the MDB developer.
> 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.
> 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?
Yes, the classloader accessibility is assumed. This has been true even
for our current Message Listener types as well. The spec assumes that
all classes accessed by a resource adapter, like a MLI that the MDB
implements, the annotations that the MDB in the new proposal implements
are either defined in the RAR or is accessible to it.
> Looking at message inflow in general is also a good candidate for a
> possible JCA 2.0 specification.
Sure, if there are slightly more concrete ideas, please add them to the
JIRA tracker in connector-spec.
Thanks
--Siva.