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?

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.

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.

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.

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.

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.