[omniORB] problems with sequence based value types

[Jason Stelzer]

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.

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.


./seq1_WStringValue.hh:211: error: expected class-name before '{' token
./seq1_WStringValue.hh:225: error: expected `)' before "_max"
./seq1_WStringValue.hh:228: error: expected `)' before "_max"
./seq1_WStringValue.hh:259: error: ISO C++ forbids declaration of
`ULong' with no type
./seq1_WStringValue.hh:259: error: invalid use of `::'
./seq1_WStringValue.hh:259: error: `ULong' declared as an `inline' field
./seq1_WStringValue.hh:259: error: expected `;' before "maximum"
./seq1_WStringValue.hh:262: error: expected `;' before "inline"
./seq1_WStringValue.hh:262: error: ISO C++ forbids declaration of
`ULong' with no type
./seq1_WStringValue.hh:262: error: invalid use of `::'
./seq1_WStringValue.hh:262: error: `ULong' declared as an `inline' field
./seq1_WStringValue.hh:262: error: expected `;' before "length"
./seq1_WStringValue.hh:265: error: expected `;' before "inline"
./seq1_WStringValue.hh:265: error: `org::omg::boxedRMI::CORBA::ULong'
has not been declared
./seq1_WStringValue.hh:265: error: ISO C++ forbids declaration of
`_len' with no type
./seq1_WStringValue.hh:269: error: `org::omg::boxedRMI::CORBA::ULong'
has not been declared
./seq1_WStringValue.hh:269: error: ISO C++ forbids declaration of
`_i' with no type
./seq1_WStringValue.hh:275: error: expected `;' before '(' token
./seq1_WStringValue.hh:285: error: `_NP_repositoryId' declared as a
`virtual' field
./seq1_WStringValue.hh:285: error: expected `;' before '(' token
./seq1_WStringValue.hh:289: error: ISO C++ forbids declaration of
`Boolean' with no type
./seq1_WStringValue.hh:289: error: invalid use of `::'
./seq1_WStringValue.hh:289: error: `Boolean' declared as a `virtual'
field
./seq1_WStringValue.hh:289: error: expected `;' before "_NP_custom"
./seq1_WStringValue.hh:290: error: ISO C++ forbids declaration of
`Boolean' with no type
./seq1_WStringValue.hh:290: error: invalid use of `::'
./seq1_WStringValue.hh:290: error: `Boolean' declared as a `virtual'
field
./seq1_WStringValue.hh:290: error: expected `;' before "_NP_box"
./seq1_WStringValue.hh: In copy constructor
`org::omg::boxedRMI::CORBA::seq1_WStringValue::seq1_WStringValue
(const org::omg::boxedRMI::CORBA::seq1_WStringValue&)':
./seq1_WStringValue.hh:222: error: class
`org::omg::boxedRMI::CORBA::seq1_WStringValue' does not have any
field named `ValueBase'
./seq1_WStringValue.hh:222: error: class
`org::omg::boxedRMI::CORBA::seq1_WStringValue' does not have any
field named `DefaultValueRefCountBase'


--
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seq1_WStringValue.idl
Type: application/octet-stream
Size: 508 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070912/167f9dfc/seq1_WStringValue.obj
-------------- next part --------------

[William Bauder]

I can't check it - I'm using 4.0 - but maybe it's not finding the the
CORBA:: types? Do you have an older omniorb (or different orb) in the
INCLUDE?

Personally, I would get away from java/rmi to IDL tools. It's a lot
less grief to write the IDL and generate the C++ and Java code from
that.

-Bill

-----Original Message-----
From: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] On Behalf Of Jason
Stelzer
Sent: Wednesday, September 12, 2007 1:22 PM
To: omniorb-***@omniorb-support.com
Subject: [omniORB] problems with sequence based value types


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.

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.


