Thanks so much for the reply, Siva.
On Feb 18, 2013, at 10:00 AM, Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com> wrote:
> I am still trying to understand the new proposal better. So, please correct me if my assumptions below are incorrect.
Will do. This is the same proposal as before, perhaps described better. It's also good to have this mailing list. We were at a disadvantage previously.
> - If I understand the new proposal correctly, you would like the RA to have the ability to cast the endpoint proxy to the bean class.
Correct. Though better phrased is the endpoint proxy should (optionally) have all the methods of the bean class. However this is achieved is fine.
The proposal is a one-two punch. 1) the connector is allowed to request the beanClass via the ActivationSpec, 2) if so MDB container gives the Connector an endpoint proxy that has the same methods as the bean class.
Simple and direct. In all cases the endpoint still implements MessageEndpoint and the message listener interface. The connector simply is allowed to ask for more.
Side note, I noticed Glassfish will actually generate an interface version of the bean class for its @LocalBean support. A proxy with this generated interface would actually work fine. We don't actually need the subclass part as it's really the methods we are after.
> Why would the RA need the proxy to be assignable to the bean class?
> - I also understand that the new proposal and the example, has broken the MessageListener interface into multiple fine-grained annotations that could then be placed on the MDB and then driven during message delivery. Is this understanding right?
The goal is to allow connectors to create expressive JAX-RS style APIs that are possibly annotation driven. We're allowing for more expressiveness and that does lead to finer control, yes.
Whether or not it's seen as breaking up the MessageListener interface is perhaps subjective. Interestingly enough I see it as the opposite.
Specifically, given a JAX-RS component like this:
@Path("/widgets")
public class WidgetsBean {
@GET
@Path("/foo/{id}")
public String getFoo(@PathParam("id") String id) {
// ...
}
@GET
@Path("/bar")
public Bar getBar() {
// ...
}
@GET
@Path("/baz")
public StreamOutput getBaz() {
// ...
}
}
To do this with an interface, we'd have to create a fixed method signature that could handle any invocation. Then we would need to split apart our bean as we can't implement the same method more than once. The result would be our component broken into multiple fine-grained components something like this:
import javax.ws.rs.core.Response;
import javax.ws.rs.core.Request;
public class FooBean implements GetOperation {
public Response doGet(Request request) {
//...
}
}
public class BarBean implements GetOperation {
public Response doGet(Request request) {
//...
}
}
public class BazBean implements GetOperation {
public Response doGet(Request request) {
//...
}
}
Effectively the fixed generic method signature forces you into APIs driven by one generic method. Examples are javax.servlet.Servlet.service(req, res) and javax.jms.MessageListener.onMessage(Message).
Both approaches are fine, but there's no doubt that APIs like JAX-RS and JAX-WS are very successful because of their expressiveness.
> We now have the ActivationSpec not just responsible for configuration of the Message endpoint, but also define the specifics on how the message delivery is performed.
Not sure I followed that point. I don't imagine the roll of the ActivationSpec changing.
> - Adding in a beanClass property in ActivationSpec now is a backward incompatible change.
This is true to the same extent that the other properties we've introduced are backwards incompatible. We added destinationType, acknowledgeMode, subscriptionDurability properties in EJB 3.1 and the clientId and subscriptionName properties in EJB 3.2.
We run the risk of negatively affecting existing JMS RAs every time we add a new property. The same is true here, though I would say the odds are significantly less given the rarity of connectors outside of JMS. We can certainly consider a different name if there's concern of conflict.
> - The resource adapter may not portably have permissions for Reflection.
We should be fine here. The the java.com.sun.genericra.GenericJMSRA uses reflection to both get and invoke the onMessage method of the endpoint. This is the heart of what we're after. We just need the endpoint to expose more methods and we could easily support APIs like JAX-RS or JAX-WS.
> I would also like to request the other Connector EG members weigh in.
Agreed. That'd be wonderful.
-David
> On Tuesday 05 February 2013 06:54 AM, David Blevins wrote:
>> Drilling in to be as specific as possible. The activation config
>> property note is entirely in the EJB spec, so we're good in that
>> regard.
>>
>> The one, nice-to-have, note for the Connector specification would be
>> an update to section 13.5:
>>
>> "the endpoint instance supplied by the createEndPoint method call is
>> a proxy which implements the endpoint message listener type [and is
>> assignable to the bean class]"
>>
>> In case there was a misunderstanding it was never proposed that said
>> proxy would not implement the message listener interface, simply that
>> in addition the proxy would be castable to the bean class similar to
>> @LocalBean. The term "no-interface-view" has been used to describe
>> this kind of proxy, which I think has lead to some confusion. I've
>> never liked the term "no-interface-view" even when we were using it in
>> EJB 3.1 and am actually the one who proposed @LocalBean. Reason being
>> is the bean may in fact have interfaces as is the case here and is
>> easily the case in EJB session beans. Having no interfaces is simply
>> one way to turn this on, the other is via annotation. Our plan is to
>> turn this on for MDBs as well.
>>
>>
>> -David
>>
>> On Mon, Feb 4, 2013 at 3:43 PM, David Blevins <david.blevins_at_gmail.com> wrote:
>>> Timeline issues aside, what is the objection to EJB_SPEC-60?
>>>
>>> If it is a matter of how useful it is, the EJB EG is very on board and this is our third most popular issue of EJB 3.2.
>>>
>>> If it is a matter of size of change, no actual change to the JCA API need be changed. Two spec notes would be nice, but are not strictly required as they are actions taken by the EJB Container. These are:
>>>
>>> - A mention that the MDB Container will be offering the inbound connector a MessageEndpoint that is akin to a no-interface view.
>>> - A mention that the MDB Container will inject the bean class into the activation config, should the spec contain a 'beanClass' property.
>>>
>>>
>>> -David
>>>
>