<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.05">
<TITLE>
The omniORBpy API
</TITLE>
</HEAD>
<BODY >
<A HREF="omniORBpy005.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="omniORBpy007.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>
<H1>Chapter 6 The omniORBpy API</H1>
<A NAME="omniORBapi"></A>In this chapter, we introduce the omniORBpy API. The purpose of this
API is to provide access points to omniORB specific functionality that
is not covered by the CORBA specification. Obviously, if you use this
API in your application, that part of your code is not going to be
portable to run unchanged on other vendors' ORBs. To make it easier to
identify omniORB dependent code, this API is defined in the
`<TT>omniORB</TT>' module.<BR>
<BR>
<A NAME="toc22"></A>
<H2>6.1 ORB initialisation options</H2>
<A NAME="omniorbapioptions"></A><A NAME="sec:ORBargs"></A><TT>CORBA::ORB_init()</TT> accepts the following standard command-line
arguments:<BR>
<BR>
<TABLE CELLSPACING=2 CELLPADDING=0>
<TR><TD ALIGN=left NOWRAP></TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBid omniORB3</TT></TD>
<TD ALIGN=left NOWRAP>The identifier must be `omniORB3'.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBInitRef </TT><<I>ObjectId</I>>=<<I>ObjectURI</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy004.html#sec:insargs">4.2</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBDefaultInitRef </TT><<I>Default URI</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy004.html#sec:insargs">4.2</A>.
</TD>
</TR></TABLE><BR>
and the following omniORB-specific arguments:<BR>
<BR>
<TABLE CELLSPACING=2 CELLPADDING=0>
<TR><TD ALIGN=left NOWRAP></TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBtraceLevel </TT><<I>level</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:rttrace">6.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBtraceInvocations</TT></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:rttrace">6.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBstrictIIOP</TT></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:strictIIOP">6.8</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBgiopMaxMsgSize </TT><<I>size in bytes</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:giopmsg">6.5</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBobjectTableSize </TT><<I>number of entries</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:objtable">6.6</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBserverName </TT><<I>string</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:servername">6.4</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBno_bootstrap_agent</TT></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:bootstrap">6.7</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBverifyObjectExistsAndType </TT><<I>0 or 1</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:lcd">6.8</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBinConScanPeriod </TT><<I>0--max integer</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy007.html#sec:shut">7.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBoutConScanPeriod </TT><<I>0--max integer</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy007.html#sec:shut">7.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBclientCallTimeOutPeriod </TT><<I>0--max integer</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy007.html#sec:shut">7.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBserverCallTimeOutPeriod </TT><<I>0--max integer</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy007.html#sec:shut">7.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBscanGranularity </TT><<I>0--max integer</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="omniORBpy007.html#sec:shut">7.3</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBlcdMode</TT></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:lcd">6.8</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBpoa_iiop_port </TT><<I>port no.</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:nameport">6.2</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBpoa_iiop_name_port </TT><<I>hostname</I>[<I>:port no.]</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:nameport">6.2</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBhelp</TT></TD>
<TD ALIGN=left NOWRAP>Lists all ORB command line options.</TD>
</TR></TABLE><BR>
and these two obsolete omniORB-specific arguments:<BR>
<BR>
<TABLE CELLSPACING=2 CELLPADDING=0>
<TR><TD ALIGN=left NOWRAP></TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBInitialHost </TT><<I>string</I>></TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:bootstrap">6.7</A>.</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>-ORBInitialPort </TT><<I>1--65535</I>>]</TD>
<TD ALIGN=left NOWRAP>See section <A HREF="#sec:bootstrap">6.7</A>.</TD>
</TR></TABLE><BR>
As defined in the CORBA specification, any command-line
arguments understood by the ORB will be removed from <TT>argv</TT> when
the initialisation functions return. Therefore, an application is not
required to handle any command-line arguments it does not understand.<BR>
<BR>
<A NAME="toc23"></A>
<H2>6.2 Hostname and port</H2>
<A NAME="sec:nameport"></A>Normally, omniORB lets the operating system pick which port number it
should use to listen for IIOP calls. Alternatively, you can specify a
particular port using <TT>-ORBpoa_iiop_port</TT>. If you specify
<TT>-ORBpoa_iiop_port</TT> more than once, omniORB will listen on
all the ports you specify.<BR>
<BR>
By default, the ORB can work out the IP address of the host machine.
This address is recorded in the object references of the local
objects. However, when the host has multiple network interfaces and
multiple IP addresses, it may be desirable for the application to
control what address the ORB should use. This can be done by defining
the environment variable <TT>OMNIORB_USEHOSTNAME</TT> to contain the
preferred host name or IP address in dot-numeric form. Alternatively,
the same can be achieved using the <TT>-ORBpoa_iiop_name_port</TT>
option. You can optionally specify a port number too. Again, you can
specify more than one host name by using
<TT>-ORBpoa_iiop_name_port</TT> more than once.<BR>
<BR>
When using omniORB 2.8, these two options are named
<TT>-BOAiiop_port</TT> and <TT>-BOAiiop_name_port</TT>.<BR>
<BR>
<A NAME="toc24"></A>
<H2>6.3 Run-time Tracing and Diagnostic Messages</H2>
<A NAME="sec:rttrace"></A>omniORB can output tracing and diagnostic messages to the standard
error stream. You can vary the amount of tracing using the
<TT>-ORBtraceLevel </TT><<I>level</I>> command line argument. For
instance:<BR>
<BR>
<PRE>
$ example_echo_srv.py -ORBtraceLevel 5
</PRE>You can also inspect or modify the trace level at run-time.
A call to <TT>omniORB.traceLevel(</TT><I>level</I><TT>)</TT> sets
the level; calling the function with no argument returns the current
level.<BR>
<BR>
At the moment, the following trace levels are defined:<BR>
<BR>
<TABLE CELLSPACING=2 CELLPADDING=0>
<TR><TD VALIGN=top ALIGN=left NOWRAP> </TD>
</TR>
<TR><TD VALIGN=top ALIGN=left NOWRAP>level 0</TD>
<TD VALIGN=top ALIGN=left>turn off all tracing and informational messages</TD>
</TR>
<TR><TD VALIGN=top ALIGN=left NOWRAP>level 1</TD>
<TD VALIGN=top ALIGN=left>informational messages only</TD>
</TR>
<TR><TD VALIGN=top ALIGN=left NOWRAP>level 2</TD>
<TD VALIGN=top ALIGN=left>the above plus configuration information</TD>
</TR>
<TR><TD VALIGN=top ALIGN=left NOWRAP>level 5</TD>
<TD VALIGN=top ALIGN=left>the above plus notifications when server threads are
created or communication endpoints are shutdown</TD>
</TR>
<TR><TD VALIGN=top ALIGN=left NOWRAP>level 10--20</TD>
<TD VALIGN=top ALIGN=left>the above plus execution and exception traces</TD>
</TR>
<TR><TD VALIGN=top ALIGN=left NOWRAP>level 25</TD>
<TD VALIGN=top ALIGN=left>the above plus hex dumps of all data sent and received
by the ORB via its network connections.</TD>
</TR></TABLE><BR>
With omniORB 3, you can also use
<TT>-ORBtraceInvocations</TT> to trace all operation invocations.<BR>
<BR>
<A NAME="toc25"></A>
<H2>6.4 Server Name</H2>
<A NAME="sec:servername"></A>Applications can optionally specify a name to identify the server
process. At the moment, this name is only used by the host-based
access control module. See section <A HREF="omniORBpy007.html#sec:accept">7.5</A> for details. The
server name can be changed by specifying the command-line option:
<TT>-ORBserverName </TT><<I>string</I>>.<BR>
<BR>
<A NAME="toc26"></A>
<H2>6.5 GIOP Message Size</H2>
<A NAME="sec:giopmsg"></A>omniORB sets a limit on the GIOP message size that can be sent or
received. The maximum size can be set with the command-line option
<TT>-ORBgiopMaxMsgSize</TT>. The exact value is somewhat
arbitrary. The reason such a limit exists is to provide some way to
protect the server side from resource exhaustion. Think about the case
when the server receives a rogue GIOP(IIOP) request message that
contains a sequence length field set to 2<SUP><FONT SIZE=2>31</FONT></SUP>. With a reasonable
message size limit, the server can reject this rogue message straight
away.<BR>
<BR>
<A NAME="toc27"></A>
<H2>6.6 Object table size</H2>
<A NAME="sec:objtable"></A>omniORB uses a hash table to store the mapping from object keys to
servant objects. Normally, it dynamically re-sizes the hash table when
it becomes too full or too empty. This is the most efficient trade-off
between performance and memory usage. However, since all POA
operations which add or remove objects from the table can (very
occasionally) cause the object table to resize, the time spent in POA
operations is much less predictable than if the table size was fixed.<BR>
<BR>
The <TT>-ORBobjectTableSize</TT> argument allows you to choose a
fixed size for the object table. This prevents omniORB from resizing
it. Note that omniORB uses an open hash table so you can have any
number of objects active, no matter what size table you specify. If
you have many more active objects than hash table entries, object
look-up performance will become linear with the number of objects.<BR>
<BR>
<A NAME="toc28"></A>
<H2>6.7 Obsolete Initial Object Reference Bootstrapping</H2>
<A NAME="sec:bootstrap"></A>Starting from 2.6.0, but superseded by the Interoperable Naming
Service in omniORB 3, a mechanism is available for the ORB runtime to
obtain the initial object references to CORBA services. The bootstrap
service is a special object with the object key `INIT' and the
following interface<A NAME="text16" HREF="#note16"><SUP><FONT SIZE=2>1</FONT></SUP></A>:<BR>
<BR>
<PRE>
// IDL
module CORBA {
interface InitialReferences {
Object get(in ORB::ObjectId id);
// returns the initial object reference of the service
// identified by <id>. For example the id for the
// Naming service is "NameService".
ORB::ObjectIdList list();
// returns the list of service ids that this agent knows
};
};
</PRE>By default, all omniORB servers contain an instance of this object and
are able to respond to remote invocations. To prevent the ORB from
instantiating this object, the command-line option
<TT>-ORBno_bootstrap_agent</TT> should be specified.<BR>
<BR>
In particular, the Naming Service omniNames is able to respond to a
query through this interface and return the object reference of its
root context. In effect, the bootstrap agent provides a level of
indirection. All omniORB clients still have to be supplied with the
address of the bootstrap agent. However, the information is much
easier to specify than a stringified IOR! Another advantage of this
approach is that it is completely compatible with JavaIDL. This makes
it possible for programs written for JavaIDL to share a Naming
Service with omniORB.<BR>
<BR>
The address of the bootstrap agent is given by the
<TT>ORBInitialHost</TT> and <TT>ORBInitialPort</TT> parameter in the
omniORB configuration file (section <A HREF="omniORBpy001.html#sec:setup">1.2</A>). The parameters
can also be specified as command-line options
(section <A HREF="#omniorbapioptions">6.1</A>). The parameter
<TT>ORBInitialPort</TT> is optional. If it is not specified, port
number 900 will be used.<BR>
<BR>
During initialisation, the ORB reads the parameters in the omniORB
configuration file. If the parameter <TT>NAMESERVICE</TT> is
specified, the stringified IOR is used as the object reference of the
root naming context. If the parameter is absent and the parameter
<TT>ORBInitialHost</TT> is present, the ORB contacts the bootstrap
agent at the address specified to obtain the root naming context when
the application calls <TT>resolve_initial_references()</TT>. If neither is
present, <TT>resolve_initial_references()</TT> returns a nil object
reference. Finally, the command line argument
<TT>-ORBInitialHost</TT> overrides any parameters in the
configuration file. The ORB always contacts the bootstrap agent at the
address specified to obtain the root naming context.<BR>
<BR>
Now we are ready to describe a simple way to set up omniNames.<BR>
<BR>
<OL type=1>
<LI>
Start omniNames for the first time on a machine (e.g. wobble):<BR>
<BR>
<TT>$ omniNames -start 1234</TT><BR>
<BR>
<LI> Add to omniORB.cfg:<BR>
<BR>
<TT>ORBInitialHost wobble</TT><BR>
<BR>
<TT>ORBInitialPort 1234</TT><BR>
<BR>
<LI> All omniORB applications will now be able to contact omniNames.<BR>
<BR>
Alternatively, the command line options can be used, for example:<BR>
<BR>
<TT>$ eg3_impl -ORBInitialHost wobble -ORBInitialPort 1234 &</TT><BR>
<BR>
<TT>$ eg3_clt -ORBInitialHost wobble -ORBInitialPort 1234</TT></OL><A NAME="toc29"></A>
<H2>6.8 GIOP Lowest Common Denominator Mode</H2>
<A NAME="sec:lcd"></A>
<A NAME="sec:strictIIOP"></A>Sometimes, to cope with bugs in another ORB, it is necessary to
disable various GIOP and IIOP features in order to achieve
interoperability. If the command line option <TT>-ORBlcdMode</TT> is
present, the ORB enters the so-called `lowest common denominator
mode'. It bends over backwards to cope with bugs in the ORB at the
other end. This is purely a transitional measure. The long term
solution is to report the bugs to the other vendors and ask them to
fix them expediently.<BR>
<BR>
In some (sloppy) IIOP implementations, the message size value in the
IIOP header can be larger than the actual body size, i.e. there is
garbage at the end. As the spec does not say the message size must
match the body size exactly, this is not a clear violation of the
spec. omniORB's default policy is to expect incoming messages to be
formatted properly. Any messages that have garbage at the end will be
rejected.<BR>
<BR>
<TT>-ORBlcdMode</TT> sets omniORB to silently skip the unread part of
such invalid messages. Alternatively, you can change just this policy
with a command line argument of <TT>-ORBstrictIIOP 0</TT>. The
problem with doing this is that the header message size may actually
be garbage, caused by a bug in the sender's code. The receiving thread
may block forever as it tries to read more data from the
connection. In this case the sender won't send any more as it thinks
it has marshalled in all the data.<BR>
<BR>
By default, omniORB uses the GIOP LOCATE_REQUEST message to verify
the existence of an object prior to the first invocation. If another
vendor's ORB is known not to be able to handle this GIOP message, you
can disable this feature with the
<TT>-ORBverifyObjectExistsAndType</TT> option, and hence achieve
interoperability.<BR>
<BR>
<A NAME="toc30"></A>
<H2>6.9 GIOP Requesting Principal field</H2>In versions 1.0 and 1.1 of the GIOP specification, request messages
contain a `principal' field which was intended to identify the client.
The meaning of the principal field was never specified, and its use is
now deprecated. The field is not present in GIOP 1.2. omniORB normally
uses the string `<TT>nobody</TT>' in the principal field. However,
some systems (e.g. the GNOME desktop environment) use the principal
field as an authentication mechanism, so omniORB allows you to
configure the principal by setting the <TT>OMNIORB_PRINCIPAL</TT>
environment variable.<BR>
<BR>
<A NAME="toc31"></A>
<H2>6.10 System Exception Handlers</H2>
<A NAME="sec:exHandlers"></A>By default, all system exceptions which are raised during an operation
invocation, with the exception of <TT>CORBA.TRANSIENT</TT>, are
propagated to the application code. Some applications may prefer to
trap these exceptions within the proxy objects so that the application
logic does not have to deal with the error condition. For example,
when a <TT>CORBA.COMM_FAILURE</TT> is received, an application may just
want to retry the invocation until it finally succeeds. This approach
is useful for objects that are persistent and their operations are
idempotent.<BR>
<BR>
omniORBpy provides a set of functions to install exception handlers.
Once they are installed, proxy objects will call these handlers when
the associated system exceptions are raised by the ORB runtime.
Handlers can be installed for <TT>CORBA.TRANSIENT</TT>,
<TT>CORBA.COMM_FAILURE</TT> and <TT>CORBA.SystemException</TT>. This
last handler covers all system exceptions other than the two covered
by the first two handlers. An exception handler can be installed for
individual proxy objects, or it can be installed for all proxy objects
in the address space.<BR>
<BR>
<H3>6.10.1 CORBA.TRANSIENT handlers</H3>When a <TT>CORBA.TRANSIENT</TT> exception is raised by the ORB runtime,
the default behaviour of the proxy objects is to retry indefinitely
until the operation succeeds, with an exponentially increasing delay
(up to a limit) between retries.<BR>
<BR>
The ORB runtime will raise <TT>CORBA.TRANSIENT</TT> under the following
conditions:<BR>
<BR>
<OL type=1>
<LI> When a <EM>cached</EM> network connection is broken while an
operation invocation is in progress. The ORB will try to open a new
connection at the next invocation.<BR>
<BR>
<LI> When the proxy object has been redirected by a location forward
message by the remote object to a new location and the object at the
new location cannot be contacted. In addition to the
<TT>CORBA.TRANSIENT</TT> exception, the proxy object also resets its
internal state so that the next invocation will be directed at the
original location of the remote object.<BR>
<BR>
<LI> When the remote object reports <TT>CORBA.TRANSIENT</TT>.</OL>You can override the default behaviour by installing your own
exception handler. The function to call has signature:<BR>
<BR>
<PRE>
omniORB.installTransientExceptionHandler(cookie, function [, object])
</PRE>The arguments are a cookie, which is any Python object, a call-back
function, and optionally an object reference. If the object reference
is present, the exception handler is installed for just that object;
otherwise the handler is installed for all objects with no handler of
their own.<BR>
<BR>
The call-back function must have the signature<BR>
<BR>
<PRE>
function(cookie, retries, exc) -> boolean
</PRE>When a <TT>TRANSIENT</TT> exception occurs, the function is called,
passing the cookie object, a count of how many times the operation has
been retried, and the TRANSIENT exception object itself. If the
function returns true, the operation is retried; if it returns false,
the TRANSIENT exception is raised in the application.<BR>
<BR>
<H3>6.10.2 CORBA.COMM_FAILURE and CORBA.SystemException</H3>There are two other functions for registering exception handlers: one
for <TT>CORBA.COMM_FAILURE</TT>, and one for all other
exceptions. For both these cases, the default is for there to be no
handler, so exceptions are propagated to the application.<BR>
<BR>
<PRE>
omniORB.installCommFailureExceptionHandler(cookie, function [, object])
omniORB.installSystemExceptionHandler(cookie, function [, object])
</PRE>In both cases, the call-back function has the same signature
as for <TT>TRANSIENT</TT> handlers.<BR>
<BR>
<A NAME="toc32"></A>
<H2>6.11 Location forwarding</H2>
<A NAME="sec:locationForward"></A>Any CORBA operation invocation can return a <TT>LOCATION_FORWARD</TT>
message to the caller, indicating that it should retry the invocation
on a new object reference. The standard allows ServantManagers to
trigger <TT>LOCATION_FORWARD</TT>s by raising the
<TT>PortableServer::ForwardRequest</TT> exception, but it does not
provide a similar mechanism for normal servants. omniORBpy provides
the <TT>omniORB.LOCATION_FORWARD</TT> exception for this
purpose. The exception object is initialised with the target object
reference. It can be thrown by any operation
implementation. <TT>omniORB.LOCATION_FORWARD</TT> is not supported on
omniORB 2.8.0.<BR>
<BR>
<A NAME="toc33"></A>
<H2>6.12 Dynamic importing of IDL</H2>
<A NAME="sec:importIDL"></A>omniORBpy is usually used with pre-generated stubs. Since Python is a
dynamic language, however, it is possible to compile and import new
stubs at run-time.<BR>
<BR>
Dynamic importing is achieved with <TT>omniORB.importIDL()</TT> and
<TT>omniORB.importIDLString()</TT>. Their signatures are:<BR>
<BR>
<PRE>
importIDL(filename [, args ]) -> tuple
importIDLString(string [, args ]) -> tuple
</PRE>The first function compiles and imports the specified file; the second
takes a string containing the IDL definitions. The functions work by
forking omniidl and importing its output; they both take an optional
argument containing a list of strings which are used as arguments for
omniidl. For example, the following command runs omniidl with an
include path set:<BR>
<BR>
<PRE>
m = omniORB.importIDL("test.idl", ["-I/my/include/path"])
</PRE>Instead of specifying omniidl arguments on each import, you
can set the arguments to be used for all calls using the
<TT>omniORB.omniidlArguments()</TT> function.<BR>
<BR>
Both import functions return a tuple containing the names of the
Python modules which have been imported. The modules themselves can be
accessed through <TT>sys.modules</TT>. For example:<BR>
<BR>
<PRE>
// test.idl
const string s = "Hello";
module M1 {
module M2 {
const long l = 42;
};
};
module M3 {
const short s = 5;
};
</PRE>From Python:<BR>
<BR>
<PRE>
>>> import sys, omniORB
>>> omniORB.importIDL("test.idl")
('M1', 'M1.M2', 'M3', '_GlobalIDL')
>>> sys.modules["M1.M2"].l
42
>>> sys.modules["M3"].s
5
>>> sys.modules["_GlobalIDL"].s
'Hello'
</PRE><HR WIDTH="50%" SIZE=1><DL>
<DT><A NAME="note16" HREF="#text16"><FONT SIZE=5>1</FONT></A><DD> This interface was first defined by Sun's
NEO and is in used in Sun's JavaIDL.
</DL>
<HR>
<A HREF="omniORBpy005.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="omniORBpy007.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
51adff6dc4cce5d695a2dcdb26f1a3d7
>
files
>
322
