[omniORB] Object by Value timeframe?

[Jeff Schnitzer]

Initially I was planning to reply privately, but I figure others
considering RMI-IIOP (or switching to Orbacus to get OBV) might find
this helpful.  These comments are for Orbacus 4.0.4.
=20
Compiling wasn't my big problem, although it was not eventless.  On my
RH7 box with the latest compiler updates, I kept running out of virtual
memory on one file.  I eventually had to compile that file separately
without optimization; whatever it needs, it's more than a couple hundred
megs of swap. =20
=20
The real pain came when I tried to compile the IDL generated by the jdk
1.3 rmic.  I have simplified my RMI-IIOP Java interfaces as much as
possible, but I still have a return value which is a struct that
contains an array of other structs.  There is, I am quite positive, *no*
way of getting the Orbacus idl compiler to generate sane C++ output for
this case; it generates screwed up include paths and it has some scoping
problems with the boxedRMI classes.  I have to postprocess the output
with a series of sed scripts.  If you want details, see this message:
=20
http://www.ooc.com/pipermail/ob-users/2001-February/015587.html
<http://www.ooc.com/pipermail/ob-users/2001-February/015587.html>=20
=20
To be fair, the Orbacus mailing list is very much like this list (the
developers read it and actively respond), and they offered to look into
the problems.  Unfortunately by the time I posted this I had everything
working and had moved onto other things.  I didn't have time to prepare
an example :-(
=20
All that combined to make my newbie CORBA experience sheer hell for a
couple months.  I thought that using RMI-IIOP would allow me to avoid
much of the CORBA learning curve by staying in Java, but quite the
opposite is true - I even had to get cozy with both the Sun RMI-IIOP
source and the Orbacus source to figure out some of the rediculously
obscure and underdocumented errors I was getting.  Documentation for
RMI-IIOP and OBV is virtually nonexistent.
=20
It's neat now that everything works, but there is no way I would have
gone through this if I knew what I was getting into.  I would have stuck
with omniORB and JavaIDL.
=20
All that said, I hope omniORB supports OBV sometime in the
not-too-distant future so there will be a good, free implementation
available.  Java programmers shouldn't have to understand CORBA to
communicate with C++ distributed objects.
=20
Jeff Schnitzer
jeff@infohazard.org <mailto:jeff@infohazard.org>=20

-----Original Message-----
From: Stakic, Srdjan [mailto:Srdjan.Stakic@icbc.com]
Sent: Tuesday, April 17, 2001 11:47 AM
To: Jeff Schnitzer; omniorb-list@uk.research.att.com
Subject: RE: [omniORB] Object by Value timeframe?





> -----Original Message-----=20
> I currently=20
> have the system running using Orbacus, which as far as I know is the=20
> only freely available (for noncommercial use at least) ORB=20
> that supports=20
> OBV.=20
>=20

MICO has OBV too. However, last time I've checked, it was
single-threaded=20
all the way, and GIOP grammar, while legal, was not optimal (it was=20
unnecessarily repeating repoIds instead of using indirections). In
moving=20
valuetype graphs, it was almost 10 times slower than the ONC RPC / C on=20
the same platform.=20


sbs=20

BTW, how did you build Orbacus? 4.0.5 doesn't link for me (Solaris 2.6,=20
GNU c++ 2.95)=20