OmniNames vs OrbixWeb3.0

[Ian Brennan]

Hi,

You should be able to work around any problems you have with this (I'm
guessing #pragma problems - the interface name of the CORBA Naming
service has not changed and shouldn't need to be)

Try recompiling the IDL file you normally use for OmniNames [using the
OrbixWeb idl compiler] and including the generated stubs in your
OrbixWeb client instead of using the precompiled Naming stubs shipped
with OrbixWeb.  Names is a "pure" CORBA server and doesn't depend on any
special client side magic.

Be warned:  I haven't tried this myself, and won't get a chance to do so
before Xmas :-(
- but it's probably a better approach to take.

I'd be very interested in knowing how you get on.

Ian, QA, IONA Technologies.

-----------------

Chris Fegan wrote:

> Hi all, I am trying to get my OrbixWeb3.0 client to operate with
> omniNames.
>
> I have this setup working with OrbixWeb2.01fine, but moving to 3.0 has
>
> caused problems. My current thinking on the problem is that
> OrbixWeb3.0
> is trying to resolve the naming service to be of type
> org.omg.CORBA.CosNaming
> (by calling is_a() on the service) and failing. Whereas before it was
> trying to
> resolve the naming service as CosNaming (with no preceding
> package/interface name).
> and succeeding.
>
> To alleviate this problem I want to change omniNames service to have
> it's
> interface name to have this preamble org.omg.CORBA. Is this
> mis-guided?
>
> Please give me your thoughts on this.
>
> Chris
>
> --
>
> Chris Fegan
> Lucent Technologies (AusLabs)
> Sydney, Australia