Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <45DEE6D8.7060305@gmail.com>
References: <90CA124C-F49D-48C2-9559-FB5D9AC9E144@iq80.com>
 <45CCF691.1080708@gmail.com> <1370D380-2025-4F5A-B54D-8187F0E8FAA2@iq80.com>
 <7280D1C3-61F2-4810-9929-A6DE4342BD17@visi.com> <45DEE6D8.7060305@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E40BE458-65BC-4199-9173-FB5B2E7A870F@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: CORBA ported from OpenEJB 2
Date: Fri, 23 Feb 2007 07:08:20 -0800
To: dev@geronimo.apache.org

On Feb 23, 2007, at 5:06 AM, Rick McGuire wrote:

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

We covered this many times.  All naming builders were hard coded so  
they always add to the environment.  This is (was?) because the  
deployment system was trying to make this decision before the  
annotations were scanned for additional references.

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

No idea on either, but this sounds reasonable.

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

I think David will have to answer these,

-dain