[omniORB] changing CORBA interface

[Michael Kilburn]

What kind of changes are allowed to idl interface? In my situation I have to
change server's interface:
- adding new entry to some methods' throw-specification
- adding new constant
- adding new method

existing clients use different ORBs, server uses omniORB. Is it ok to do
these changes? Do I need to add new method to the end of interface?

[Michael Kilburn]

Post by Michael Kilburn

Post by Michael Kilburn
What kind of changes are allowed to idl interface? In my situation I

have to

Post by Michael Kilburn
- adding new entry to some methods' throw-specification

Clients that use this method need to be aware of the new raises
specification
(of course, if the exception is never thrown it shouldn't matter - but I
assume you have a
reason to add the new exception)

Hmm... and what happens if client compiled with old idl file gets an
exception that appeared in new idl file?

[Michael]

Post by Michael Kilburn

Post by Michael Kilburn

Post by Michael Kilburn
What kind of changes are allowed to idl interface? In my situation I

have to

Post by Michael Kilburn
- adding new entry to some methods' throw-specification

Clients that use this method need to be aware of the new raises
specification
(of course, if the exception is never thrown it shouldn't matter - but I
assume you have a
reason to add the new exception)

Hmm... and what happens if client compiled with old idl file gets an
exception that appeared in new idl file?

That may depend on the ORB implementation, I would assume you'll get a CORBA system
exception (maybe MARSHAL). I would suggest that you test this with your actual
implementations and in general I would try to avoid changing signatures on the server side
only.

[Michael Kilburn]

Post by Michael

Post by Michael Kilburn
Hmm... and what happens if client compiled with old idl file gets an
exception that appeared in new idl file?

That may depend on the ORB implementation, I would assume you'll get a CORBA system
exception (maybe MARSHAL). I would suggest that you test this with your actual
implementations and in general I would try to avoid changing signatures on the server side
only.

Good! Before clients were getting CORBA_UNKNOWN, now they'll get basically
the same.
Of course I'll check... (I am catching std::exception and convert it to
something meaningful, instead of letting it slip to ORB, presumably it
should be rare case).

Thank you.

[Thomas Lockhart]

It sounds to me that you are extending the interface. So why not do that
formally and code to the new interface which inherits from the original IDL?

hth

- Tom

[Michael Kilburn]

Post by Thomas Lockhart
It sounds to me that you are extending the interface. So why not do that
formally and code to the new interface which inherits from the original IDL?

1. Change is rather cosmetic, I do not want to make things unnecessarily
complex if possible
2. Changing throw-specs is not something you could address with interface
inheritance

[Kevin Bailey]

Post by Michael Kilburn
2. Changing throw-specs is not something you could address with
interface inheritance

I think what he meant was to have a new method in a new interface
(inheritted from the first interface.) This way, new code can
interrogate the server and find out what it supports, while
old code can treat it unchanged. Since both methods are similar,
there should be opportunities for code re-use in the implementation.

[Haiquan Yang]

Hello, everybody, I need help about how to compile the omniorb4.1.1 on x64
WindowsXP platform.

I have VS2005 installed and followed the guide for win32. I installed
Python2.5 x64. however, the compilation stops with the following errors.
"Import Error: No module named os"

Could anyone tell me what happed.

Best Regards
Haiquan

[Duncan Grisby]

Post by Michael Kilburn
What kind of changes are allowed to idl interface? In my situation I have to
- adding new entry to some methods' throw-specification
- adding new constant
- adding new method
existing clients use different ORBs, server uses omniORB. Is it ok to do
these changes? Do I need to add new method to the end of interface?

According to the CORBA spec, no changes are permitted at all.

However, the way GIOP works means you can add new operations to existing
interfaces, and as long as a client doesn't call the new operation on an
old server, everything will be fine. If a client does call the new
operation on a server that doesn't understand it, you should get a
CORBA::BAD_OPERATION system exception. omniORB correctly does. I can't
tell you about other ORBs.

Adding a constant won't do any harm at all, since constants are just
compiled in to executables. Each one will have either seen it or not.
Changing the value of a constant is dangerous for obvious reasons.

Adding a new exception to an operation's throw clause won't do any harm
unless the exception is thrown to a client that doesn't expect it. If a
client does get an exception is wasn't expecting, it should throw
CORBA::UNKNOWN. Again, omniORB does that, but other ORBs may be less
robust.

Cheers,

Duncan.