[omniORB] Inserting CORBA::UserExceptions into an Any

[Duncan Grisby]

On Tuesday 10 December, "Visscher, Bruce" wrote:

> From time to time there have been discussions on this list regarding
> the best way to report the actual type of a CORBA::Exception.  IIRC,
> the consensus was that the best (most portable, etc.) way was to
> insert the exception into a CORBA::Any then use the CORBA::Any::id()
> member function to report the exact type of exception.

The official way now is to use the _name() and _rep_id() member
functions of the exception object. omniORB 4 supports them; omniORB 3
does not, but it would be easy enough to add them.

[...]
> This member appears to be initialized to 0 in NamingSK.cc but in
> NamingDynSK.cc there is a singleton class that has a constructor that
> apparently is supposed to override this.  A static instance of this class
> is declared in this file.
> 
> Unfortunately, if you don't do anything to load NamingDynSK.cc into the
> executable then this singleton instance won't ever be created.  Which
> explains why I see the above message.

Linking with the omniDynamic library ought to cause that singleton to
be created. I guess it's failing for some reason on OpenVMS.

> Am I missing something?  Does omniORB 4 fix this?

It fixes it to the extent you don't need to mess with Anys any more.
I suspect it will have the same issue with the dynamic library,
though.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --