-
1. Re: JBAS-2408 - EJB3 / JCA integration
adrian.brock Apr 11, 2008 5:41 AM (in response to jesper.pedersen)The correct fix for this is for JCA to provide an AbstractMessageEndpointFactory
and "MessageEndpointInterceptor" (you actually need two for the two different models
AOP or JMX, but they can share a lot of code).
All the EJB2/3/POJO containers should do is provide callbacks for
things like isDeliveryTransacted(Method), getTransactionTimeout(Method)
and the dispatch interceptor (i.e. invoke the ejb container or pojo).
This work is also tied up with the JCA metadata repository."jesper.pedersen" wrote:
I can see two areas that would benefit the implementation:
1) The TODO in JBossMessageEndpointFactory::resolveResourceAdapter about the creation of the ObjectName for the RA - is this still valid ?
This should be replaced with the container passing the above mentioned callback
to the JCA metadata repository.2) The use of JMSProviderAdapter in MessagingContainer which add a JAR dependency - we can just move this class to the ejb3 namespace
No. EJB3 is not the place for integration code. All EJB3 cares about is
I want to activate an endpoint with
* this callback
* these activation config properties
* some selection parameters to determine the rar, e.g. listener interface, rar name, etc.
There a lot of other threads about this with more details in either the JCA forum
and possibly the EJB3 or JMS forums? -
2. Re: JBAS-2408 - EJB3 / JCA integration
adrian.brock Apr 11, 2008 5:51 AM (in response to jesper.pedersen)"adrian@jboss.org" wrote:
No. EJB3 is not the place for integration code. All EJB3 cares about is
I want to activate an endpoint with
* this callback
* these activation config properties
* some selection parameters to determine the rar, e.g. listener interface, rar name, etc.
i.e. there should be a jca spi in the jboss-integration that has something like:public interface EndpointActivationBus { EndpointActivation activate(Endpoint endpoint, Set<ActivationConfigProperties> properties, RarSelection selection); } public interface EndpointActivation { deactivate(); } public interface Endpoint { boolean isDeliveryTransacted(Method); int getTransactionTimeout(Method); // etc. } public interface AOPEndpoint extends org.jboss.aop.Interceptor {} public interface JMXEndpoint extends org.jboss.invocation.Interceptor {} public interface RarSelection { String getRarName(); Class<?> getListenerType(); Map<String, String> getProperties(); // for some kind of fuzzy match based on rar config }
which we then implementation in JBossAS over the JCA metadata repository.
You can imagine alternate methods where the caller does more work upfront
if it knows a lot a about the rar, e.g.EndpointActivation activate(Endpoint endpoint, ActivationSpec spec);
the activation spec obviously determines the rar. -
3. Re: JBAS-2408 - EJB3 / JCA integration
adrian.brock Apr 11, 2008 5:57 AM (in response to jesper.pedersen)"adrian@jboss.org" wrote:
which we then implementation in JBossAS over the JCA metadata repository.
Obviously EJB3 is reposnsible for implementing the AOPEndpoint on top of its
MDBContainer(s). -
4. Re: JBAS-2408 - EJB3 / JCA integration
jesper.pedersen Apr 14, 2008 5:09 AM (in response to jesper.pedersen)I've created the following task to track the SPI
http://jira.jboss.com/jira/browse/JBAS-5426
and imported the first version into jboss-integration. The classes lives under the org.jboss.jca.spi package as it seem like a good choice when looking at jboss-jca.
I havn't added the JMXEndpoint interface yet as I could find the correct Maven artifact for this. Feel free to add the interface, Adrian :)
The next tasks would be to add an implementation in the AS -- currently the locator looks for java:/EndpointActivationBus or org.jboss.jca.EndpointActivationBusManager.
Additional tasks/sub-tasks can be created for this work - or for work that enhanced the current SPI.
Feel free to share your design/implementation ideas, Adrian - or move code around as you see fit, -
5. Re: JBAS-2408 - EJB3 / JCA integration
adrian.brock Apr 14, 2008 5:31 AM (in response to jesper.pedersen)"jesper.pedersen" wrote:
I've created the following task to track the SPI
http://jira.jboss.com/jira/browse/JBAS-5426
and imported the first version into jboss-integration. The classes lives under the org.jboss.jca.spi package as it seem like a good choice when looking at jboss-jca.
I haven't looked at it. The spi needs implementing to validate it works.
I havn't added the JMXEndpoint interface yet as I could find the correct Maven artifact for this. Feel free to add the interface, Adrian :)
The JMXEndpoint should live in the appserver project. It is the backwards
compatibility implementation for EJB2.1
The invocation model is in the appserver's server project.
The next tasks would be to add an implementation in the AS -- currently the locator looks for java:/EndpointActivationBus or org.jboss.jca.EndpointActivationBusManager.
The bus should just be injected.
Additional tasks/sub-tasks can be created for this work - or for work that enhanced the current SPI.
Feel free to share your design/implementation ideas, Adrian - or move code around as you see fit,
The other thing that we will need is a mechanism to predetermine what the rar
resolves to such that the ejb can add the dependency during deployment.
Something like:public interface EndpointActivationBus { EndpointActivation activate(Endpoint endpoint, Set<ActivationConfigProperties> properties, RarSelection selection); /** * Determine the dependency name for the rar * @param properties the config properties * @selection the rar selection parameters * @return the dependency name, e.g. JMX object name or MC name or null if it cannot be determined */ String resolveRarContext( Set<ActivationConfigProperties> properties, RarSelection selection); }
-
6. Re: JBAS-2408 - EJB3 / JCA integration
jesper.pedersen May 14, 2008 2:09 PM (in response to jesper.pedersen)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.