[omniORB] DynAny and typecode aliases

[Stephen Crawley]

Renzo wrote:
>     I found a simple workaround to the alias problem. In my case it wor=
ks
> since I can reconstruct the original typecode from a separated stream
> anyway. The basic steps are:
> =

> - create the original typecode;
> - walk down to its first non-alias top-level component (since there is =
no
> specific DynAny for aliases);
> - create the appropriate DynAny;
> - create the any fro the DynAny;
> - replace its typecode (which is now stripped) through the original one=

> using the new value(tc) method. This is new to 2.8 and it works since
> involved typecodes are "equivalent". It works for embedded alias stripp=
ing
> as well.

Renzo,

I don't intend to disparage your ingenuity or your coding style, but that=
 is
disgusting!  It reminds me of the crufty, highly non-portable hacking I h=
ad to
do to create Anys and TypeCodes in Orbix 2.3 :-(

The OMG added DynAny to allow clients build Any values cleanly and portab=
ly.
The fact that you still need to resort to that kind of cruft is direct
evidence that the implementor has misinterpreted the CORBA 2.2 DynAny spe=
c.  =

[Yea I know it was a crock ... but not in that area!] =


Is there a test harness for omniORB's DynAny implementation floating arou=
nd
anywhere?  If there was, I'd have a go at fixing this ...

-- Steve