[omniORB] Possible bug in omniidl regarding _PD_repoId?

[Tarjei Knapstad]

I have encountered an issue when trying to get object references to an
existing server using the IIOP.Net library from a C# application.
After some digging, I found the issue to be a failure in the "is_a()"
call because the _PD_repoId string is not set correctly. The existing
omniORB server code defines several interfaces in separate IDL files
which are then included into a module in a separate IDL file like so:

// myInterface.idl
interface MyInterface {
};

// moduleIncl.idl
module MyModule {
#include "myInterface.idl"
};

When compiling this with omniidl, the _PD_repoId of MyInterface is defined as:

moduleInclSK.cc:const char* MyModule::MyInterface::_PD_repoId =
"IDL:MyInterface:1.0";

However, if I define MyInterface inline in one single file like this:

// moduleInline.idl
module MyModule {
interface MyInterface {
};
};

...then the _PD_repoId string is defined as:

moduleInlineSK.cc:const char* MyModule::MyInterface::_PD_repoId =
"IDL:MyModule/MyInterface:1.0";

The latter is what IIOP.Net asks for when trying to obtain a object
reference. Is this a bug in how omniidl treats include directives? It
seems to disregard the fact that a file was included inside a module,
but I haven't been able to figure out if this is legal IDL in the
first place (the IDLToCLS compiler from IIOP.Net at least puts
MyInterface in the MyModule namespace when compiling the same IDL).

Regards,
--
Tarjei Knapstad

[Duncan Grisby]

On Mon, 2012-10-29 at 10:32 +0100, Tarjei Knapstad wrote:

[...]

Post by Tarjei Knapstad
moduleInlineSK.cc:const char* MyModule::MyInterface::_PD_repoId =
"IDL:MyModule/MyInterface:1.0";
The latter is what IIOP.Net asks for when trying to obtain a object
reference. Is this a bug in how omniidl treats include directives?

No, it's a bug in IIOP.Net. omniidl is correct in not including the
"MyModule" within the repository id. See section 10.6.5.2 of the CORBA
2.6 specification:

...
The specified prefix applies to RepositoryIds generated after
the pragma until the end of the current scope is reached or
another prefix pragma is encountered. An IDL file forms a scope
for this purpose, so a prefix resets to the previous prefix at
the end of the scope of an included file:

...

If an included file does not contain a #pragma prefix, the
current prefix implicitly resets to the empty prefix:

// E.idl
interface E {};

// F.idl
module M {
#include <E.idl>
};

The repository IDs for module M and interface E in this case
are:

IDL:M:1.0
IDL:E:1.0


As a work-around for the bug in IIOP.net, you can use #pragma prefix
"MyModule" at the start of myInterface.idl, which will mean that omniidl
uses the repository id that IIOP.net incorrectly thinks it should have.

Cheers,

Duncan.

[Tarjei Knapstad]

Post by Duncan Grisby
[...]

Post by Tarjei Knapstad
moduleInlineSK.cc:const char* MyModule::MyInterface::_PD_repoId =
"IDL:MyModule/MyInterface:1.0";
The latter is what IIOP.Net asks for when trying to obtain a object
reference. Is this a bug in how omniidl treats include directives?

No, it's a bug in IIOP.Net. omniidl is correct in not including the
"MyModule" within the repository id. See section 10.6.5.2 of the CORBA
[...]
As a work-around for the bug in IIOP.net, you can use #pragma prefix
"MyModule" at the start of myInterface.idl, which will mean that omniidl
uses the repository id that IIOP.net incorrectly thinks it should have.

Thanks for the workaround and for clearing this up for me Duncan, much
appreciated!

Regards,
--
Tarjei