[omniORB] problems with sequence based value types

[Duncan Grisby]

On Wednesday 12 September, Jason Stelzer wrote:

> I'm working on a library that bridges calls from perl to a java app
> via corba. In the interest of reducing the spaghetti code effect, I'm
> creating interfaces in java that use basic types for return values.
> For example, when I was returning a result of type List<String>, the
> idl generated by rmic pulled in too much of the core java interfaces.
> I've since changed to returning String[] which then results in a
> single valuetype to use. This seems reasonable to me as all I'm
> really after is a list of strings.

As others have said, it would be vastly more simple if you could define
your own IDL, rather than use the inconvenient and bizarre Java to IDL
mapping. If you were writing your own IDL, you'd just define a type as
sequence<string>, and everything would be much easier for everyone
involved.

I find it difficult to believe that JBoss can't support user-defined
IDL. Doesn't it use JacORB internally?

> However, this relatively simple idl doesn't generate stub code which
> compiles. Attached is the idl. When generating the stub code, I'm
> using omniORB 4.1.0. The compiler is gcc 3.4.6 on RHES 4. I've also
> tried using the same version of omniORB on a mac using gcc 4.0.1 with
> similar results. Am I making this more complex than I need to? Is
> there a more succinct way of expressing the interface? This seems
> like it should be a trivial valuetype. Am I just making some basic
> error in the idl? Thanks for any insights.

It's essentially a bug in omniidl, but it's a nasty situation. The
problem is that the generated IDL has a nested module named CORBA. That
confuses the C++ compiler so that some lookups for things in the
standard CORBA top-level namespace actually look in the
org::omg::boxedRMI::CORBA namespace, leading to all the errors you see.
The solution would be to fully scope all references to the standard
CORBA namespace as ::CORBA.

Unfortunately, some C++ compilers (Visual C++ is the main offender) have
bugs that mean not all references to types can be fully scoped. Given
that, I'm not sure it's possible to output C++ that works on all
compilers, and still supports IDL that is perverse enough to include
CORBA as a module name.

Your IDL compiles just fine if you rename the CORBA module to something
else.

I'll look into what can be done about the clashes, but as I say, it may
be a choice between supporting Java's awkward generated IDL or
supporting Visual C++...

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --