djencks has posited several times recently that the CORBA portion of
openejb should be made into a separate module to avoid needing to
include the yoko jar files as a dependency of openejb-core. I took at
look at what changes might be required to allow this, and it looks doable.
In openejb-core, most of the references to o.a.o.corba classes are
either through ORBRef (which is an interface) or TSSBean (which is not
an interface). It should be a fairly simple matter to create an
interface mapping over TSSBean to accomplish the same thing.
Once that's taken care of, there's one remaining problem area. The
AbstractRpcDeployment class has references to a number of
o.a.o.corba.transaction classes. These references are contained in just
a single method, and they are all policy classes. My first thought was
to move the policy classes into the core and keep the remainder of the
corba.transaction classes in the openejb-corba module, but the policy
classes reference a lot of the org.omg.corba classes, as well as other
o.a.o.corba classes.
Then I noticed that AbstractRpcDeployment a) contains a TSSBean
reference and b) the buildTransactionImportPolicy() method doesn't
access any instance data of the implementing class. It appears that
this method could be moved into the TSSBean, giving a very clean
separation of the CORBA classes from core. This assumes that the
TSSBean reference is always non-null (or the
buildTransactionImportPolicy() method will only be called when the
TSSBean reference is non-null). Can anybody confirm that?
Looking at openejb-builder, the code there is dependent on quite a bit
of the config classes in the corba packages for the property editors.
If the openejb-builder module has a dependency on a new openejb-corba
module, does this negate the advantage of separating the corba support
from openejb-core?
Rick
- Splitting CORBA support into a separate module. Rick McGuire
-
