Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=6cmzNlbPBnrb2gJUK4PjJNqJxf8OVjkMadwvAclfAP2BPtS9vZRWBSoPfvfYKN/f7PHERER1l+VC5MSUXnmfleIRa3xjhFc7ibxOnDfoD4d1WYxFEUUCFt/SfE4VDZ9rX0PETI7PggoLpRdu4U6ZTikYq4VFflQu2I62VVmVksI=
  ;
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <EBA0419D-714F-4154-85E5-01EA67FA1231@trifork.com>
References: <EBA0419D-714F-4154-85E5-01EA67FA1231@trifork.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <97fb9f7cc934afe05e1c319e5cb9251b@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: orb integration
Date: Mon, 22 Aug 2005 08:38:35 -0700
To: dev@geronimo.apache.org


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?

Not exactly.  A "server" orb can have lots of security configurations, 
represented by TSSBeans.  However, we haven't found a way for a single 
"server" orb to service both unprotected and TLS ports, so you may need 
up to 2 server orbs.  "client" orbs are represented by CSSBeans and 
each have only one security configuration.  If there is a way to 
further reduce the number of orbs, I'd like to know about it.
>
> In the Trifork ORB, every POAManager (and thus potentially every POA) 
> can have it's own security & port configuration.

I think this might correspond to our TSSBeans.
> 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?

Depends on how many things you need to support at once :-)  In an 
actual production server, I'd expect 1 or 2: a "server" orb and a 
"client" orb.  If you need multiple client security configs, you would 
need more client orbs.
>
> 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 are not using openeorb at all in any way.  We are using CGLib 
proxies on the client and a mapping system on the server to avoid stubs 
and skeletons.
>
> 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?

IIUC the classloader management is in StandardServant.  At the moment I 
don't see why the AdapterEntity.ObjectActivator should work for custom 
primary key classes.  Perhaps Dain or Alan can shed some more light on 
this.

thanks
david jencks

>
> I'll return with some more questions...
>
> Kresten Krab Thorup
> krab@trifork.com
>
> "We do not inherit the Earth from our parents, we borrow it from our 
> children." Saint Exupery
>
>
>