[omniORB] bugreport - problem using omniifr with CorbaScript

[Roger Barnett]

I'm not sure this is really an omniORB problem, but just to follow up...


> 1. started omniifr with -ORBpoa_iiop_port 9990
> 2. feeded CosNaming.idl from the CorbaScript idl directory to the ifr
> with omniidl
>
> So I started CorbaScript interactive, resolved the nameservice and asked
> for the NS.bind function "syntax":
>
> H:\CorbaScript-1.3.4\idl>cssh
> CorbaScript 1.3.4 (Mar 13 2001) for omniORB3 for C++
> Copyright 1996-2001 LIFL, France
> >>> NS=CORBA.ORB.resolve_initial_references("NameService")
> >>> NS.bind
> < OMG-IDL operation void CosNaming::NamingContext::bind (in string n, in
> string obj) raises(CosNaming::NamingContext::NotFound,
> CosNaming::NamingContext::CannotProceed,
CosNaming::NamingContext::InvalidName,
> CosNaming::NamingContext::AlreadyBound); >
> >>>
>
> Suprise! Both parameters are now of type string, while they should be
> something completely different.
>
> What version of omniORB are you using? I'm using omniORB303 with the
> "latest" release of CorbaScript 1.3.4.


I can confirm I see the same thing with the same configuration. It seems
to be a general problem affecting all typedefs, enums, structs, none of
which are shown properly. We don't get any such problems when using our
own Interface Repository server.

I'm wondering if the type data is being "carried forward" in some way
from the first declaration in an interface or module. For example, if I
look at interface CORBA.OperationDef then the various attributes are all
shown as being of type TypeCode.


Roger B.