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.
Regards,
Alan
|