给定两个 IDL 定义:(我只实现一个客户端,服务器端是固定的。)
// Version 1.2
module Server {
interface IObject {
void Foo1();
void Foo2() raises(EFail);
string Foo3();
// ...
}
};
// Version 2.3
module Server {
interface IObject {
// no longer available: void Foo1();
void Foo2(string x) raises(ENotFound, EFail); // incompatible change
wstring Foo3();
// ...
}
};
(编辑注意:添加了不能重载的Foo3方法,因为返回类型改变了。)
是否有可能在同一个 C++ CORBA 客户端应用程序中编译两个 stub 代码文件?
使用 IDL 编译器的默认设置,上述两个 IDL 定义将导致 stub 代码无法编译到同一个 C++ 模块中,因为您会从链接器中获得多个定义错误。然而,客户端需要能够与两个服务器版本对话。
有哪些可能的解决方案?
(注意:我们使用的是 omniORB )
最佳答案
(添加 Stefan Gustafsson 的回答,发布于 comp.object.corba 2011-03-08)
If you look at it as a C++ problem instead of a CORBA problem, the solution is C++ namespaces. You could try to wrap the different implementations in different C++ namespaces. Like:
namespace v1 {
#include "v1/foo.h" // From foo.idl version 1
}
namespace v2 {
#include "v2/foo.h" // from foo.idl version 2
}
And to be able to compile the C++ proxy/stub code you need to create C++ main files like:
// foo.cpp
namespace v1 {
#include "v1/foo_proxy.cpp" // filename depend on IDL compiler
}
namespace v2 {
#include "v2/foo_proxy.cpp"
}
This will prevent the C++ linker complaining since the names will be different. Of course you could run into problems with C++ compilers not supporting nested namespaces..
A second solution is to implement the invocation using
DII
, you could write a C++ class
class ServerCall {
void foo2_v1() {
// create request
// invoke
}
void foo2_v2(String arg) {
// create_list
// add_value("x",value,ARG_IN)
// create_request
// invoke
}
}
By using DII you can create any invocation you like, and can keep full control of your client code.
我认为这是个好主意,但我还没有尝试过,因此对于不再存在于全局命名空间中的事物,可能会潜伏一些意想不到的惊喜。
关于c++ - 在同一应用程序/模块中使用 CORBA 接口(interface)的不同不兼容版本?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5178031/