[omniORB] DynAny and typecode aliases

[Renzo Tomaselli]

Stephen,
    I found a simple workaround to the alias problem. In my case it works
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 strippin=
g
as well.
Thanks,
                Renzo Tomaselli

----- Original Message -----
From: Stephen Crawley <crawley@dstc.edu.au>
To: Renzo Tomaselli <renzo.tomaselli@tecnotp.it>
Cc: <omniorb-list@uk.research.att.com>
Sent: marted=EC 12 ottobre 1999 3.45
Subject: Re: [omniORB] DynAny and typecode aliases


>
> Renzo,
>
> I'm running into a similar problem:
>
>   CORBA::TypeCode_ptr tc =3D // ... typecode for "typedef long Int;"
>
>   CORBA::DynAny_ptr da =3D orb -> create_dyn_basic_type(tc);
>
>   cerr << "kind is " << kind_to_string(da -> type() -> kind()) << endl;
>
> is printing "kind is long", not "kind is alias".
>
> The problem is that CORBA::ORB::create_basic_dyn_any() is stripping
> off the aliasing and creating the DynAnyImpl object with the stripped
> typecode.  This violates the intent of the CORBA 2.2 spec.
>
> It seems that with the current implementation of DynAny in omniORB it
> is not possible to create an Any value for an aliased TypeCode.  Is
> this correct?
>
> -- Steve
>
>
>
>
>
>
>
>