Splitting CORBA support into a separate module.

[Rick McGuire <ri...@gmail.com>]

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

Re: Splitting CORBA support into a separate module.

[Rick McGuire <ri...@gmail.com>]

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
>
>

Re: Splitting CORBA support into a separate module.

[David Jencks <da...@yahoo.com>]

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.

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?

Should I try to create a branch out of my partial non-compiling  
refactoring?

thanks
david jencks


>
> Rick