David Blevins wrote:
>
> 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.
I'm about 99.9999% certain that tss was a very old element type that was
never deleted from the schema. The only one I'm aware is still getting
used is the tss-link, so that should be the only thing that needs to be
added. The tss-link element is used to hook an ejb instance to the
appropriate POA to export this as a CORBA object. My experience with
schema is pretty limited (i.e., approaching zero), so any assistance in
that phase would be greatly appreciated.
> 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
>
>
>
>
|