geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: CORBA ported from OpenEJB 2
Date Fri, 23 Feb 2007 13:06:32 GMT
I huddled with djencks yesterday to try to figure out what needs to be 
done, and came out of this with a lot of questions (see below).  We 
don't think this is going to be much of a deal, but we're not certain on 
some of the specifics of implementing it.

Rick

David Blevins wrote:
>
> On Feb 9, 2007, at 10:26 PM, Dain Sundstrom wrote:
>
>> On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote:
>>
>>> Dain Sundstrom wrote:
>>>> I have ported the OpenEJB 2 CORBA code and updated it to the 
>>>> OpenEJB 3 APIs.  The code is contained in three new modules 
>>>> geronimo-corba, geronimo-corba-builder and geronimo-yoko.
>>>>
>>>> The CORBA code is highly coupled to Geronimo so I put it in 
>>>> Geronimo.  In the future, I would like to split this code into 
>>>> OpenEJB specific code and Geronimo specific code, but that will 
>>>> take a lot of effort that is currently better spent on Jee5.  
>>>> Hopefully, later this year I'll get time to split the code, but 
>>>> CORBA typically has a really low priority
>>>>
>>>>
>>>> Lastly, the code is ported, but not hooked up.  So, it isn't going 
>>>> to work yet for the thousands of you that use CORBA :)
djencks and I were curious as to why you changed the 
willMergeEnvironment() methods in the 3 corba builders to always return 
true.  We couldn't think of any reason why that would be wanted, and we 
could think of multiple reasons why you wouldn't want that to happen.  
Do you remember why you decided to do that?


>>> For the one person here who does, what does "not hooked up" actually 
>>> mean?  In other words, how an I going to be spending my time in the 
>>> near future :-)
>>
>> I figured you would be asking me that :)
>>
>> All of the GBeans, interceptors, delegates, adapters, etc have been 
>> ported over and I believe make the correct calls to the OpenEJB 3 
>> deployments and containers.  
I've taken a troll through those bits, and I think everything looks 
ok...I hesitate to make a more definitive statement on anything 
involving CORBA :-)


>> The piece that is not hooked up is deployment.  You'll need to hook 
>> the EjbModuleBuilder and add the TSS link GBeans.  You will also need 
>> to enable the CSS naming builder.
Ok, of the 3 builders that are currently there, djencks and I believe 
CorbaRefBuilder and OpenEjbCorbaRefBuilder won't require any/much 
modification (other than the open question of the 
willMergeEnvironments() method).  The function that's currently 
performed in the TSSLinkBuilder needs to be done by a 
CORBAModuleBuilderExtension.  Do you agree?

Also, the CSS naming builder still seems to be enabled.  Am I missing 
something here?

>
> To do that part just implement the ModuleBuilderExtension interface 
> and you can hook into all phases of the EjbModuleBuilder.
This is probably the part I have the most questions on.  Based on what I 
see in the two extensions that Geronimo currently has, I *think* the 
corba extension will need to do the following:

1)  In createModule(), handle merging of the default environments if we 
have one.  Should this be unconditional, or should we make it 
conditional on the presence of TSSLinks as in done in 1.2.
2)  In addGBeans(), create the TSSLink GBeans as is currently done in 
TSSLinkBuilder.  djencks and I couldn't figure out where we need to look 
to find the TSSLink plan entries.  I'm guessing we retrieve it from the 
Module somehow, but I'm not sure how or in what form it will be in when 
retrieved.

Also a couple of side questions. 

1)  There are two different signatures for createModule(), but I notice 
that the other extensions only override one of them.  When are they 
called and what needs to be done here? 
2)  I notice that both of these pass a plan argument, in different forms 
(one File, one Object).  Is it the responsibility of the createModule() 
method to examine the plan and add any relevant information to the 
module shared context?  Is that how we get the TSSLink information we'll 
need in addGBeans()?
3)  What form is the plan Object passed to the second createModule() 
signature?

Rick



>
> -David
>
>> I'm sure there are other things I missed, but that should be the bulk 
>> of the work to hook it up.  Of course then there is the TCK to 
>> contend with :)
>>
>> -dain`
>>
>
>


Mime
View raw message