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?
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.
Secondly, it looks like OpenEJB/OpenORB includes an RMI/IIOP
binding; you do this mapping statically using
org.openorb.compiler. Do you still compile stubs/skeletons
via .java files with the openorb rmi compiler in that setup? In
the Trifork ORB, there are no skeletons for RMI invocations; this
is data driven off a RMI meta-data structure (even though we do
obviously support skeletons). The same goes for stubs if the
client ORB is out ORB, but here we need proxy stubs which are byte
code generated.
We dynamically generate stubs using
org.openejb.corba.util.DynamicStubClassLoader and we use a single
servant for all EJBs org.openejb.corba.StandardServant.
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.
-dain
