[omniORB] Problem with case sensitive IDLs

[Morris, Steve (SW/FW - Rehovot)]

I know that the omniORB IDL compiler supports case insensitive identifiers and I know that this in accordance with the OMG spec., however....

I need to write a Python application that will connect to a large, existing CORBA application that uses a case sensitive IDL compiler.

I think that can change some things in the IDL without causing problems, such as changing PropertyList getMany(in PropertyList propertyList) to PropertyList getMany(in PropertyList myPropertyList).

However, I cannot change others. For instance, I do not have any solution for
struct ForcedDrawer {.....};
struct PaperSource
{
:
ForcedDrawer forcedDrawer;
:
};

Any ideas?

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20071231/e14875de/attachment.htm

[Duncan Grisby]

Post by Morris, Steve (SW/FW - Rehovot)
I need to write a Python application that will connect to a large,
existing CORBA application that uses a case sensitive IDL compiler.

Case sensitive, i.e. broken IDL compiler...

Post by Morris, Steve (SW/FW - Rehovot)
I think that can change some things in the IDL without causing
problems, such as changing PropertyList getMany(in PropertyList
propertyList) to PropertyList getMany(in PropertyList myPropertyList).
However, I cannot change others. For instance, I do not have any
solution for
struct ForcedDrawer {.....};
struct PaperSource
{
ForcedDrawer forcedDrawer;
};

You can fix that by fully qualifying the ForcedDrawer type. e.g. if it's
in the global scope you can use

struct ForcedDrawer {.....};
struct PaperSource
{
::ForcedDrawer forcedDrawer;
};

Alternatively, and much more easily, you can cheat and tell omniidl to
permit identifiers that differ only in case, using the -nc command line
flag.

Cheers,

Duncan.

[Morris, Steve (SW/FW - Rehovot)]

Thanks - the -nc switch solved most of the problems.
I agree with "broken IDL compiler", but I have no control over that. The existing CORBA application was written by another team and is a given.
omniIDL also picked up on a number of errors, such as oneway calls that raise exceptions.

I still have one compiler error that I cannot see my way round. The following code fails because PropertyManagerException is not a type.

exception PropertyManagerException
{
ExceptionCode exceptionCode;
wstring why;
};
typedef sequence<PropertyManagerException> ExceptionList;

I do not see how I can change this without changing the interface. Any ideas?

Regards,
Steve

-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: Tuesday, 01 January, 2008 16:49
To: Morris, Steve (SW/FW - Rehovot)
Cc: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] Problem with case sensitive IDLs

Post by Morris, Steve (SW/FW - Rehovot)
I need to write a Python application that will connect to a large,
existing CORBA application that uses a case sensitive IDL compiler.

Case sensitive, i.e. broken IDL compiler...

Post by Morris, Steve (SW/FW - Rehovot)
I think that can change some things in the IDL without causing
problems, such as changing PropertyList getMany(in PropertyList
propertyList) to PropertyList getMany(in PropertyList myPropertyList).
However, I cannot change others. For instance, I do not have any solution for
struct ForcedDrawer {.....};
struct PaperSource
{
ForcedDrawer forcedDrawer;
};

You can fix that by fully qualifying the ForcedDrawer type. e.g. if it's
in the global scope you can use

struct ForcedDrawer {.....};
struct PaperSource
{
::ForcedDrawer forcedDrawer;
};

Alternatively, and much more easily, you can cheat and tell omniidl to
permit identifiers that differ only in case, using the -nc command line
flag.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

[Duncan Grisby]

Post by Morris, Steve (SW/FW - Rehovot)
I still have one compiler error that I cannot see my way round. The
following code fails because PropertyManagerException is not a type.
exception PropertyManagerException
{
ExceptionCode exceptionCode;
wstring why;
};
typedef sequence<PropertyManagerException> ExceptionList;
I do not see how I can change this without changing the interface. Any ideas?

Wow, that's incredibly broken for an IDL compiler to accept that. What
ORB is it?

I'm not sure what you can do about that. Is the exception declared in
the raises clause of any operations? If it's never used as an
exception, it will probably be ok to change it to be a struct.

Otherwise, for most uses you could declare a struct with the same
members as the exception, but a different name, and declare the sequence
to be a sequence of that struct. For most uses of the type, it will just
work. The only place you might get into trouble is if the sequence is
inserted into an Any, in which case its TypeCode could be different.

Cheers,

Duncan.

[Morris, Steve (SW/FW - Rehovot)]

I am getting the following exception in the code generated by omniidl.

