[omniORB] omniNames 3: how to have both INS and Bootstrap agent ?

[Jean Francois Poilpret]

I just answer to myself...

In fact, I must have misunderstood something when I tried all this, =
since now (after retrying it) it works correctly: I have both true =
INS-conformance and Bootstrap agent with omniNames 3.0.
The only minor issue is that I have to specify -ORBpoa_iiop_port 900 as =
an extra argument for the bootstrap agent to listen to the default port =
(900)., because the bootstrap agent listens on the same port (2089 by =
default) as the Name Service itself.

So there is no problem any longer

    Jean-Fran=E7ois

-----Original Message-----
From: Jean Francois Poilpret <jfpoilpret@hn.vnn.vn>
To: omniORB <omniorb-list@orl.co.uk>
Date: samedi 8 juillet 2000 11:45
Subject: [omniORB] omniNames 3: how to have both INS and Bootstrap agent =
?


Hi omniORB'ers,

I'm still trying to use omniORB 3.0 (and omniNames 3.0) with JDK 1.3 (I =
already submitted the bug related to string_to_object to Sun so now I =
try to find "the best workaround").

In order to be able to use omniNames 3.0 with JDK 1.3, I've got the =
following solutions:

1.    use omniNames 3.0 normally (INS-compliant way, port 2089, =
"NameService" Object Key),
      build an IOR with an Object Key which is understandable by JDK1.3 =
(eg "NameServiceA") with genior
      use omniMapper to forward all requests to the previous object, =
over to the actual Name Service
      use the IOR as an arg to the Java application, and use =
string_to_object then narrow to get the Root NamingContext

- I did not check this solution yet, but I believe this should work =
quite easily
- the bad thing is that I always have to go along with that infamous IOR =
argument in Java apps

After reading the omniORB 3.0 documentation, I discovered there was =
(there should be) another option:

2.    use omniNames 3.0 normally,
      use the bootstrap agent (which still works in omniORB 3.0) which =
is (shoud be) used by JDK 1.3 to get the initial references.

This second solution sounds better to me, because it should (if I =
understood everything):

- enable all my omniORB-built applications (and, in fact, any other =
application built upon an INS-compliant ORB library) to work directly =
with omniNames (through the INS-compliant way, ie use the port 2089 and =
the "NameService" Object Key to get the reference to the Root =
NamingContext)
- enable all my JDK1.3-built application to work directly with omniNames =
(through the bootstrap agent way, ie
use the port 900 and the "INIT" Object Key to request omniNames the =
reference to its Root context)

In this solution, I should not have to use any IOR to specify the =
reference to the Root Context.
Moreover, the code both in my C++ apps and my Java apps still can use =
the "standard" way to get the Root NamingCOntext (I mean, through =
"resolve_initial_references").

This is the theory.
Unfortunately, in practice, the behavior seems different:

If I launch "omniNames -start" (the first time), it only listens to port =
2089. In addition, if I use traceLevel 25, I don't see any trace of an =
"INIT" bootstrap Object created (only the Root NamingContext).

I re-read the omniORB 3 doc and still don't understand why it does not =
work.
Is it that the old, deprecated bootstrap agent is only used by omniORB's =
resolve_initial_references(), allowing for use of other Name Service (as =
tnameserv, the Name Service coming with JDK), but the omniNames itself =
does not create a bootstrap object to answer others' requests ?
This point seems a bit fuzzy to me.

Some details about my configuration:

Linux 2.2.13
gcc 2.95.2
glibc 2.1
omniORB 3.0 (May, 26th 2000 snapshot)

At this time I don't use any omniORB.cfg file (since, if everything =
worked as expected, this should not be necessary, should it ?)

Can someone provide me with some explanations regarding that point ?

Thanks in advance

    Jean-Fran=E7ois Poilpr=EAt