./seq1_WStringValue.hh:211: error: expected class-name before '{' token
./seq1_WStringValue.hh:225: error: expected `)' before "_max"
./seq1_WStringValue.hh:228: error: expected `)' before "_max"
./seq1_WStringValue.hh:259: error: ISO C++ forbids declaration of
`ULong' with no type
./seq1_WStringValue.hh:259: error: invalid use of `::'
./seq1_WStringValue.hh:259: error: `ULong' declared as an `inline' field
./seq1_WStringValue.hh:259: error: expected `;' before "maximum"
./seq1_WStringValue.hh:262: error: expected `;' before "inline"
./seq1_WStringValue.hh:262: error: ISO C++ forbids declaration of
`ULong' with no type
./seq1_WStringValue.hh:262: error: invalid use of `::'
./seq1_WStringValue.hh:262: error: `ULong' declared as an `inline' field
./seq1_WStringValue.hh:262: error: expected `;' before "length"
./seq1_WStringValue.hh:265: error: expected `;' before "inline"
./seq1_WStringValue.hh:265: error: `org::omg::boxedRMI::CORBA::ULong'
has not been declared
./seq1_WStringValue.hh:265: error: ISO C++ forbids declaration of
`_len' with no type
./seq1_WStringValue.hh:269: error: `org::omg::boxedRMI::CORBA::ULong'
has not been declared
./seq1_WStringValue.hh:269: error: ISO C++ forbids declaration of
`_i' with no type
./seq1_WStringValue.hh:275: error: expected `;' before '(' token
./seq1_WStringValue.hh:285: error: `_NP_repositoryId' declared as a
`virtual' field
./seq1_WStringValue.hh:285: error: expected `;' before '(' token
./seq1_WStringValue.hh:289: error: ISO C++ forbids declaration of
`Boolean' with no type
./seq1_WStringValue.hh:289: error: invalid use of `::'
./seq1_WStringValue.hh:289: error: `Boolean' declared as a `virtual'
field
./seq1_WStringValue.hh:289: error: expected `;' before "_NP_custom"
./seq1_WStringValue.hh:290: error: ISO C++ forbids declaration of
`Boolean' with no type
./seq1_WStringValue.hh:290: error: invalid use of `::'
./seq1_WStringValue.hh:290: error: `Boolean' declared as a `virtual'
field
./seq1_WStringValue.hh:290: error: expected `;' before "_NP_box"
./seq1_WStringValue.hh: In copy constructor
`org::omg::boxedRMI::CORBA::seq1_WStringValue::seq1_WStringValue
(const org::omg::boxedRMI::CORBA::seq1_WStringValue&)':
./seq1_WStringValue.hh:222: error: class
`org::omg::boxedRMI::CORBA::seq1_WStringValue' does not have any
field named `ValueBase'
./seq1_WStringValue.hh:222: error: class
`org::omg::boxedRMI::CORBA::seq1_WStringValue' does not have any
field named `DefaultValueRefCountBase'


--
J.

[Jason Stelzer]

Post by William Bauder
I can't check it - I'm using 4.0 - but maybe it's not finding the the
CORBA:: types? Do you have an older omniorb (or different orb) in the
INCLUDE?

No, only one version of omniorb is installed.

I'm using "omniidl -I. -I/usr/share/idl/omniORB -bcxx c path/to/idl"
to generate the stub code. The other idl files are fine, my problems
center round this specific valuetype.

Post by William Bauder
Personally, I would get away from java/rmi to IDL tools. It's a lot
less grief to write the IDL and generate the C++ and Java code from
that.

That approach is fundamentally incompatible with how jboss has
implemented its corba support. They're using reflection and
annotations and deploying things at runtime. Switching away from
jboss is a battle I can't win. If I can't resolve this I can always
just return a comma delimited string and split it apart on the client
side, but that is a workaround I dont think I should need. That all
said, the idl file in question is very simple. How would you write it
differently? I'm just curious. There may be a cleaner way to specify
"this returns a list of strings".

--
J.

[William Bauder]

Ya, my omniidl does't seem to like CORBA::WStringValue, so I can't
actually compile it (I think it's a 4.1 thing).

I hadn't considered the jboss factor (I guess rmic does make more sense
in that case).

It still sounds like the compiler is missing a reference or having a
collision with something. What are the problem lines in the generated
code? Is there something that defines org::omg::boxedRMI::CORBA::Ulong
(since it's usually just CORBA::Ulong)?

The cleaner way is just to return a sequence of string, but nothing's
ever that simple...

-----Original Message-----
From: Jason Stelzer [mailto:***@healthmarketscience.com]
Sent: Wednesday, September 12, 2007 2:40 PM
To: William Bauder
Cc: 'Jason Stelzer'; omniorb-***@omniorb-support.com
Subject: Re: [omniORB] problems with sequence based value types

Post by William Bauder
I can't check it - I'm using 4.0 - but maybe it's not finding the the
CORBA:: types? Do you have an older omniorb (or different orb) in the
INCLUDE?

No, only one version of omniorb is installed.

I'm using "omniidl -I. -I/usr/share/idl/omniORB -bcxx c path/to/idl"
to generate the stub code. The other idl files are fine, my problems
center round this specific valuetype.

Post by William Bauder
Personally, I would get away from java/rmi to IDL tools. It's a lot
less grief to write the IDL and generate the C++ and Java code from
that.

That approach is fundamentally incompatible with how jboss has
implemented its corba support. They're using reflection and
annotations and deploying things at runtime. Switching away from
jboss is a battle I can't win. If I can't resolve this I can always
just return a comma delimited string and split it apart on the client
side, but that is a workaround I dont think I should need. That all
said, the idl file in question is very simple. How would you write it
differently? I'm just curious. There may be a cleaner way to specify
"this returns a list of strings".

--
J.

[Duncan Grisby]

Post by Jason Stelzer
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?

Post by Jason Stelzer
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.

[Jason Stelzer]

Post by Duncan Grisby

Post by Jason Stelzer
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?

Well, to be honest I haven't figured out how, exactly, jboss
'supports' corba. Discussions in jboss forums have generally resulted
in me asking questions about how they intend for people to use/
configure corba services and being answered with 'why not create a
web service?'. That said, I'm guilty of not reading all the source
code WRT jacorb/jboss integration thoroughly enough to find an
alternative approach. I freely admit that I'm in unfamiliar
territory, and have quite a bit of work to do to catch up. I'll look
harder at how I can write/create corba services running in jboss in a
more sane manner.

Post by Duncan Grisby
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.

Thank you. I can work around this and get stuff working. I was
wondering if the namespace was part of the problem. I'm in the
progress of rebuilding, I imagine things will work now.

Post by Duncan Grisby
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++...

Well, now that I understand what the problem is I can just alter the
names. Thanks again for the insight.



--
J.