[omniORB] Interoperability problems with JacORB 1.4beta4

[Mike Mascari]

I wrote:
> 
> Duncan Grisby wrote:
> >
> > On Wednesday 14 August, Mike Mascari wrote:
> >
> > > I'm having a bit of an interoperability problem using a JacORB 1.4beta4
> > > client with omniORB4 beta2 (July 12th snapshot) and the Fixed point
> > > type. I have the following IDL:
> >
> > Please post a trace from omniORB with -ORBtraceLevel 40, when JacORB
> > is sending fixed point data. That will print the GIOP traffic so we
> > can see what JacORB is sending.
> 
> Thanks, Duncan. Here it is:
> 
> omniORB: inputMessage: from giop:tcp:65.24.158.68:1116 101 bytes
> 4749 4f50 0102 0000 0000 0059 0000 0010 GIOP.......Y....
> 0300 0000 0000 0000 0000 0014 ff64 6261 .............dba
> 7365 fef4 a25a 3d01 0021 cd00 0000 0000 se...Z=..!......
> 0000 000b 6164 644d 6163 6869 6e65 0000 ....addMachine..
> 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0000 0001 2a05 f3aa 0000 0005 5465 7374 ....*.......Test
> 0004 5500 0c                            ..U..
> omniORB: Dispatching remote call 'addMachine' to: root/dbase<0> (active)
> omniORB: throw MARSHAL from giopImpl12.cc:1132
> (NO,MARSHAL_PassEndOfMessage)

Well, I looked into this further. According to OMG docs, the Java
mapping not only defines the mapping between IDL types and Java types,
but also the interfaces that the stubs and skeletons use. For CORBA 2.3,
the OutputStream interface defined has a method called by the stubs to
generate the CDR:

public final void write_fixed(final java.math.BigDecimal value);

Unfortunately, Java's BigDecimal class knows its own scale, but not the
number of digits. So a Java ORB conforming to the 2.3 OutputStream
interface will generate:

455000c

for "45.5000", not

0000000000455000c

even though the IDL for the type is fixed<16,4>. Of course, unless the
server ORB picks through the bytes until it arrives at either 0xc or
0xd, and then works its way backwards assuming the appropriate scale,
there is no way for it to determine the number of digits in the data. Do
you want to do this, Duncan? ;-)

I've butchered JacORB as a stop-gap to generate 16-digit fixed CDR data
since my application uses 16-digit numeric values everywhere. Hopefully
JacORB will become compliant with the CORBA 2.4 Java mapping, which
surprisingly contains the following interface method:

public void write_fixed(java.math.BigDecimal value, short digits, short
scale);

And, of course, the reason I'm using JacORB instead of Sun's JDK 1.4
built-in ORB is because Sun's ORB decided to steer clear of that whole
hornet's nest altogether by simply not supporting "fixed" at all! 

At any rate, omniORB works great. Its the Java mapping that nuts...

FWIW,

Mike Mascari
mascarm@mascari.com