MessageEndpointFactory (MC/EJB3/AOP)

[weston.price]

What we want is an abstract MessageEndpointFactory maintained by the
JCA project. Then each environment
* EJB2.0
* EJB3
* MC/AOP
* Other
can provide plugins to handle the container callbacks
which are for:
isDeliveryTransacted(Method)
and the classloader/ENC change for the before/after processing.

The MDB is funny in that although it is similar to an SLSB
it is the MessageEndpoint that actually performs the
transaction demarcation or in some cases the RAR (tx inflow).

It doesn't make sense to have three different impls of the
core rules.

Besides the above mentioned container callbacks,
this already exists in the new jboss-jca project.

Although the version in org.jboss.ejb.plugins.inflow
works, it is not very nice since it has an unnecessary JMX
layer that makes it difficult to reuse.

[weston.price]

Right, I agree.

Right now there exists 3 fundamentally different implementations:

a)
org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory (MBean, JMX dependent)

b)
org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory (straight impl of MessageEnpointFactory but JMX dependent)

c)
org.jboss.jca.plugins.endpoint.POJOMessageEndpointFactory (straight impl of MessageEnpointFactory using injection etc, etc).

The EJB3 implementation's reliance on JMX is in the creation of the ActivationSpec, endpointActivation and endpointDeactivation.

Ideally in a refactoring this JMX dependecy would be removed and put behind some form of wrapper that wasn't JMX dependent....more along the lines of the MC stuff doing injection.

I know this is required for EJB3 to move forward with inflow in non managed environment, however, jboss-jca clearly isn't ready for prime time at this point, so an interim solution, or bridge is probably the way to go.

Thoughts?

[weston.price]

Further, I think a refactoring or at least a 'rethinking' of some of this stuff would go a long way towards helping people understand inflow in general. I get a lot of questions like...

'How does all of that stuff work, I tried looking at the code, but I can't figure it out.'

A few emails on core have touched on the subject as well.

[weston.price]

More thoughts...

The real problem in allow for the non-managed solution is in the way we deploy and manage RARS today. Of course it is wrapped in an MBean and creating the ActivationSpec, endpoint activation/deactivation etc, etc, requires the use of JMX. Of course, the POJO JCA implemenation doesn't do things this way and would provide the necessary support to run divorced from the container.

Ideally the abstract MessageEndpointFactory should contain an 'Activator' type abstraction that is either injected via AOP or set via MBean. In this manner, the MEF could do all the necessary 'stuff' (ActivationSpec, activation/deactivation etc, etc) required for inflow, without actually knowing where this supporting stuff resided.

Further, doing something like this should allow the new stuff and old stuff to peacefully coexist.

[adrian.brock]

The "activator" is just the container.

It needs to know how to construct the ActivationSpec (which is just a javabean)
and then pass it to the rar instance which should just be injected into the
container.

The problem at the moment is that the container only gets an ObjectName
and that is to the RARDeployment mbean which acts as a proxy to the RAR
instance.

In the simplest POJO case, you don't need the container/activator.
You just construct the MessageEndpointFactory, ActivationSpec and RAR
using IOC then tie them together.

You could imagine a "POJO activator" that does a lot of the boiler plate,
constructing the ActivationSpec from the annotations on the POJO
and using a predefined MessageEndpointFactory/advices.
i.e. The user just provides
* The "mdb instance", the annotated POJO
* The rar instance injection

[weston.price]

Right, that would be ideal.

Problem being, that right now for EJB3, there is no way to give them an embedded version of inflow without using the jboss-jca stuff which, AFAIK isn't really prime time.

[adrian.brock]

It could be made "prime time" if you can persuade Kabir
to backport the new aop proxy factory that it uses to AOP 1.3

I think using/testing one codebase would be a more efficient use of time
than trying to maintain features and fixes across three different
implementations.

[weston.price]

Agreed.

But this is one of the the things I have kind of been hung up on and maybe it's just not me understanding things, or things just not laid out etc, etc.

I have always been working with what is in connector today, as opposed to working with the prototype, new stuff.

The JIRA task about testing inflow is a bit abstract, and being that we do indeed have 3 different implementations right now, where would the time be better spent? I would love to work against the prototype, and I feel I am getting a better understanding of the MC, AOP etc, etc, which, frankly are new tools for me.

[weston.price]

However, I definitely think the EJB3 implementation of the MEF should just go away. It's broken as it is, serves no purpose, and if the goal was to remove a dependency on the connector project, I am sure we can devise a much less radical solution than a complete rewrite of something that was already there and functioning correctly.

[kabirkhan]

It could be made "prime time" if you can persuade Kabir
to backport the new aop proxy factory that it uses to AOP 1.3
implementations.

The proxy exists in the AOP 1.5.0 snapshot that is in the 4.0 branch- does that work for you?