Proxy Tasks for Delegation

[alrubinger]

I've committed the first round of development for EJB3 Proxy. Anyone with spare cycles (I believe Carlo volunteered himself) who wants to look at the following is more than welcome; this will help speed along JNDI Name Conflicts preventing many tests from passing.

1) There are currently two test cases extending from a common base which contains all test logic. Each class tests an implementation of the ProxyFactoryRegistry, an object designed to keep track of / store Proxy Factories.

The In-Memory tests are working; these are just backed by a HashMap.

The JNDI tests are not; these require a backing JNDI Store.

To fix, need standalone startup of the JNP Server (in a @BeforeClass method) and injection for the naming Context within the JndiProxyFactoryRegistry (I've placed comments in the code where this is appropriate).

2) How do we get at a Managed MC Object from an unmanaged one? The JNDI ObjectFactories are instanciated by our JNP Server upon each lookup, so I've no way to make these objects MC Beans on their own. Best I can think is to either do a lookup (but I have no reference to the Kernel/ControllerContext) or introduce an aspect to inject the MC Bean as an instance when the ctor is called. Specifically, I'm talking about McProxyObjectFactory.

3)The tests fail within the JUnit launcher for Eclipse, but this is a second-class citizen so long as all is kosher from the command line.

S,
ALR

[alrubinger]

4) Add tests to ProxyFactoryRegistryUnitTestCaseBase that check to ensure that:

* ProxyFactory.start() is called upon ProxyFactoryRegistry.registerProxyFactory()
* ProxyFactory.stop() is called upon ProxyFactoryRegistry.deregisterProxyFactory()

S,
ALR

[alrubinger]

5) Set up a code coverage M2 Plugin (Where is this being done already?)

S,
ALR

[wolfc]

I've added a name server in beans.xml, so the JNDI test is runnable.

I still don't see the need for any registries. We got enough of those lying around (kernel registry and JNDI itself). Likewise start and stop semantics are then handled by MC.

[wolfc]

I've committed test/proxy/session to illustrate the current JNDI problems. Note that the test is not yet complete.

It also outlines the scope of the proxy component.

[alrubinger]

"wolfc" wrote:
I still don't see the need for any registries. We got enough of those lying around (kernel registry and JNDI itself). Likewise start and stop semantics are then handled by MC.

Both MC and JNDI are specific to the current JVM; abstracting the Registry allows for resources to be defined by key locally only, and maintained elsewhere. This allows us to provide custom load-balancing by distributing EJB lookups, proxy creation, and invocation among different physical machines or clusters.

The Registry itself is an MC Bean; one objective of this component is to leverage MC wherever possible.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
4) Add tests to ProxyFactoryRegistryUnitTestCaseBase that check to ensure that:

* ProxyFactory.start() is called upon ProxyFactoryRegistry.registerProxyFactory()
* ProxyFactory.stop() is called upon ProxyFactoryRegistry.deregisterProxyFactory()

Revision 73366.

S,
ALR

[alrubinger]

Some more for my wishlist:

* Unit Tests for org.jboss.ejb3.proxy.lang.SerializableMethod - hashCode and equals.

* Unit Tests for org.jboss.ejb3.proxy.handler.ProxyInvocationHandlerBase - construct a Proxy using this InvocationHandler and call "handleInvocationDirectly", checking for proper handling of equals, hashCode, and toString - these should be handled directly by the InvocationHandler. Anything else should throw NotEligibleForDirectInvocationException.

S,
ALR

[alrubinger]

"wolfc" wrote:
I still don't see the need for any registries. We got enough of those lying around (kernel registry and JNDI itself). Likewise start and stop semantics are then handled by MC.

I've removed the notion of the ProxyFactoryRegistry, this is now handled by MC via the EJB3 Registrar Facade.

S,
ALR