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

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.


-----Original Message-----
From: Dion Picco [mailto:[email protected]]
Sent: Mittwoch, 1. Februar 2006 20:48
To: Gierschner, Frank
Cc: [email protected]
Subject: Re: [OB-Users] Expected app behaviour on encountering a changed
IDL type on unchanged typecode within the >>=-operator


Hi Frank,

On Mon, Jan 30, 2006 at 03:10:20PM +0100, Gierschner, Frank wrote:
> Hi altogether.
> 
> I have a (low-priority) question about the >>= -operator just to get things clear in my mind: Suppose I have a structure or sequence of anything with a known typecode which reaches my app within an Any and I try to extract it via the forementioned operator. If I would try to extract anything else with a different typecode this operator simply would return false; if the typecode fits and the extraction from the Any could be done it returns true and everything is fine.
> 
> Now suppose the definition of the contained data within the Any was changed (via IDL) but my app was compiled with an old IDL information. Clearly in this case we have broken the rules concerning this interface. But how will my app behave now ? How is my app suggested to cope with this kind of mistake ?
> 
> Initially I supposed my app to throw some kind of MARSHAL-exception, which indeed it does. But I found that during the subsequent stack-unwinding it causes a so-called >DAMAGE after normal block< which also causes other parts of the app to malfunction and run in GPFs. At the result of all this the app itself is no longer approachable and can only be killed.
> 
> Is this app-damaging expected to occurr in this case or are there any issues concerning (UN)MARSHAL-exceptions? 
> 
> (BTW: I used OB422 in "old-wstring-compatibility mode" under windows, whereby the data type is expected to have a (w)string component where another simple data type resides now).
> 
> Thanks for your comments in advance.
> 
> Greetings
> Frank Gierschner
> Development

Let me try to simplify the situation in order to get to the root of the
problem.  If I mistakenly assume something here please correct me.

For all intents and purposes, you have a client talking to a server.
Up until now, both your client and server were compiled with the same
idl definitions of your 'complex type' which contained a wstring.  This
complex type had a corresponding typecode generated for it as well by
the idl compiler.  When you insert your type into the Any (via the <<=
operator), the typecode is also inserted.  During transmission, the type
and typecode get marshaled across the wire to the server.  The server
(when the >>= operator is invoked) checks the typecode of the type you
are unmarshaling.  It it doesn't match, it returns false.  Otherwise it
unmarshals the data and returns true.  
Now you've changed the IDL definition of your type.  This should have
caused a new typecode sequence to be generated for this type.  Your
client is also compiled with the new type and typecode in order for the
<<= operator to insert the data properly into the Any.  However, lets
assume the server hasn't been recompiled.  Now what should happen is
that the typecode as it appears to the client and server is different.
So during the >>= operator, it should simply return false.  

Does this sound correct and if not, what details am I missing here?

-- 
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