geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: orb integration
Date Mon, 22 Aug 2005 16:29:29 GMT
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.


View raw message