geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: CORBA ported from OpenEJB 2
Date Tue, 27 Feb 2007 01:53:19 GMT

On Feb 23, 2007, at 7:08 AM, Dain Sundstrom wrote:

> On Feb 23, 2007, at 5:06 AM, Rick McGuire wrote:
>>> 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.

Conditional on the presence of the TSSLink seems optimal.

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

We just need to add that data to the geronimo-openejb.xml schema,  
which is available at EjbModule.getVendorDD().  In the v2 plan I see  
that we have two different elements, tss and tss-link.  What's the  
difference between those two?  If I can get a better understanding I  
can be a better help on the "how" part of adding them to the geronimo- 
openejb.xml.  Once we have a place for the data, we'd just update the  
conversion tool to port it over from the v2 plans and you're good to go.

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

Go with the one method the other extensions override. They're called  
at the very end of each of the matching phases in the ModuleBuilder  
interface.  As far as what needs to be done, you don't need to do  
anything if you don't want to.  They're just hooks there for you to  
have nearly-equal opportunity to do participate in all phases of the  
deployment process.  I say nearly as there are things you can't do  
like determine the module type or create it in createModule as the  
primary builder can, etc.

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

You'd get it from the EjbModule.getVendorDD() when we add that info  
as described above.  But generally, it is possible to put data in the  
plan intended only for the builder extension which is something we  
may want to do someday though not really required for this.  The  
passing of the raw plan is more a "for future use" kind of thing so  
that we could someday do as described and have data passed to the  
builder extension in the plan without having to update the primary  
builder to handle it -- though it would have to know not to handle it.

>> 3)  What form is the plan Object passed to the second createModule 
>> () signature?

It's usually an XMLBeans XmlObject.  Most likely one for a v2 openejb- 
jar.  These are already converted into the geronimo-openejb plan and  
available at builder extension createModule time via  
EjbModule.getVendorDD().  As stated, we just need a spot in the  
geronimo-openejb.xml to put the converted data.

Hope this helps.

-David




Mime
View raw message