geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: CORBA ported from OpenEJB 2
Date Tue, 06 Mar 2007 17:15:31 GMT

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.

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

View raw message