Traceback (most recent call last):
File "C:\projects\JobPreview\JobPreviewFrame.py", line 450, in connectToIPC
ref = registry.find("iPC_CONNECT")
File "C:\projects\JobPreview\registry_idl.py", line 94, in find
return _omnipy.invoke(self, "find", _0_hp.orblite.RegistryPackage.Registry._d_find, args)
File "C:\projects\JobPreview\iPC_Connect_idl.py", line 107, in __init__
_0_iPC_API._objref_PropertyManager.__init__(self)
TypeError: unbound method __init__() must be called with _objref_PropertyManager instance as first argument (got _objref_iPC_Connect instance instead)

Here is a code snippet taken from JobPreviewFrame.py that shows the problem:

orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
obj = orb.string_to_object(ior)
registry = obj._narrow(Registry) # the narrow works
ref = registry.find("iPC_CONNECT") # this call raises the TypeError

Registry is a naming service and find() returns a reference to a registered interface "iPC_CONNECT".

Here is the code in iPC_Connect.idl

#include <iPC_PropertyManager.idl>
module iPC_API {
interface iPC_Connect : PropertyManager
{
boolean testIt( );
};
};

Here is the code in iPC_ PropertyManager.idl

module iPC_API {
interface PropertyManager
{
boolean get(in boolean property);
};
};

Any ideas?

Steve Morris

[Duncan Grisby]

On Thursday 3 January, "Morris, Steve (SW/FW - Rehovot)" wrote:

[...]

Post by Morris, Steve (SW/FW - Rehovot)
File "C:\projects\JobPreview\iPC_Connect_idl.py", line 107, in __init__
_0_iPC_API._objref_PropertyManager.__init__(self)
TypeError: unbound method __init__() must be called with _objref_PropertyManager instance as first argument (got _objref_iPC_Connect instance instead)

[...]

Post by Morris, Steve (SW/FW - Rehovot)
#include <iPC_PropertyManager.idl>
module iPC_API {
interface iPC_Connect : PropertyManager
{
boolean testIt( );
};
};
module iPC_API {
interface PropertyManager
{
boolean get(in boolean property);
};
};

Could that interface declaration be included more than once, or is the
interface declared in more than one file? The generated code that's
failing looks like this

class _objref_iPC_Connect (_0_iPC_API._objref_PropertyManager):
_NP_RepositoryId = iPC_Connect._NP_RepositoryId

def __init__(self):
_0_iPC_API._objref_PropertyManager.__init__(self)

So, on the face of it, the class is definitely correctly derived from
the base class whose __init__ method it's trying to call. The only way
it could fail would be if at some point after that class declaration,
_0_iPC_API._objref_PropertyManager was set to be a different class to
the one that was present at the time the _objref_iPC_Connect class was
declared.

First of all, remove all the generated code and regenerate it, in case
you have something left over from a previous version of the IDL. If that
doesn't help, grep all the _idl.py files looking for duplicate
definitions of the _objref_PropertyManager class.

Cheers,

Duncan.

[Morris, Steve (SW/FW - Rehovot)]

You are correct.
Although I had cut my project down to the two IDLs that I listed, that was enough to cause the problem.
iPC_Connect.idl includes iPC_PropertyManager.idl, but I compiled both, with the result that iPC_PropertyManager.idl was included twice in the py files.
When I only compile iPC_Connect.idl the problem disappears.

Thanks very much,
Steve

-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: Sunday, 06 January, 2008 17:45
To: Morris, Steve (SW/FW - Rehovot)
Cc: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] exception in generated code

On Thursday 3 January, "Morris, Steve (SW/FW - Rehovot)" wrote:

[...]

Post by Morris, Steve (SW/FW - Rehovot)
File "C:\projects\JobPreview\iPC_Connect_idl.py", line 107, in __init__
_0_iPC_API._objref_PropertyManager.__init__(self)
TypeError: unbound method __init__() must be called with _objref_PropertyManager instance as first argument (got _objref_iPC_Connect instance instead)

[...]

Post by Morris, Steve (SW/FW - Rehovot)
#include <iPC_PropertyManager.idl>
module iPC_API {
interface iPC_Connect : PropertyManager
{
boolean testIt( );
};
};
module iPC_API {
interface PropertyManager
{
boolean get(in boolean property);
};
};

Could that interface declaration be included more than once, or is the
interface declared in more than one file? The generated code that's
failing looks like this

class _objref_iPC_Connect (_0_iPC_API._objref_PropertyManager):
_NP_RepositoryId = iPC_Connect._NP_RepositoryId

def __init__(self):
_0_iPC_API._objref_PropertyManager.__init__(self)

So, on the face of it, the class is definitely correctly derived from
the base class whose __init__ method it's trying to call. The only way
it could fail would be if at some point after that class declaration,
_0_iPC_API._objref_PropertyManager was set to be a different class to
the one that was present at the time the _objref_iPC_Connect class was
declared.

First of all, remove all the generated code and regenerate it, in case
you have something left over from a previous version of the IDL. If that
doesn't help, grep all the _idl.py files looking for duplicate
definitions of the _objref_PropertyManager class.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --