Reputation: 2069
We have a Java client which is using corba to call several third party systems. These are different systems which implement the same set of interfaces. We were provided libraries (jar files) to use these interfaces. For example, one object from those libraries is
this.that.GeneralException
Now we have to connect to another external system, but they changed the naming by introducing some more package levels, like:
org.example.this.that.GeneralException
My guess was, that the classes above would be recognized as completely different. So I made a copy of the old client, switched to the new library and changed the references according to the new naming sheme. Lacking a test environment for the new system, I connected that client with one of the old systems. And, suprinsingly, it worked pretty well.
Is this something related to corba or what am I missing here?
EDIT
Just received a note from one of the third party developers. Actually, this is in no way related to corba. Instead they are trying to maintain backwards compatibility of their system. Therefore they mapped the new naming scheme to the old one and are now offering the interface under both names simultaneously.
Upvotes: 4
Views: 126
Reputation: 2069
Actually, this is in no way related to corba. Instead they are trying to maintain backwards compatibility of their system. Therefore they mapped the new naming scheme to the old one and are now offering the interface under both names simultaneously.
Upvotes: 0
Reputation: 11638
Stubs and skeletons for CORBA are generated via IDL, in general. Part of the IDL definition defines the package structure in the case of Java generated stubs. By changing the package structure of your client interface classes you basically fulfilled the contract that the ORB would have expected between client and server. The only issues you'd run into would be where the client-side stubs referred to methods which didn't exist on the server.
Upvotes: 3