David Jencks wrote:
On Oct 11, 2006, at 7:29 AM, Rick McGuire wrote:
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?
I started trying to do this on the plane to apachecon.... I should
have posted about my progress (or lack thereof)
I moved the TSSBean reference from AbstractRpcDeployment to a new
gbean TSSLinkGBean that I'm putting in the new openejb-corba module.
This is a design change that David Blevins and I have wanted ever
since I put the TSSBean reference in (the predecessor to)
AbstractRpcDeployment.
I missed the method with o.a.l.corba.transaction classes or I moved it
without noticing. In any case I didn't see a problem near this part.
Hmm, well I have something building now (at least on the openejb side),
and am trying to work through the Geronimo changes to get everything to
build. I moved all of the o.a.o.corba tree over to a new module except
for ORBRef and CORBAException, and created a new TSSRef interface class
that has just 3 methods (registerContainer(), unregisterContainer(), and
buildTransactionImportPolicy(). TSSBean implements this interface. The
most difficult part of this was getting the details of
buildTransactionImportPolicy() right, once I discovered it require
fields and methods from the AbstractRpcDeployment class.
Where I got stuck was all the ORBRef stuff in the server classes.
Dain thought that perhaps the only reason we needed the ORBRef was to
work around the lack of policy support in the sun orb. Do you know if
this is true? Is your idea to have the ORBRef interface in core
rather than corba?
Yes, I maintained that as an interface for communication between the
classes. Same concept with my TSSRef class interface.
Should I try to create a branch out of my partial non-compiling
refactoring?
Yes, I think I'd like to see how you approached this.
thanks
david jencks
Rick
