Ok, I think I've run into the first problem area. I'm trying to
translate what's getting done in the TSSLinkBuilder to the new paradigm,
and I've bumped up against a problem straight off. Ok, you've given me
the following with what you've implemented: an ejbName, a tssBeanName,
and a list of jndinames used to publish this bean to the naming service.
Now in the TSSLinkBuilder, we were operating on the XML for a single ejb
definition, so the ejbName came from the plan naming context, and was
then converted into an AbstractName instance to complete the GBean
wiring. The TSSLinkBuilder code in question looks like this:
public void buildNaming(XmlObject specDD, XmlObject plan,
Configuration localConfiguration, Configuration remoteConfiguration,
Module module, Map componentContext) throws DeploymentException {
if (plan == null) {
return;
}
AbstractName ejbName = getGBeanName(componentContext);
where the componentContext is used to retrieve an AbstractName for this
ejb using the simple name contained in the plan. But now things are
inverted in the ModuleBuilderExtension, so I need to map the simple name
retrieved from a tss-link element to the corresponding AbstractName for
the EJB in this module context. How do I retrieve that information?
Secondly, TSSLinkBuilder uses the module URI for the first attempt at
resolving the TSSBean information. Here's the code:
URI moduleURI = module.getModuleURI();
String moduleString = moduleURI == null ? null :
moduleURI.toString();
AbstractNameQuery tssBeanName =
ENCConfigBuilder.buildAbstractNameQuery(null, moduleString, tssLink,
NameFactory.EJB_MODULE, NameFactory.EJB_MODULE);
If this fails, than it tries again without the module name. Is this
still a correct usage, or is there something else that should be used here?
Rick
David Blevins wrote:
On Feb 28, 2007, at 3:29 AM, Rick McGuire wrote:
David Blevins wrote:
On Feb 27, 2007, at 4:39 PM, Rick McGuire wrote:
David Blevins wrote:
On Feb 27, 2007, at 5:55 AM, Rick McGuire wrote:
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.
Ok. How about something like:
<tss-link ejb-name="" poa-name=""/>
The only piece of information required is the name of a TSSBean,
assuming all of the same bits of information are still extractable
from the either the plan or other sources. The current usage is
<tss-link>tss-bean-name<tss-link>
I'm not really sure what I'd pick for an attribute name, so keeping
the same syntax is probably easiest.
The two other pieces of information required to complete the
linkage are the EBJ name and the JNDI name(s) this EJB is
registered under. The JNDI names are using to export the EJB to
the CORBA naming service. I assume these same bits of information
are still relevant/available in openejb3.
Couple more questions. Does every ejb in corba need a tss-link and
or tssbean?
Every ejb that's exported via corba will need a tss-link.
Will some ejbs share the same tssbean (i.e. be linked to the same
tss bean)?
Sharing is quite common. The tssbean the ejbs link to determine the
characteristics of the transport and security profile used for access.
If sharing is there, how common is it to have a second tss bean (and
subsequent links).
I think this is fairly common to have more than one tssbean if there
are multiple security profiles defined. Any given EJB, however, is
only linked to one tssbean at a time.
And finally, where is the tssbean itself configured?
I'm not totally certain I understand the context of this question.
The tssbeans are typically defined in a parent configuration play for
the deployed app. A tssbean is attached to a corbabean instance.
The corbabean manages the ORB instance the tssbean is defined for
(defining, for example, the transport-level security
characteristics....i.e., does it use SSL). The TSSBean, when it's
started, creates the POAs on the hosting orb that will be used to
activate the EJBs. The tsslink GBeans handle making the connections
between the exported GBeans and the location used for the export. So
far, I don't believe that there have been any chances at all required
for either corbabean or tssbean for openejb3.
Ok, so I plumbed this in for you;
<tss-link>
<ejb-name></ejb-name>
<tss-name></tss-name>
<jndi-name></jndi-name>
<jndi-name></jndi-name>
<jndi-name></jndi-name>
</tss-link>
It's all in the geronimo-openejb.xsd and data from v2 plans is getting
converted over and now available as an array directly off the
EjbModule.getVendorDD() object.
Let me know if you run into an issue. There's usually something the
first go around.
-David
