[omniORB] javaORB and OmniORB

[Joachim Janssen]

Hi *,

some time ago we used OmniORB and javaORB together for some testing
purposes and encountered the same problems as Mark and Frederic
were talking about.

We analysed it in more detail and it seems that omniNames is (always)
expecting an 12 bytes binary Object key  (omniObjectKey in file
giopServer.cc).
This is the key you get with the catior tool. In our case it was:

catior -x IOR:01f7ff  ......  (the whole string of your NAMESERVICE IOR)

Which produced  the following output :

Type ID: "IDL:omg.org/Cosnaming/NamingContext:1.0"
1. IIOP 1.0  10.0.1.15 12347 0x36f783d2f0263e4500000001   (12 bytes)

So the key you need to fill in the ORB.ref file of javaORB is this 12 bytes
value (0x36f7....).
However, the problem is that javaORB does not accept hexadecimal values
in the "key()" parameter.

Probably the best way to solve this problem is to change javaORB that it
will
accept hexadecimal values as key.

Since we didn't have the source code of javaORB, we decided to change the
server side (omniNames).

We made the following changes:
We gave the the key() parameter in the ORB.ref file the value as returned by
catior. So :  Key(0x36f783d2f0263e4500000001)   This is an 26 bytes ASCII
string representing the 12 bytes binary key.
And then we made some changes in the HandleRequest() function in
giopServer.cc
Just in front of the line where they test for an 12 bytes keycode (if
(keysize !=
sizeof(omniObjectKey)) we put some extra code that converts the objectkey to
an 12 bytes value when the length of the key was 26.

The good news is that we managed to get it working (for our test purposes).
The bad news is that I don't have the source code of these changes anymore
:-(

I hope this gives you a pointer to solve the problem.
If you're desperately looking for a real patch, I could give you a hand, but
it
will take me some time.
But, as told before, probably it's better to change the client side
(javaORB).

Regards,

Joachim Janssen
Dynamic Consulting International
jjanssen@dci.es


> Hi OmniORBers,
>
> I actually have to cope with the same problem, Mark Howells submited
> afew weeks ago. Unfortunately, I don't manage to solve to make my stuff
> work, I suppose I haven't properly understood the answer which was given
> to Mark.
>
> My problem is the following.
> I'm trying to make a javaORB ( from dog
> http://www.multimania.com/dogweb) client side work with omniNames.
> JavaORB uses a config file to resolve initial refs for the NameService.
> The following entry works with both client and server using javaORB
>
> NameService  Host(my_pc),
> ObjectId(IDL:omg.org/CosNaming/NamingContext:1.0),
> Key(NamingRoot),
> Port(my_port)
>
> If I set my_pc and my_port to match with omniNames configuration, I get
> 'org.omg.CORBA.OBJECT_NOT_EXIST' on attempting to narrow the Naming
> context.
>
> What should I use as ObjectId (id of the initial reference) and Key (its
> simply key) values ? How can I get these values ?
>
>
> I also failed to make eg3 omniORB example work with javaORB Naming
> Service. I only set ORBInitialHost and ORBInitialPort to the machine and
> the port where the service is available. Isn't it enough ?
>
> Thanks
>
>
> --
>    Frederic ROUAS
>    E-mail : frouas@oktal.fr
>
>
>