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
