H
Hung
Hi there.
I'm facing an backwards compatibility problem with my IDLs here.
Wondering if you guys could verify that this would work.
I have v1 of a particular interface and works with current clients.
Now i have to release v2 of that interface to basically add two
additional request methods and a bunch of structs.
So what I've done is, create v2 which inherited everything from v1.
Sound simple, and the idl crons out perfectly.
That was the easy part.
So i then when to my Java app, where i could build the
implementation from v1 or v2, i implemented v2 only which extends from
the v2 POA. I still have to implement everything from v1, exactly to
the spec of v1.
When clients request for a particular interface (v1 or
v2), I have it so they pass me the name, and i return the string to
narrow to, always return v2, because they use the v1 or v2's Helper
class, they always get the appropriate interfaced ability associated
with which one was requested, albiet on the server its really always
v2.
It seems to work okay when I was testing it, and runs similar to
Java's interface, implemenation, and inheritence workings.
Am I missing something? It seemed almost too easy to kudge this
beast up and not totally screw myself over at some unforseen time.
Thanks.
I'm facing an backwards compatibility problem with my IDLs here.
Wondering if you guys could verify that this would work.
I have v1 of a particular interface and works with current clients.
Now i have to release v2 of that interface to basically add two
additional request methods and a bunch of structs.
So what I've done is, create v2 which inherited everything from v1.
Sound simple, and the idl crons out perfectly.
That was the easy part.
So i then when to my Java app, where i could build the
implementation from v1 or v2, i implemented v2 only which extends from
the v2 POA. I still have to implement everything from v1, exactly to
the spec of v1.
When clients request for a particular interface (v1 or
v2), I have it so they pass me the name, and i return the string to
narrow to, always return v2, because they use the v1 or v2's Helper
class, they always get the appropriate interfaced ability associated
with which one was requested, albiet on the server its really always
v2.
It seems to work okay when I was testing it, and runs similar to
Java's interface, implemenation, and inheritence workings.
Am I missing something? It seemed almost too easy to kudge this
beast up and not totally screw myself over at some unforseen time.
Thanks.