geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: orb integration
Date Mon, 29 Aug 2005 04:17:24 GMT
Dain Sundstrom wrote, On 8/22/2005 9:29 AM:

> On Aug 22, 2005, at 5:56 AM, Kresten Krab Thorup wrote:
>> Hi there,
>> I've been working now for a while on this CORBA stuff, and so I  have 
>> some questions regarding how you generalize over different orbs.
>> I have looked through the code in org.openejb.corba.* (in  geronimo), 
>> and from this it looks like that one ORB instance can  only have one 
>> security configuration; is that right?
>> In the Trifork ORB, every POAManager (and thus potentially every  
>> POA) can have it's own security & port configuration.  This makes a  
>> lot of code inside the CORBA implementation quite complicated, but  
>> allows us to deploy beans with different security configurations  all 
>> on the same ORB; and most importantly it allows us to optimize  
>> intra-orb calls in various ways.   However, we can simplify a lot  of 
>> code if we strip out that option.
> I believe that we originally coded the CORBA code using a single orb  
> and policies, but the Sun orb doesn't support policies.  It is my  
> understanding that we want to go back to using policies.
> Alan is the correct?

Yeah, we originally wanted policies associated w/ POAs and a POA 
associated w/ a single container.  We wanted our security code to work 
with any ORB that supported interceptors and custom policies.

>> How many ORB instances are typically in a Geronimo (OpenEJB)  
>> server?  How do you manage that?
> To pass the CTS we had like 10 orbs.  As David Jencks mentioned, one  
> or two would be better.

+1 the less the better.

I am eager to see how you handle the problem with IOR serialization that 
forced us to have multiple ORBs.

>> Also, what is it that determines the class loader used to reify  
>> inbound objects.  For example AdapterEntity.ObjectActivator loads a  
>> primary key from they byte sequence that is the OID of the  activated 
>> object.  Where is the management for these class  loaders?  What is 
>> the logic in controlling these class loaders?
> I'm not if or why that code works.  The Adapter class from which  
> AdapterEntity extends, has a reference to the EJB container and can  
> get the class loader from there, but it doesn't seem to use the class  
> loader for deserialization.  My guess is either this code doesn't  
> work or some code is setting the thread context class loader.

I guess that means that we don't test for fancy keys that "live" in the 
containers classloader space.

How are things going?  I know that there are a lot of people from 
OpenORB that are keen on helping out.


View raw message