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
