Just a small update on the SPI work.
The EndpointActivationBusLocator isn't needed as the EndpointActivationBusManager
should be injection using @Inject or through a -beans.xml file. The manager itself is
installed in the microcontainer using a -beans.xml together with its dependencies. The
manager is a singleton.
One dependency is currently the JCAMetaDataRepository as the manager needs information
about the resource archives that have been installed. Furthermore the client can activate
the endpoint using a set of properties -- and of course the client callback object
(Endpoint).
I'm currently investigating the interaction with the EndpointActivation from a clients
point of view using the EJB3 messaging container as the example.
The EJB3 messaging container currently relies on two classes: JBossMessageEndpointFactory
and MessageInflowLocalProxy both in the org.jboss.ejb3.mdb.inflow package.
Most of the functionality in JBossMessageEndpointFactory will be replaced by the
EndpointActivation and the callback object.
The task is to replace the MessageInflowLocalProxy with something on both sides - or some
sort of callback that the client provides. The AOPEndpoint interface doesn't currently
fit in here, since MessageInflowLocalProxy is an java.lang.reflect.InvocationHandler. The
question is also how much of the JCA API we expose to the client.
I havn't investigated yet how the resolveRarContext method should be implemented, but
properly a scan through the metadata and lookups in the microcontainer.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150845#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...