[omniORB] problems with sequence based value types

[Jason Stelzer]

On Sep 12, 2007, at 4:57 PM, Duncan Grisby wrote:

> 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?
>


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.

>
> 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.

>
> 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.