On Mar 6, 2007, at 11:35 AM, Rick McGuire wrote:
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?
The easiest solution would be if the openejb builder could construct
a map of simple name to abstract name (or gbeanData) for the ejbs
it's constructing and put that in the componentContext. It that
isn't practical we can figure out enough of the name to construct an
abstract name query to find the ejb at runtime. You can figure out
all of the ejb name except the j2eeType from the module name and ejb
name and by using an interface query we can be sure we're getting
some kind of ejb. If this doesn't make sense let me know and I'll
come up with something more detailed.
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?
I think this is still correct. First we look for a tss bean in the
same module, then we look for one in the set of ancestors.
thanks
david jencks
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
