You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/02/09 20:33:02 UTC
CORBA ported from OpenEJB 2
I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB
3 APIs. The code is contained in three new modules geronimo-corba,
geronimo-corba-builder and geronimo-yoko.
The CORBA code is highly coupled to Geronimo so I put it in
Geronimo. In the future, I would like to split this code into
OpenEJB specific code and Geronimo specific code, but that will take
a lot of effort that is currently better spent on Jee5. Hopefully,
later this year I'll get time to split the code, but CORBA typically
has a really low priority.
Lastly, the code is ported, but not hooked up. So, it isn't going to
work yet for the thousands of you that use CORBA :)
-dain
Re: CORBA ported from OpenEJB 2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sun, 2007-02-11 at 18:35 -0800, Dain Sundstrom wrote:
>
> It is the code that binds EJBs to an ORB. The code is a set of CORBA
> portable interceptors, security policies, adapters and a CORBA
> servant. Theoretically, the code will work with any modern orb, but
> our experience is that every ORB is different. The only ORB we
> guarantee this code works with is Yoko.
Ah got it. Muchos gracias!
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Re: CORBA ported from OpenEJB 2
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 11, 2007, at 3:22 PM, Sanjiva Weerawarana wrote:
> On Fri, 2007-02-09 at 11:33 -0800, Dain Sundstrom wrote:
>> I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB
>> 3 APIs. The code is contained in three new modules geronimo-corba,
>> geronimo-corba-builder and geronimo-yoko.
>
> Not being a CORBA nor Geronimo expert this may be a really dumb
> question .. but I'll ask anyway :). Is the OpenEJB CORBA code an
> alternative to Yoko? I thought Yoko also implemented IIOP etc..
It is the code that binds EJBs to an ORB. The code is a set of CORBA
portable interceptors, security policies, adapters and a CORBA
servant. Theoretically, the code will work with any modern orb, but
our experience is that every ORB is different. The only ORB we
guarantee this code works with is Yoko.
-dain
Re: CORBA ported from OpenEJB 2
Posted by David Jencks <da...@yahoo.com>.
On Feb 11, 2007, at 3:22 PM, Sanjiva Weerawarana wrote:
> On Fri, 2007-02-09 at 11:33 -0800, Dain Sundstrom wrote:
>> I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB
>> 3 APIs. The code is contained in three new modules geronimo-corba,
>> geronimo-corba-builder and geronimo-yoko.
>
> Not being a CORBA nor Geronimo expert this may be a really dumb
> question .. but I'll ask anyway :). Is the OpenEJB CORBA code an
> alternative to Yoko? I thought Yoko also implemented IIOP etc..
The openejb (now geronimo) corba code adapts yoko (or, with work,
other orbs) to work with geronimo. The main areas of adaptation are
ssl sockets, connecting the csiv2 stuff up to geronimo (or jaas)
security, and hooking the transaction stuff up (which currently
involves saying "it's not hooked up").
thanks
david jencks
>
> Thanks,
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://
> www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
Re: CORBA ported from OpenEJB 2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2007-02-09 at 11:33 -0800, Dain Sundstrom wrote:
> I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB
> 3 APIs. The code is contained in three new modules geronimo-corba,
> geronimo-corba-builder and geronimo-yoko.
Not being a CORBA nor Geronimo expert this may be a really dumb
question .. but I'll ask anyway :). Is the OpenEJB CORBA code an
alternative to Yoko? I thought Yoko also implemented IIOP etc..
Thanks,
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Re: CORBA ported from OpenEJB 2
Posted by David Jencks <da...@yahoo.com>.
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
>>
>>
>
Re: CORBA ported from OpenEJB 2
Posted by Rick McGuire <ri...@gmail.com>.
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
>
>
Re: CORBA ported from OpenEJB 2
Posted by David Blevins <da...@visi.com>.
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
Re: CORBA ported from OpenEJB 2
Posted by Rick McGuire <ri...@gmail.com>.
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.
Rick
>
> -David
>
>
>
>
Re: CORBA ported from OpenEJB 2
Posted by David Blevins <da...@visi.com>.
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? Will some ejbs share the same tssbean (i.e. be linked to
the same tss bean)? If sharing is there, how common is it to have a
second tss bean (and subsequent links). And finally, where is the
tssbean itself configured?
-David
Re: CORBA ported from OpenEJB 2
Posted by Rick McGuire <ri...@gmail.com>.
David Blevins wrote:
>
> On Feb 27, 2007, at 5:55 AM, Rick McGuire wrote:
>
>> 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.
>
> 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.
Rick
>
> Not sure if poa-name is really the right name (not my area of
> expertise). And of course we can go with elements instead of
> attributes, your choice. Let me know what you want for
> elements/attributes and I'll throw it in today and get the data
> converted over into it.
>
> -David
>
>
Re: CORBA ported from OpenEJB 2
Posted by David Blevins <da...@visi.com>.
On Feb 27, 2007, at 5:55 AM, Rick McGuire wrote:
> 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.
Ok. How about something like:
<tss-link ejb-name="" poa-name=""/>
Not sure if poa-name is really the right name (not my area of
expertise). And of course we can go with elements instead of
attributes, your choice. Let me know what you want for elements/
attributes and I'll throw it in today and get the data converted over
into it.
-David
Re: CORBA ported from OpenEJB 2
Posted by Rick McGuire <ri...@gmail.com>.
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
>
>
>
>
Re: CORBA ported from OpenEJB 2
Posted by David Blevins <da...@visi.com>.
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. 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
Re: CORBA ported from OpenEJB 2
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 23, 2007, at 5:06 AM, Rick McGuire wrote:
> I huddled with djencks yesterday to try to figure out what needs to
> be done, and came out of this with a lot of questions (see below).
> We don't think this is going to be much of a deal, but we're not
> certain on some of the specifics of implementing it.
>
> Rick
>
> David Blevins wrote:
>>
>> On Feb 9, 2007, at 10:26 PM, Dain Sundstrom wrote:
>>
>>> On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote:
>>>
>>>> Dain Sundstrom wrote:
>>>>> I have ported the OpenEJB 2 CORBA code and updated it to the
>>>>> OpenEJB 3 APIs. The code is contained in three new modules
>>>>> geronimo-corba, geronimo-corba-builder and geronimo-yoko.
>>>>>
>>>>> The CORBA code is highly coupled to Geronimo so I put it in
>>>>> Geronimo. In the future, I would like to split this code into
>>>>> OpenEJB specific code and Geronimo specific code, but that will
>>>>> take a lot of effort that is currently better spent on Jee5.
>>>>> Hopefully, later this year I'll get time to split the code, but
>>>>> CORBA typically has a really low priority
>>>>>
>>>>>
>>>>> Lastly, the code is ported, but not hooked up. So, it isn't
>>>>> going to work yet for the thousands of you that use CORBA :)
> djencks and I were curious as to why you changed the
> willMergeEnvironment() methods in the 3 corba builders to always
> return true. We couldn't think of any reason why that would be
> wanted, and we could think of multiple reasons why you wouldn't
> want that to happen. Do you remember why you decided to do that?
We covered this many times. All naming builders were hard coded so
they always add to the environment. This is (was?) because the
deployment system was trying to make this decision before the
annotations were scanned for additional references.
>>>> For the one person here who does, what does "not hooked up"
>>>> actually mean? In other words, how an I going to be spending my
>>>> time in the near future :-)
>>>
>>> I figured you would be asking me that :)
>>>
>>> All of the GBeans, interceptors, delegates, adapters, etc have
>>> been ported over and I believe make the correct calls to the
>>> OpenEJB 3 deployments and containers.
> I've taken a troll through those bits, and I think everything looks
> ok...I hesitate to make a more definitive statement on anything
> involving CORBA :-)
>
>
>>> The piece that is not hooked up is deployment. You'll need to
>>> hook the EjbModuleBuilder and add the TSS link GBeans. You will
>>> also need to enable the CSS naming builder.
> Ok, of the 3 builders that are currently there, djencks and I
> believe CorbaRefBuilder and OpenEjbCorbaRefBuilder won't require
> any/much modification (other than the open question of the
> willMergeEnvironments() method). The function that's currently
> performed in the TSSLinkBuilder needs to be done by a
> CORBAModuleBuilderExtension. Do you agree?
>
> Also, the CSS naming builder still seems to be enabled. Am I
> missing something here?
No idea on either, but this sounds reasonable.
>> 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.
> 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.
>
> 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? 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()?
> 3) What form is the plan Object passed to the second createModule
> () signature?
I think David will have to answer these,
-dain
Re: CORBA ported from OpenEJB 2
Posted by Rick McGuire <ri...@gmail.com>.
I huddled with djencks yesterday to try to figure out what needs to be
done, and came out of this with a lot of questions (see below). We
don't think this is going to be much of a deal, but we're not certain on
some of the specifics of implementing it.
Rick
David Blevins wrote:
>
> On Feb 9, 2007, at 10:26 PM, Dain Sundstrom wrote:
>
>> On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote:
>>
>>> Dain Sundstrom wrote:
>>>> I have ported the OpenEJB 2 CORBA code and updated it to the
>>>> OpenEJB 3 APIs. The code is contained in three new modules
>>>> geronimo-corba, geronimo-corba-builder and geronimo-yoko.
>>>>
>>>> The CORBA code is highly coupled to Geronimo so I put it in
>>>> Geronimo. In the future, I would like to split this code into
>>>> OpenEJB specific code and Geronimo specific code, but that will
>>>> take a lot of effort that is currently better spent on Jee5.
>>>> Hopefully, later this year I'll get time to split the code, but
>>>> CORBA typically has a really low priority
>>>>
>>>>
>>>> Lastly, the code is ported, but not hooked up. So, it isn't going
>>>> to work yet for the thousands of you that use CORBA :)
djencks and I were curious as to why you changed the
willMergeEnvironment() methods in the 3 corba builders to always return
true. We couldn't think of any reason why that would be wanted, and we
could think of multiple reasons why you wouldn't want that to happen.
Do you remember why you decided to do that?
>>> For the one person here who does, what does "not hooked up" actually
>>> mean? In other words, how an I going to be spending my time in the
>>> near future :-)
>>
>> I figured you would be asking me that :)
>>
>> All of the GBeans, interceptors, delegates, adapters, etc have been
>> ported over and I believe make the correct calls to the OpenEJB 3
>> deployments and containers.
I've taken a troll through those bits, and I think everything looks
ok...I hesitate to make a more definitive statement on anything
involving CORBA :-)
>> The piece that is not hooked up is deployment. You'll need to hook
>> the EjbModuleBuilder and add the TSS link GBeans. You will also need
>> to enable the CSS naming builder.
Ok, of the 3 builders that are currently there, djencks and I believe
CorbaRefBuilder and OpenEjbCorbaRefBuilder won't require any/much
modification (other than the open question of the
willMergeEnvironments() method). The function that's currently
performed in the TSSLinkBuilder needs to be done by a
CORBAModuleBuilderExtension. Do you agree?
Also, the CSS naming builder still seems to be enabled. Am I missing
something here?
>
> 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.
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.
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?
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()?
3) What form is the plan Object passed to the second createModule()
signature?
Rick
>
> -David
>
>> I'm sure there are other things I missed, but that should be the bulk
>> of the work to hook it up. Of course then there is the TCK to
>> contend with :)
>>
>> -dain`
>>
>
>
Re: CORBA ported from OpenEJB 2
Posted by David Blevins <da...@visi.com>.
On Feb 9, 2007, at 10:26 PM, Dain Sundstrom wrote:
> On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote:
>
>> Dain Sundstrom wrote:
>>> I have ported the OpenEJB 2 CORBA code and updated it to the
>>> OpenEJB 3 APIs. The code is contained in three new modules
>>> geronimo-corba, geronimo-corba-builder and geronimo-yoko.
>>>
>>> The CORBA code is highly coupled to Geronimo so I put it in
>>> Geronimo. In the future, I would like to split this code into
>>> OpenEJB specific code and Geronimo specific code, but that will
>>> take a lot of effort that is currently better spent on Jee5.
>>> Hopefully, later this year I'll get time to split the code, but
>>> CORBA typically has a really low priority.
>>>
>>> Lastly, the code is ported, but not hooked up. So, it isn't
>>> going to work yet for the thousands of you that use CORBA :)
>> For the one person here who does, what does "not hooked up"
>> actually mean? In other words, how an I going to be spending my
>> time in the near future :-)
>
> I figured you would be asking me that :)
>
> All of the GBeans, interceptors, delegates, adapters, etc have been
> ported over and I believe make the correct calls to the OpenEJB 3
> deployments and containers. The piece that is not hooked up is
> deployment. You'll need to hook the EjbModuleBuilder and add the
> TSS link GBeans. You will also need to enable the CSS naming builder.
To do that part just implement the ModuleBuilderExtension interface
and you can hook into all phases of the EjbModuleBuilder.
-David
> I'm sure there are other things I missed, but that should be the
> bulk of the work to hook it up. Of course then there is the TCK to
> contend with :)
>
> -dain`
>
Re: CORBA ported from OpenEJB 2
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote:
> Dain Sundstrom wrote:
>> I have ported the OpenEJB 2 CORBA code and updated it to the
>> OpenEJB 3 APIs. The code is contained in three new modules
>> geronimo-corba, geronimo-corba-builder and geronimo-yoko.
>>
>> The CORBA code is highly coupled to Geronimo so I put it in
>> Geronimo. In the future, I would like to split this code into
>> OpenEJB specific code and Geronimo specific code, but that will
>> take a lot of effort that is currently better spent on Jee5.
>> Hopefully, later this year I'll get time to split the code, but
>> CORBA typically has a really low priority.
>>
>> Lastly, the code is ported, but not hooked up. So, it isn't going
>> to work yet for the thousands of you that use CORBA :)
> For the one person here who does, what does "not hooked up"
> actually mean? In other words, how an I going to be spending my
> time in the near future :-)
I figured you would be asking me that :)
All of the GBeans, interceptors, delegates, adapters, etc have been
ported over and I believe make the correct calls to the OpenEJB 3
deployments and containers. The piece that is not hooked up is
deployment. You'll need to hook the EjbModuleBuilder and add the TSS
link GBeans. You will also need to enable the CSS naming builder.
I'm sure there are other things I missed, but that should be the bulk
of the work to hook it up. Of course then there is the TCK to
contend with :)
-dain`
Re: CORBA ported from OpenEJB 2
Posted by Rick McGuire <ri...@gmail.com>.
Dain Sundstrom wrote:
> I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB 3
> APIs. The code is contained in three new modules geronimo-corba,
> geronimo-corba-builder and geronimo-yoko.
>
> The CORBA code is highly coupled to Geronimo so I put it in Geronimo.
> In the future, I would like to split this code into OpenEJB specific
> code and Geronimo specific code, but that will take a lot of effort
> that is currently better spent on Jee5. Hopefully, later this year
> I'll get time to split the code, but CORBA typically has a really low
> priority.
>
> Lastly, the code is ported, but not hooked up. So, it isn't going to
> work yet for the thousands of you that use CORBA :)
For the one person here who does, what does "not hooked up" actually
mean? In other words, how an I going to be spending my time in the near
future :-)
Rick
>
> -dain
>