Re: Expected app behaviour on encountering a changed IDL type on unchanged typecode within the >>=-operator

Hi Frank,

On Thu, Feb 02, 2006 at 09:43:55AM +0100, Gierschner, Frank wrote:
> Hi Dion.
> 
> Except of the last two sentences of your statement this is correct. 
> But it seems to be incorrect that the received typecode representation has changed due to the IDL and client* recompilation.
> 
> It may be correct that the representation of the typecode of the specified data has changed on the (server) side which provides the any.
> But the typecode representation within my non-recompiled still running app must of course be the old one.
> 
> What happens is that my app compares the typecode of the received any with its own known typecode and found them to be equal.
> Therefore my app starts to marshal the any but of course it expects an old obsolete layout of the contained data.
> 
> Cheers
>  Frank
> 
> *You call it client here though I guess it is the server as my app requests the any from it.
> 

Both your app and your server should have the generated typecode which
gets marshalled into the any.  If this complex type has changed, then
the typecode 'should' be different.  Can you send me the idl definition
for your complex type (before and after the changes) along with the
generated typecodes in both circumstances?
I understand that the server hasn't been recompiled but your app has and
hence should have the new typecode.  Exceptions should not be the issue
as the differing typecodes should handle the marshaling by returning a
false.

Cheers.

-- 
Dion Picco, Software Engineer
IONA Technologies Inc.
Team Orbacus - Your CORBA Source
mailto:[email protected]
http://www.orbacus.com
_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html