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.
How many ORB instances are typically in a Geronimo (OpenEJB) server? How do you manage that?
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.
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'll return with some more questions... Kresten Krab Thorup [EMAIL PROTECTED]"We do not inherit the Earth from our parents, we borrow it from our children." Saint Exupery
smime.p7s
Description: S/MIME cryptographic signature
