[omniORB] IOR in Python from hostname and port

Wilson Jimmy - jiwils Jimmy.Wilson@acxiom.com
Fri, 24 Aug 2001 14:07:37 -0500


Just so I can make sure that I clearly understand the issue, I thought the
Orbix/_is_a() problem could be solved with the command line argument
-ORBverifyObjectExistsAndType 0.  If you're utilizing that, and you know
your object key, connecting shouldn't be a big issue (at least in Orbix
3.0.1).  Is there something going on with Orbix 2.3c that I am missing here?

To solve the original post's problem (I think) absent any additional Orbix
2.3c problems, you need to capture the IOR of your servant using
object_to_string, and then use omniORB's catior to figure out what the
object key looks like.

By the way, I should probably modify some pieces of information in my
original template post.  I've learned some more about the use of Orbix's
object markers, and what the default behavior for them is (with Orbix 3.0.1
anyway).

In the original post, the marker component of the object key goes unstated.
The original template looked like this:

corbaloc:iiop:<machine>:<port>/:%5c<machine>:<IR name>:0::IFR:<namespace (if
any)>_<object name>%00

It should look like this:

corbaloc:iiop:<machine>:<port>/:%5c<machine>:<IR
name>:<marker>::IFR:<namespace + '_'><object name>%00

The marker (if you don't manually set it) is just a ASCII representation of
an integer that increments when the next object (servant) is created.  So if
you create 3 servants of the same type, their markers are used by Orbix to
distinguish between them given the above formula.  Their corresponding
markers would be '0', '1', and '2'.  Just as a note, if you destroy a
servant (delete it), the count doesn't get reset or decremented.

Orbix 3.3 makes you set the object marker's manually, so this doesn't hold
true for it.

Jimmy
-- 
James "Jimmy" Wilson
Software Developer, Acxiom Corporation