Thorough documentation

From jack_44@usa.net Tue Jan 2 10:36:52 2001 From: jack_44@usa.net (Jack P) Date: 2 Jan 01 03:36:52 MST Subject: [omniORB] Naming service. Message-ID: <20010102103652.12905.qmail@nwcst330.netaddress.usa.net> Hi, HAPPY NEW YEAR TO U ALL. Is it possible to have two(or >2) entries in omniORB.cfg file? (The host/port combinations) The Naming service is running on two different machines(1&2). I mean if the machine1 is crashed then client(on machine3) can still get = the work done by contacting the Naming service on machine2. Should we have to specify multiple arguments to resolve_initial_references()function.If possible how thats done? Thanks Jack = ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 From dgrisby@uk.research.att.com Tue Jan 2 15:21:21 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 02 Jan 2001 15:21:21 +0000 Subject: [omniORB] question about possible deadlock In-Reply-To: Message from "Andy Faibishenko" of "Wed, 20 Dec 2000 16:10:19 CST." Message-ID: <200101021521.PAA02222@pineapple.uk.research.att.com> On Wednesday 20 December, "Andy Faibishenko" wrote: > I have a scenario where the client (client method C1) passes an object > reference to a server method S1. Server method S1 immediately calls back > a method (client method C2) on that object reference. Is this a valid > scenario? I am using omniorb 3.0.1 BOA on NT/Solaris. > > When the server calls back will this create a new thread on the client > side? If not, I could see why I am locking up. The callback will be serviced by a new thread, so it will not block. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From rsimkin@htc.com Wed Jan 3 01:38:38 2001 From: rsimkin@htc.com (Simkin, Rick) Date: Tue, 2 Jan 2001 19:38:38 -0600 Subject: [omniORB] Thorough documentation Message-ID: <5B6E5316047CD311B66B009027B0A75C03B4BE9B@hlch01e.htc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07525.E684AF40 Content-Type: text/plain; charset="iso-8859-1" I have just started working on a project using omniORB 3.0.2 to connect to a service written using BOA, but I can't find documentation on the BOA interface. The sample code provided with this remote service makes me aware that the omniORB documentation covers essential points, but not all of CORBA 2.3. I would greatly appreciate a quick guide (a short list, or perhaps a URL) to thorough CORBA documentation (books or on-line): how to learn about BOA and ORB classes, for example, how to determine when to delete a pointer and when to let CORBA do it. Thank you for your help! ================ I speak for myself, not my employer ================= Rick Simkin rick.simkin@htc.com +1 (312) 697-2949 Goldman Sachs/Hull Group * 311 S. Wacker #1400 * Chicago IL 60606-6623 ------_=_NextPart_001_01C07525.E684AF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thorough documentation

I have just started working on a project using = omniORB 3.0.2 to connect
to a service written using BOA, but I can't find = documentation on the
BOA interface. The sample code provided with = this remote service
makes me aware that the omniORB documentation covers = essential points,
but not all of CORBA 2.3.

I would greatly appreciate a quick guide (a short = list, or perhaps a
URL) to thorough CORBA documentation (books or = on-line): how to learn
about BOA and ORB classes, for example, how to = determine when to
delete a pointer and when to let CORBA do it.

Thank you for your help!

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I = speak for myself, not my employer = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Rick = Simkin = = rick.simkin@htc.com = ; +1 (312) 697-2949
Goldman Sachs/Hull Group * 311 S. Wacker #1400 * = Chicago IL 60606-6623

------_=_NextPart_001_01C07525.E684AF40-- From crawley@dstc.edu.au Wed Jan 3 02:04:01 2001 From: crawley@dstc.edu.au (Stephen Crawley) Date: Wed, 03 Jan 2001 12:04:01 +1000 Subject: [omniORB] Thorough documentation In-Reply-To: Message from "Simkin, Rick" of "Tue, 02 Jan 2001 19:38:38 CST." <5B6E5316047CD311B66B009027B0A75C03B4BE9B@hlch01e.htc.com> Message-ID: <200101030203.f0323aH24725@piglet.dstc.edu.au> > I have just started working on a project using omniORB 3.0.2 to connect > to a service written using BOA, but I can't find documentation on the > BOA interface. The sample code provided with this remote service > makes me aware that the omniORB documentation covers essential points, > but not all of CORBA 2.3. Erm ... BOA is not part of CORBA 2.3. If you want documentation on BOA, you'll have to look at the documentation for the ORB that was used to implement the service you are trying to connect to. But I don't see why you would need to do this to implement a client. It does not matter to the client-side what OA was used on the server side. -- Steve From klaus@m-machine.com Wed Jan 3 01:55:26 2001 From: klaus@m-machine.com (Klaus Sonnenleiter) Date: Tue, 02 Jan 2001 20:55:26 -0500 Subject: [omniORB] Thorough documentation References: <5B6E5316047CD311B66B009027B0A75C03B4BE9B@hlch01e.htc.com> Message-ID: <3A52868E.8020109@m-machine.com> The best resource I could find was the Advanced CORBA Programming in C++ book written by Michi Henning and Steve Vinoski published by Addison Wesley. The example code sometimes differs slightly (for example, the omniORB IDL compiler creates different files than the ones in the examples), but it is probably the best you can find. Klaus Sonnenleiter The Media Machine, LLC Simkin, Rick wrote: > I have just started working on a project using omniORB 3.0.2 to connect > to a service written using BOA, but I can't find documentation on the > BOA interface. The sample code provided with this remote service > makes me aware that the omniORB documentation covers essential points, > but not all of CORBA 2.3. > > I would greatly appreciate a quick guide (a short list, or perhaps a > URL) to thorough CORBA documentation (books or on-line): how to learn > about BOA and ORB classes, for example, how to determine when to > delete a pointer and when to let CORBA do it. > > Thank you for your help! > > ================ I speak for myself, not my employer ================= > Rick Simkin rick.simkin@htc.com +1 (312) 697-2949 > Goldman Sachs/Hull Group * 311 S. Wacker #1400 * Chicago IL 60606-6623 > From crawley@dstc.edu.au Wed Jan 3 02:16:37 2001 From: crawley@dstc.edu.au (Stephen Crawley) Date: Wed, 03 Jan 2001 12:16:37 +1000 Subject: [omniORB] Thorough documentation In-Reply-To: Message from Klaus Sonnenleiter of "Tue, 02 Jan 2001 20:55:26 EST." <3A52868E.8020109@m-machine.com> Message-ID: <200101030216.f032GDH25501@piglet.dstc.edu.au> > The best resource I could find was the Advanced CORBA Programming in C++ > book written by Michi Henning and Steve Vinoski published by Addison > Wesley. The example code sometimes differs slightly (for example, the > omniORB IDL compiler creates different files than the ones in the > examples), but it is probably the best you can find. Sorry. Henning & Vinoski does not cover BOA, for reasons explained in section 2.4.5. -- Steve From dgrisby@uk.research.att.com Wed Jan 3 10:05:45 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 03 Jan 2001 10:05:45 +0000 Subject: [omniORB] RMI over IIOP In-Reply-To: Message from Daniel Popowich of "Thu, 28 Dec 2000 14:33:41 EST." <14923.38293.679460.653781@buckland.lilybay.com> Message-ID: <200101031005.KAA09041@pineapple.uk.research.att.com> On Thursday 28 December, Daniel Popowich wrote: > I want to use omniORB to communicate with remote services written in > java. Unfortunately, I work in a java shop where most developers do > not want to have to know IDL. At first glance, RMI over IIOP seems to > be the answer: java-only developers can still work with java and those > that want/need to develop in C++ or python can run 'rmic -iiop -idl' > to generate idl from the java remote interfaces. When I use omniidl > on the the output from rmic I get the following error: I think that this sort of approach is, in general, a bad idea. It's normally the case that the Java interfaces in question are badly arranged for distributed use, unless they were specifically designed for use with RMI. It's usually better to manually write a sensible abstraction in IDL, and a small amount of glue code to adapt the IDL to the existing Java. That said, it would be nice if RMI-IIOP could be used for simple situations. > % rmic -d .. -idl javatest.FooServer > % omniidl -bpython -I /usr/java/jdk1.3/lib Foo.idl > /usr/java/jdk1.3/lib/orb.idl:13: omniORBpy does not support valuetype You may be able to avoid the specific problem you are having. orb.idl is meant to contain ORB-specific definitions for built-in CORBA things, so if Java is doing the right thing (which it quite possibly is not), you should be able to put omniORB's idl directory first on your include search path, so you get omniORB's orb.idl (which is actually empty) rather than Java's. Unfortunately, you'll probably find that Foo.idl also contains valuetypes, so it's likely that this approach will only move the problem somewhere else. > Is there any time frame for support of valuetype? What other gotchas > are there? Are there other solutions? valuetype is on the list of things to do, but we don't have any definite time frame for it. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From rogerb@harlequin.co.uk Wed Jan 3 10:38:11 2001 From: rogerb@harlequin.co.uk (Roger Barnett) Date: Wed, 3 Jan 2001 10:38:11 +0000 Subject: [omniORB] side-effect when setting trace level ? Message-ID: <802569C9.003A6DE0.00@notesman.man.harlequin.co.uk> Hi all. I'm trying to track down the cause of a problem and I was wondering if there any known side-effects when setting the trace detail level using the -ORBtraceLevel command line option ? I'm using omniORB 2.8 running on NT 4 (SP5), and the process in question does the following: - lookup a name in Name Server - if found and associated obj ref not nil - invoke operation on obj ref (via DII if that matters) - if op returns ok then mark obj as "live" - else catch any exceptions - if obj not live - create new obj and rebind entry in NS What happened is that the process hung waiting for the operation to complete, so I restarted it with -ORBtraceLevel 25 ; this showed that the hang was "real" in that the ORB was sitting there happily recovering connections over time. So I restarted it again with -ORBtraceLevel 50 to get more detail; this time there was no hang and the process ran ok. After this, of course, the process could be restarted at any trace level. So, is this a clue to the cause of the problem, a different problem, or the proverbial herring ? TIA Roger Barnett From rsimkin@htc.com Wed Jan 3 14:05:11 2001 From: rsimkin@htc.com (Simkin, Rick) Date: Wed, 3 Jan 2001 08:05:11 -0600 Subject: [omniORB] Thorough documentation Message-ID: <5B6E5316047CD311B66B009027B0A75C03B4BE9C@hlch01e.htc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0758E.3170F410 Content-Type: text/plain; charset="iso-8859-1" Stephen Crawley wrote: > Erm ... BOA is not part of CORBA 2.3. . . . > But I don't see why you would need to do this to implement > a client. It does not matter to the client-side what OA was used on the > server side. Interesting point! I'll guess that it has something to do with the server producing some responses asynchronously, and delivering them via CORBA calls to objects that the client supplies. > If you want documentation on BOA, you'll have to look at the documentation > for the ORB that was used to implement the service you are trying to > connect to. Then that's just what I'll have to do. Thank you. Klaus Sonnenleiter wrote: > The best resource I could find was the Advanced CORBA Programming in C++ > book written by Michi Henning and Steve Vinoski published by Addison > Wesley. Thank you for this reference. I went to a bookstore looking for CORBA books, and saw only OMG's 3.0 reference. I'll check other sources now. ================ I speak for myself, not my employer ================= Rick Simkin rick.simkin@htc.com +1 (312) 697-2949 Goldman Sachs/Hull Group * 311 S. Wacker #1400 * Chicago IL 60606-6623 ------_=_NextPart_001_01C0758E.3170F410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [omniORB] Thorough documentation

Stephen Crawley wrote:
> Erm ... BOA is not part of CORBA 2.3.
. . .
> But I don't see why you would = need to do this to implement
> a client. It does not matter to the = client-side what OA was used on the
> server side.

Interesting point! I'll guess that it has something = to do with the
server producing some responses asynchronously, and = delivering them
via CORBA calls to objects that the client = supplies.

> If you want documentation on BOA, you'll have to = look at the documentation
> for the ORB that was used to implement the = service you are trying to
> connect to.

Then that's just what I'll have to do. Thank = you.

Klaus Sonnenleiter wrote:
> The best resource I could find was the Advanced = CORBA Programming in C++
> book written by Michi Henning and Steve Vinoski = published by Addison
> Wesley.

Thank you for this reference. I went to a bookstore = looking for CORBA
books, and saw only OMG's 3.0 reference. I'll check = other sources now.

------_=_NextPart_001_01C0758E.3170F410-- From laurent.pointal@lure.u-psud.fr Wed Jan 3 14:38:22 2001 From: laurent.pointal@lure.u-psud.fr (Laurent Pointal) Date: Wed, 03 Jan 2001 15:38:22 +0100 Subject: [omniORB] OmniORBpy and packaging Message-ID: <4.2.0.58.20010103143056.00c5b2e0@webmail.lure.u-psud.fr> First, its the time, so happy new year to all omniorb lists readers. Here is just a note about a problem I found. I use the stubs generated by OmniORB from an IDL interface as a part of a larger Python package. So, the file structure is as this: /myPackage/__init__.py /myPackage/myInterface.idl /myPackage/myInterface_idl.py /myPackage/myInterface\__init__.py /myPackage/myInterface_POA\__init__.py And is in the python path. In this structure, myInterface\__init__.py and myInterface_POA\__init__.py import myInterface_idl.py. The problem is that myInterface_idl.py is not itself in the python path, it must be called with import myPackage.myInterface_idl to be found with the current path. A solution may be to have myInterface\__init__.py and myInterface_POA\__init__.py to dynamically update sys.path to ensure it contains their parent directory, and then import myInterface_idl.py. As a short-cut solution, I moved generated stubs directly in . A+ Laurent. --- Laurent POINTAL - CNRS/LURE - Service Informatique Experiences Tel/fax: 01 64 46 82 80 / 01 64 46 41 48 email : laurent.pointal@lure.u-psud.fr ou lpointal@planete.net ou laurent.pointal@laposte.net From dgrisby@uk.research.att.com Wed Jan 3 14:55:11 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 03 Jan 2001 14:55:11 +0000 Subject: [omniORB] OmniORBpy and packaging In-Reply-To: Message from Laurent Pointal of "Wed, 03 Jan 2001 15:38:22 +0100." <4.2.0.58.20010103143056.00c5b2e0@webmail.lure.u-psud.fr> Message-ID: <200101031455.OAA10281@pineapple.uk.research.att.com> On Wednesday 3 January, Laurent Pointal wrote: > I use the stubs generated by OmniORB from an IDL interface as a part of a > larger Python package. [...] > The problem is that myInterface_idl.py is not itself in the python path, it > must be called with import myPackage.myInterface_idl to be found with the > current path. You should use the -Wbpackage option to omniidl like omniidl -bpython -Wbpackage=myPackage foo.idl That will put both the stubs and the modules in myPackage, with the correct import statements. You can put them in different packages with -Wbstubs and -Wbmodules. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From popowich@chiliad.com Wed Jan 3 15:53:37 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 3 Jan 2001 10:53:37 -0500 Subject: [omniORB] RMI over IIOP In-Reply-To: <200101031005.KAA09041@pineapple.uk.research.att.com> References: <14923.38293.679460.653781@buckland.lilybay.com> <200101031005.KAA09041@pineapple.uk.research.att.com> Message-ID: <14931.19201.871088.99404@buckland.lilybay.com> Duncan Grisby writes: > On Thursday 28 December, Daniel Popowich wrote: > > > I want to use omniORB to communicate with remote services written in > > java. Unfortunately, I work in a java shop where most developers do > > not want to have to know IDL. At first glance, RMI over IIOP seems to > > be the answer: java-only developers can still work with java and those > > that want/need to develop in C++ or python can run 'rmic -iiop -idl' > > to generate idl from the java remote interfaces. When I use omniidl > > on the the output from rmic I get the following error: > > I think that this sort of approach is, in general, a bad idea. It's > normally the case that the Java interfaces in question are badly > arranged for distributed use, unless they were specifically designed > for use with RMI. It's usually better to manually write a sensible > abstraction in IDL, and a small amount of glue code to adapt the IDL > to the existing Java. That said, it would be nice if RMI-IIOP could be > used for simple situations. I wouldn't say it's bad. The interfaces I'm compiling are explicitly for RMI use, so while not ideal, using RMI over IIOP at least gives some tool to allow non java code to communicate with servers written in java. In particular, I was hoping to be able to use omniORBpy to offer simple scripting tools to communicate with some servers; any weirdnesses in the Java->IDL->python mapping I'd hide on the python side with nice class definitions. > > % rmic -d .. -idl javatest.FooServer > > % omniidl -bpython -I /usr/java/jdk1.3/lib Foo.idl > > /usr/java/jdk1.3/lib/orb.idl:13: omniORBpy does not support valuetype > > You may be able to avoid the specific problem you are having. orb.idl > is meant to contain ORB-specific definitions for built-in CORBA > things, so if Java is doing the right thing (which it quite possibly > is not), you should be able to put omniORB's idl directory first on > your include search path, so you get omniORB's orb.idl (which is > actually empty) rather than Java's. Foo.idl references ::CORBA::WStringValue which is defined in Java's orb.idl as a valuetype: // IDL not generated by rmic, do not edit // These are all in IDL module CORBA // The Java classes are in the package org.omg.CORBA // See ValueType Semantics:Standard Value Box Definitions (5.3) in CORBA 2.3 spec #ifndef __org_omg_CORBA__ #define __org_omg_CORBA__ #pragma prefix "omg.org" module CORBA{ valuetype StringValue string; valuetype WStringValue wstring; }; #include "ir.idl" #pragma prefix "" #endif omniORB doesn't support wstring either, if I'm not mistaken. > valuetype is on the list of things to do, but we don't have any > definite time frame for it. > Oh well. Back to the drawing board. Thanks, Daniel From crawley@dstc.edu.au Wed Jan 3 23:42:34 2001 From: crawley@dstc.edu.au (Stephen Crawley) Date: Thu, 04 Jan 2001 09:42:34 +1000 Subject: [omniORB] Thorough documentation In-Reply-To: Message from "Simkin, Rick" of "Wed, 03 Jan 2001 08:05:11 CST." <5B6E5316047CD311B66B009027B0A75C03B4BE9C@hlch01e.htc.com> Message-ID: <200101032342.f03NgBH09981@piglet.dstc.edu.au> > Stephen Crawley wrote: > > But I don't see why you would need to do this to implement > > a client. It does not matter to the client-side what OA was used on the > > server side. > > Interesting point! I'll guess that it has something to do with the > server producing some responses asynchronously, and delivering them > via CORBA calls to objects that the client supplies. That shouldn't make any difference to what I said ... unless you've decided to implement the "client"-side callback objects using BOA too. I'd recommend transitioning to using POA on both OmniORB and the ORB used to implement your server ... as soon as practical. If the OmniORB client side objects are all transient callbacks, that is the easy place to start. -- Steve From robert@peac.com Wed Jan 3 22:28:25 2001 From: robert@peac.com (Robert Kermode) Date: Wed, 03 Jan 2001 17:28:25 -0500 Subject: [omniORB] omniORB under Cygwin with gnu compiler Message-ID: <3A53A789.1BE2BE94@portalsphere.com> Hello, I am presently trying to port an omniORB-based server program developed on Linux to NT. I am using Cygwin, and ideally would like to use the gnu compiler. I am aware that if I do, I must also compile omniORB under Cygwin with the gnu compiler, rather than using the omniORB binaries compiled with the Microsoft VC++ compiler, on account of different name-mangling conventions and other incompatibiliies. My question is this: Has anyone attempted to compile omniORB using the gnu compiler under Cygwin? I believe omniORB may use some parts of the STL not yet included in Cygwin (apologies to Cygwin if I am mistaken in this) and am wondering what I'm up against. My preference for gnu over VC++ is not (merely) doctrinal -I am in for some considerable changes if I try to do the port entirely with the Microsoft compiler. Thanks very much for any help, Robert Kermode robert@portalsphere.com From zdx_nari@sina.com Thu Jan 4 12:18:28 2001 From: zdx_nari@sina.com (zdx_nari) Date: Thu, 4 Jan 2001 20:18:28 +0800 Subject: [omniORB] How to compile my source file in linux Message-ID: <20010104121828.2947.qmail@sina.com> Hello, I am a new user of omniORB. Now when I use omniORB, I have a problem not to be solved to this day. The problem is : How to compile my source file with the right pre-processor defines in Redhat Linux 6.2 and how to pass these flags -D__x86__ -D__linux__ -D__OSVERSION__=2 to the compiler.Could you give me a complete example. Thanks very much! ______________________________________ =================================================================== ��ѵ�� http://mail.sina.com.cn ��ѡ�ֻ��򵥣�(http://mall.sina.com.cn/yesmobile/) From erberj@post.ch Thu Jan 4 14:18:21 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 4 Jan 2001 15:18:21 +0100 Subject: [omniORB] OmniOrb 3 and Factory Finder Interface Message-ID: <26D7602EA56DD21197BB0000F840029A03EA54D9@hceh71.post.ch> Hi, does OmniOrb support this interface? Best regards Jakob From erberj@post.ch Thu Jan 4 14:39:53 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 4 Jan 2001 15:39:53 +0100 Subject: [omniORB] Building OmniOrb3 examples on VMS Message-ID: <26D7602EA56DD21197BB0000F840029A03EA54DA@hceh71.post.ch> Hello, when trying to build the examples, omniidl gives the following error, which I do not understand: can somebody give me a Hint here? Best regards Jakob GDC006>make all Making ALL in [SRC.EXAMPLES.ECHO]... %CREATE-I-EXISTS, [STUB] already exists Compiling /OMNIROOT/IDL/ECHO.IDL... 'import exceptions' failed; use -v for traceback Warning! Falling back to string-based exceptions 'import site' failed; use -v for traceback Traceback (innermost last): File "", line 1, in ? I m p o r t E r r o r : N o m o d u l e n a m e d o s %DCL-F-NOMSG, Message number 00038004 %MMS-F-ABORT, For target .FIRST, CLI returned abort status: %X00038004. -CLI-F-NOMSG, Message number 00038004 %MMS-F-ABORT, For target ALL, CLI returned abort status: %X10EE8034. %MMS-F-ABORT, For target ALL, CLI returned abort status: %X10EE8034. %MMS-F-ABORT, For target ALL, CLI returned abort status: %X10EE8034. From o.thiboutot@voxco.com Thu Jan 4 14:37:45 2001 From: o.thiboutot@voxco.com (Olivier Thiboutot) Date: Thu, 4 Jan 2001 09:37:45 -0500 Subject: [omniORB] Thorough documentation Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0765B.E6E14B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, For information about "Advanced CORBA Programming in C++", this is = the online store : or call 1-800-824-7799 = (North-America only... I supposed...!) Klaus Sonnenleiter wrote:=20 > The best resource I could find was the Advanced CORBA Programming in = C++=20 > book written by Michi Henning and Steve Vinoski published by Addison=20 > Wesley.=20 Thank you for this reference. I went to a bookstore looking for CORBA=20 books, and saw only OMG's 3.0 reference. I'll check other sources now.=20 Olivier Thibout=F4t=20 VOXCO Inc.=20 o.thiboutot@voxco.com=20 tel : (514) 861-9255=20 fax : (514) 861-9209=20 ------_=_NextPart_001_01C0765B.E6E14B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [omniORB] Thorough documentation

Hi, For information about = "Advanced CORBA Programming in C++", this is the online store = : <http://store.awl.com/> or call 1-800-824-7799 (North-America = only... I supposed...!)

Klaus Sonnenleiter = wrote:
> The best resource I = could find was the Advanced CORBA Programming in C++
> book written by Michi Henning = and Steve Vinoski published by Addison
> Wesley.
Thank you for this reference. I = went to a bookstore looking for CORBA
books, and saw only OMG's = 3.0 reference. I'll check other sources now.
Olivier Thibout=F4t
VOXCO Inc.
o.thiboutot@voxco.com
tel : (514) 861-9255
fax : (514) 861-9209

------_=_NextPart_001_01C0765B.E6E14B80-- From visschb@rjrt.com Thu Jan 4 14:54:00 2001 From: visschb@rjrt.com (Bruce Visscher) Date: Thu, 04 Jan 2001 09:54:00 -0500 Subject: [omniORB] Building OmniOrb3 examples on VMS References: <26D7602EA56DD21197BB0000F840029A03EA54DA@hceh71.post.ch> Message-ID: <3A548E88.A6DCCAAC@rjrt.com> Hi Jacob, erberj@post.ch wrote: > [...] > GDC006>make all > > Making ALL in [SRC.EXAMPLES.ECHO]... > %CREATE-I-EXISTS, [STUB] already exists > Compiling /OMNIROOT/IDL/ECHO.IDL... > 'import exceptions' failed; use -v for traceback > Warning! Falling back to string-based exceptions > 'import site' failed; use -v for traceback > Traceback (innermost last): > File "", line 1, in ? > I > m > p > o > r > t > E > r > r > o > r > : N > o > > m > o > d > u > l > e > > n > a > m > e > d > > o > s > ImportError: No module named os (Python's habit of writing one character at a time to the console doesn't get along with VMS mailboxes very well...) Check your PYTHONPATH symbol? What happens if you just "import os" from python? HTH, Bruce -- Bruce Visscher visschb@rjrt.com CONFIDENTIALITY NOTE: This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney-client or other legal privileges, and/or proprietary non-public information. If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message and/or any of its attachments (if any) by unintended recipients is not authorized and may be unlawful. From chris.newbold@laurelnetworks.com Thu Jan 4 15:19:12 2001 From: chris.newbold@laurelnetworks.com (Chris Newbold) Date: Thu, 04 Jan 2001 10:19:12 -0500 Subject: [omniORB] Default for omniORB::diiThrowsSysExceptions is wrong References: Message-ID: <3A549470.7000909@laurelnetworks.com> It appears that the default value for omniORB::diiThrowsSysExceptions is wrong, or at least in disagreement with the documentation. The documentation claims that from 2.8.0 the default is TRUE. The actual value seems to be FALSE, as found in omniORB.cc. -Chris Newbold Laurel Networks, Inc. From erberj@post.ch Thu Jan 4 16:09:29 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 4 Jan 2001 17:09:29 +0100 Subject: [omniORB] OmniOrb 3 and C Message-ID: <26D7602EA56DD21197BB0000F840029A03EA54DC@hceh71.post.ch> Hi, does OmniOrb3 also support simple C, if yes, what Do I have do specify as backend with the idl command? Best regards Jakob From hany@peac.com Thu Jan 4 11:56:54 2001 From: hany@peac.com (Hany Greiss) Date: Thu, 04 Jan 2001 11:56:54 +0000 Subject: [omniORB] Apache module Message-ID: <3A546506.12D211D8@peac.com> Hello, I have recently moved to omni-orb from mico. The server port was quite smooth and the performance of the server has improved, multi-threading, etc. I am having significant problems porting our Apache extension module. For some unknown reason, the call to the ORB_init function hangs. I know the right one is getting called because if I pass it anything other than omniORB3 as the last parameter it complains as it should. Has anyone tried writing an Apache module using omni-orb and if so, were similar problems seen? The configuration I am working on is Linux, RedHat 6.1, gcc 2.95. Thanks, Hany hany@portalsphere.com From dgrisby@uk.research.att.com Thu Jan 4 17:00:56 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 04 Jan 2001 17:00:56 +0000 Subject: [omniORB] fixed data type In-Reply-To: Message from Joel Schuster of "Wed, 27 Dec 2000 11:31:00 MST." <3A4A3564.F56993FA@cctus.com> Message-ID: <200101041700.RAA18251@pineapple.uk.research.att.com> On Wednesday 27 December, Joel Schuster wrote: > It seems that the Fixed data type has not yet > been implemented in the CORBA 2.3 compiant > OmniORB 3.0. Does anyone know when it will be > or if there is a development branch where it is? Fixed is not yet available. It is on the list of things to do, but we can't give a definite time-scale. Probably sooner rather than later, since it's quite simple. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 4 17:12:21 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 04 Jan 2001 17:12:21 +0000 Subject: [omniORB] OmniOrb 3 and Factory Finder Interface In-Reply-To: Message from erberj@post.ch of "Thu, 04 Jan 2001 15:18:21 +0100." <26D7602EA56DD21197BB0000F840029A03EA54D9@hceh71.post.ch> Message-ID: <200101041712.RAA18333@pineapple.uk.research.att.com> On Thursday 4 January, erberj@post.ch wrote: > does OmniOrb support this interface? What do you mean by support? The FactoryFinder is specified in IDL, so omniORB supports it in the sense that you can write client and server code which uses the interface. If you mean does omniORB provide an implementation of the interface, then no. The whole Life Cycle service is really just a design pattern. Implementations of all the interfaces are application specific. If you need something like the FactoryFinder, I strongly recommend that you write your own similar interface which is less generic. It will save you a lot of pain. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 4 17:15:13 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 04 Jan 2001 17:15:13 +0000 Subject: [omniORB] OmniOrb 3 and C In-Reply-To: Message from erberj@post.ch of "Thu, 04 Jan 2001 17:09:29 +0100." <26D7602EA56DD21197BB0000F840029A03EA54DC@hceh71.post.ch> Message-ID: <200101041715.RAA18370@pineapple.uk.research.att.com> On Thursday 4 January, erberj@post.ch wrote: > does OmniOrb3 also support simple C, if yes, what Do I have do specify as > backend with the idl command? No, omniORB does not support C, just C++ and Python. There is, of course, no reason why you can't interface C++ CORBA code with existing C code. If you _really_ want to use the unbelievably awkward C mapping, you should try ORBit or ILU. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From hany@peac.com Thu Jan 4 12:28:53 2001 From: hany@peac.com (Hany Greiss) Date: Thu, 04 Jan 2001 12:28:53 +0000 Subject: [omniORB] omni and Apache Message-ID: <3A546C85.52CA092B@peac.com> Hello again, Just to follow up on my previous e-mail regarding hanging on the call to ORB_init from within an Apache module. I came across a suggestion to insert tracing within the argc/argv parameters. When I did this the only output I received was, omniORB: strand Ripper: start. It appears to hang at this point. Any ideas? Thanks, Hany hany@portalsphere.com From eliot@isogen.com Thu Jan 4 15:21:41 2001 From: eliot@isogen.com (W. Eliot Kimber) Date: Thu, 04 Jan 2001 09:21:41 -0600 Subject: [omniORB] Re: A Stab at Python COM-to-CORBA Binding Generation References: <3A4D1462.5A1DD54A@isogen.com> Message-ID: <3A549505.DCA4FF14@isogen.com> "W. Eliot Kimber" wrote: > Here is the code. Enjoy. We've refined the code to the point that I think it is pretty complete. We've tested it by writing a little VB GUI against our CORBA objects. We've fixed a nasty ommission in the first version I posted, added support for "narrow", and figured out how to autogenerate all classes, including the "top level" class that makes the initial CORBA connection. Below are two packages, "gencombind.py" and "com2corba.py". gencombind.py is the omniidl back end, com2corba.py is a set of static classes and methods used by the generated classes. The code assumes the default mapping of IDL module/interface to python packages used by OmniIDL. Typical usage of the generated classes is (here using VB code): dim myServer as Object Set myServer = CreateObject("MyProject.MyServer") myServer.initializeCorbaReference ("corbaname::localhost#MyServer") If Err.Number <> 0 Then MsgBox "Creation of my server object failed: " & Err.Description Return End If dim obj2 as Object set obj2 = myServer.getSomeOtherObject() print obj2.getName() ' Prints the objects name. This would be from the IDL-defined methods. Each corba class has a built-in ClassName method and exposes the narrow() method, e.g.: dim obj3 as Object set obj3 = obj2.narrow("myproject.Module1.Interface2") if not obj3 is Nothing: print obj3.ClassName() ' should be "Interface2" It would easy to expose other CORBA-specific properties, such as the fully-qualified interface name, but I haven't done that yet just because I haven't found a need for it yet. It would also be easy to generate the inverse of this binding: Python that exposes COM objects through CORBA using OmniORB. That could be really useful for quickly corbatizing legacy COM systems at almost zero cost. gencombind.py: --- cut here --- #------------------------------------------------------------- # # COM-to-IDL Binding Generator # # Copyright (c) 2000, 2001 DataChannel, Inc. # # This software may be used for any purpose without restriction as long # as the above copyright notice is maintained. # # $Id$ #--------------------------------------------------------------- """ OmniORB back end for generating Python COM server classes that implement the IDL and delegate to the corresponding Python CORBA classes. To use this back end, use the omniidl command (provided with the OmniORB package). Go to the directory that contains the IDL you want to process and issue this command: omniidl -I. -bbonnellcorba.gencombind Bonnell.idl > outputfile.py After generating the COM binding file (outputfile.py), you must run that file to register the COM classes: python outputfile.py """ from omniidl import idlast, idlvisitor, idlutil, idltype import string import pythoncom progidMain = "myProduct" # FIXME: get this from an argument declaredClasses = [] # List of classes declared, used to generate COM registrations narrowLookups = {} # Dictionary for mapping IDL defined classname # to (stub class, wrap class) class ComVisitor (idlvisitor.AstVisitor): def visitAST(self, node): for n in node.declarations(): n.accept(self) def visitModule(self, node): print "import %s" % string.join(node.scopedName(), ".") for n in node.definitions(): n.accept(self) def visitInterface(self, node): name = node.identifier() fqName = string.join(node.scopedName(), ".") narrowLookups[fqName] = name global declaredClasses declaredClasses.append(name) guid = pythoncom.CreateGuid() desc = name # FIXME: generate a better description. progid = "%s.%s" % (progidMain, name) print """ class %s(CorbaWrapper): _reg_clsid_ = "%s" _reg_desc_ = "%s" _reg_progid_ = "%s" _public_attrs_ = [] _readonly_attrs_ = [] scopedName = "%s" corbaStubClass = %s """ % (name, guid, desc, progid, fqName, fqName) # Now generate the list of public methods spacingVar = " " * 22 publicMethodList = \ "'narrow',\n%s'ClassName',\n%s'initializeCorbaReference',\n%s" % \ (spacingVar, spacingVar, spacingVar) callables = node.callables() for callable in callables: if callable.__class__ == idlast.Operation: publicMethodList = "%s'%s',\n%s" % (publicMethodList, callable.identifier(), spacingVar) print " _public_methods_=[%s]" % publicMethodList print """ def lookupWrapClassForStubClass(self, stubClassName): return narrowLookups[stubClassName] """ for callable in callables: if callable.__class__ == idlast.Operation: generateMethodForOperation(callable) def generateMethodForOperation(operation): """ Given an operation, generates the corresponding COM-specific Python method. """ methodName = operation.identifier() comParms = "self" parms = operation.parameters() corbaParms = "" if len(parms) > 0: for param in parms: if param.is_in(): comParms = "%s, %s" % (comParms, param.identifier()) corbaParms = "%s%s," % (corbaParms, comparm2corbaparm(param)) corbaParms = corbaParms[:-1] # Slice off trailing "," print "\n def %s(%s):" % (methodName, comParms) returnType = operation.returnType() returnKind = returnType.kind() if returnKind == idltype.tk_alias: returnType = operation.returnType().unalias() returnKind = returnType.kind() # print "### returnKind=%s" % returnKind if returnKind == idltype.tk_void: print " self.corbaObject.%s(%s)" % (methodName, corbaParms) elif returnKind == idltype.tk_objref: print " return wrap(%s(self.corbaObject.%s(%s)))" % \ (returnType.name(), methodName, corbaParms) elif returnKind == idltype.tk_sequence: seqType = returnType.seqType() print " objs = self.corbaObject.%s(%s)" % (methodName, corbaParms) print " comObjs = []" if seqType.kind() == idltype.tk_objref: print " for obj in objs:" print " comObjs.append(wrap(%s(obj)))" % \ seqType.name() elif seqType.kind() == idltype.tk_string: print " for string in objs:" print " comObjs.append(str(string))" else: print " comObjs = objs" print " return wrap(Collection(data = comObjs))" else: print " return self.corbaObject.%s(%s)" % (methodName, corbaParms) def comparm2corbaparm(corbaParm): """ Given a corba parameter, returns the appropriate Python parameter. """ result = "" type = corbaParm.paramType() if type.kind() == idltype.tk_string: result = "str(%s)" % corbaParm.identifier() elif type.kind() == idltype.tk_objref: result = "unwrap(%s).corbaObject" % corbaParm.identifier() else: result = corbaParm.identifier() return result def run(tree, args): visitor = ComVisitor() print "#----------------------------------------------------------" print "# Generated by gencombind.py " print "#----------------------------------------------------------" print """ import sys from win32com.server.util import wrap, Collection # NOTE: we override unwrap below from win32com.server.exception import COMException from win32com.server import util from com2corba import * import traceback import CosNaming from omniORB import CORBA """ tree.accept(visitor) print "\nnarrowLookups = {" for (key, wrapClass) in narrowLookups.items(): print " '%s': %s," % (key, wrapClass) print "}" print "\nif __name__ == '__main__':" print " import win32com.server.register" for name in declaredClasses: print " win32com.server.register.UseCommandLine(%s)" % name #---- end of package com2corba.py: --- cut here --- #---------------------------------------------------------------- # # com2corba support methods and classes (package) # # Copyright (c) 2000, 2001 DataChannel, Inc. # # This software may be used for any purpose without restriction as long as the above # copyright notice is maintained. # # $Id: com2corba.py,v 1.1 2001/01/03 20:15:45 eliot Exp $ ## #---------------------------------------------------------------- from win32com.server.util import wrap, Collection # NOTE: we override unwrap below from win32com.server.exception import COMException from win32com.server import util from omniORB import CORBA import sys, string class InitializeCorbaReferenceError(COMException): pass class CorbaWrapper: def __init__(self, corbaObject = None): self.corbaObject = corbaObject def initializeCorbaReference(self, corbaloc): """ Given a corba location, gets a CORBA object reference to it if it doesn't already have one. """ corbaloc = str(corbaloc) if not self.corbaObject: orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) try: self.corbaObject = orb.string_to_object(corbaloc) except Exception, exc: raise InitializeCorbaReferenceError("Failed to get CORBA" "object reference for location %s: %s" %\ (corbaloc, exc)) self.corbaObject = self.corbaObject._narrow(self.corbaStubClass) def ClassName(self): return self.__class__.__name__ def narrow(self, stubClassName): """ Implements the CORBA narrow method. stubClassName is the class name generated in the Python stubs from the IDL, i.e., 'module.module.interface' """ try: wrapClass = self.lookupWrapClassForStubClass(str(stubClassName)) cObj = self.corbaObject._narrow(wrapClass.corbaStubClass) if cObj: return wrap(wrapClass(cObj)) else: return None except KeyError: return None def lookupWrapClassForStubClass(self, stubClassName): """ Given the name of a python stub class (e.g., full-qualified name from IDL), return the corresponding COM wrapping class. Raises KeyError if stubClassName not found. """ raise Exception("This is an abstract method. " "Must be implemented by subclasses") def unwrap(comObj): "Handle Nothing objects passed in from COM" if comObj == None: return NullCorbaObj() else: pyObj = util.unwrap(comObj) return pyObj class NullCorbaObj: "Provides a None object that has a corbaObject property" def __init__(self): self.corbaObject = None #---- end of package -- . . . . . . . . . . . . . . . . . . . . . . . . W. Eliot Kimber | Lead Brain 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.656.4139 | F 512.419.1860 | eliot@isogen.com w w w . d a t a c h a n n e l . c o m From trohed@yahoo.com Thu Jan 4 20:03:34 2001 From: trohed@yahoo.com (trohed) Date: Thu, 4 Jan 2001 12:03:34 -0800 (PST) Subject: [omniORB] omniORB3 on Compaq Tru64 UNIX V5.0A Message-ID: <20010104200334.22053.qmail@web10302.mail.yahoo.com> Has anyone ever used omniORB3 on Tru64 V5.0A? Thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From Boris Khanales Thu Jan 4 22:34:00 2001 From: Boris Khanales (Boris Khanales) Date: Thu, 4 Jan 2001 17:34:00 -0500 (EST) Subject: [omniORB] JDK Orb Message-ID: <200101042234.RAA07991@desmond.imagine_ny.com> Sorry for unrelated question, but anybody knows anything about time-out support for CORBA calls in SUN's JDK or maybe other Java ORBs? By the way, there was something for omni to set time-out, can somebody point me where was it? Thank You. From tran15@rohan.sdsu.edu Fri Jan 5 02:03:02 2001 From: tran15@rohan.sdsu.edu (Malcom X.) Date: Thu, 4 Jan 2001 18:03:02 -0800 (PST) Subject: [omniORB] OmniORB CFG Message-ID: Hi, does anyone have a sample OmniORB.CFG file I can look at or have any idea of what should be in this CFG file? What directory should this CFG file resides? Any special environment setting for naming service. I'm running Win2000 and OmniORB 3.0. I'm totally new to OmniORB naming service and had trouble getting eg3_impl and eg3_clt to talk. Thanks in advance. From nansan@etang.com Fri Jan 5 09:10:39 2001 From: nansan@etang.com (nansan) Date: Fri, 5 Jan 2001 17:10:39 +0800 (CST) Subject: [omniORB] need a help Message-ID: <3A558F8F.24402@mail-smtp2> I have downloaded omniORB_302.tar.gz. My computer is linux redhat7.0 with gcc-2.96,python-1.5.2,and egcs 6.2-1.1.2. I have changed "platform=i586_linux_2.0_glibc2.1_gcc2.96"in config/mk.dir and "python=/usr/bin/python" in mk/platform/i586_linux_2.0_glibc2.1_gcc2.96.mk. then i make the file successfully. The problem is that the examples can not run properly.It is always saying "cat ch corba::systemexeption". Can you tell me why and how to make it run? Thanks for any help. ----------------------------------------- 100Ԫ��ã� http://ecard.etang.com/progt/index.asp?s1=1&s2=1 From davidh@cavendish.co.uk Fri Jan 5 11:28:11 2001 From: davidh@cavendish.co.uk (David Hyde) Date: Fri, 5 Jan 2001 11:28:11 -0000 Subject: [omniORB] OmniORB In A Loop Message-ID: <31C9EC5EF9CAD111981300805F06666028B20D@phantom.cavendish.co.uk> Occassional I am getting into the situation that my when my client makes a call into a server it hangs. I've found that that it is looping around in a call to tcpSocketStrand::ll_recv(void* buf, size_t sz) in tcpSocketMTfactory.cc and the call that it makes to rx = select(pd_socket+1,&fds,0,&efds,&t) takes about 5 seconds. I've a feeling that this might be happening as a result of a fault in the server, but I don't know what. I can make seperate connections to the server whilst this is happening, so I know that it is generally ok. Does anyone have any pointers? Thanks David Hyde From steffann@nederland.net Fri Jan 5 12:48:50 2001 From: steffann@nederland.net (Sander Steffann) Date: Fri, 5 Jan 2001 13:48:50 +0100 Subject: [omniORB] Calling syslog from programs linking to libomniORB3.so (on Linux) Message-ID: <003c01c07715$da2af200$7101a8c0@OFFICE> Hello, I am trying to use syslog from a program that links to libomniORB3.so, but as soon as I link a program with omniORB, the calls to syslog don't work anymore, and the messages are displayed on stdout or stderr (I don't know for sure which one) instead of going to syslog. I tried this with a small program that only calls syslog() and then exits. When not linked with omniORB3, it works as expected, but when linked with omniORB3 it doesn't. Anybody any idea what can cause this (and how to solve it)? Sander. From vonWedel@lfpt.rwth-aachen.de Fri Jan 5 14:27:17 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Fri, 5 Jan 2001 15:27:17 +0100 Subject: [omniORB] Compiling omniORB with Python 2.0 Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00509971C12569CB_= Content-Type: text/plain; charset="us-ascii" Hello, we have upgraded from Python 1.5.2 to Python 2.0 and now I want to upgrade omniORB as well. I checked out the sources from the development branches for omniORB and omniORBpy this morning. Compiling starts with the following warnings which look somewhat strange to me: ../../../../bin/sun4_sosV_5.7/omkdepend -D__SUNPRO_CC -D__cplusplus -DOMNIPY_MAJOR=0 -DOMNIPY_MINOR=5 -DOMNIORB_VERSION_STRING="3.0.2" -DOMNIORBPY_FOR_30 -I../../../../src/lib/omniORB2 -I../../../../src/lib/omniORB2/orbcore -I/usr/local/include -DPYTHON_INCLUDE= -DPYTHON_THREAD_INC= -I. -I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 common/pyomniFunc.cc common/pyThreadCache.cc common/pyTypeCode.cc common/pyMarshal.cc common/pyExceptions.cc omni30/pyServant.cc omni30/pyCallDescriptor.cc omni30/pyObjectRef.cc omni30/pyPOAManagerFunc.cc omni30/pyPOAFunc.cc omni30/pyORBFunc.cc omni30/omnipy.cc ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/Python.h: 44: # error "Python.h requires that stdio.h define NULL." ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/pyport.h: 390: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)." ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyMarshal.cc) common/pyMarshal.cc: 255: # error "omniidl requires Python 1.5.2 or higher" making export in src/lib/omniORBpy/modules/omni30... Are these actually omniORB problems? They look like a Python-related problem, to some extent... Anyone seen this before? Lars --=_alternative 00509971C12569CB_= Content-Type: text/html; charset="us-ascii"
Hello,

we have upgraded from Python 1.5.2 to Python 2.0 and now I want to upgrade omniORB as well.
I checked out the sources from the development branches for omniORB and omniORBpy this morning.
Compiling starts with the following warnings which look somewhat strange to me:

../../../../bin/sun4_sosV_5.7/omkdepend -D__SUNPRO_CC -D__cplusplus -DOMNIPY_MAJOR=0 -DOMNIPY_MINOR=5 -DOMNIORB_VERSION_STRING="3.0.2" -DOMNIORBPY_FOR_30 -I../../../../src/lib/omniORB2 -I../../../../src/lib/omniORB2/orbcore -I/usr/local/include -DPYTHON_INCLUDE=<python2.0/Python.h> -DPYTHON_THREAD_INC=<python2.0/pythread.h> -I. -I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 common/pyomniFunc.cc common/pyThreadCache.cc common/pyTypeCode.cc common/pyMarshal.cc common/pyExceptions.cc omni30/pyServant.cc omni30/pyCallDescriptor.cc omni30/pyObjectRef.cc omni30/pyPOAManagerFunc.cc omni30/pyPOAFunc.cc omni30/pyORBFunc.cc omni30/omnipy.cc
../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/Python.h: 44: # error "Python.h requires that stdio.h define NULL."
../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/pyport.h: 390: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyMarshal.cc) common/pyMarshal.cc: 255: # error "omniidl requires Python 1.5.2 or higher"
making export in src/lib/omniORBpy/modules/omni30...

Are these actually omniORB problems? They look like a Python-related problem, to some extent...
Anyone seen this before?

Lars
--=_alternative 00509971C12569CB_=-- From harri.pasanen@trema.com Fri Jan 5 14:38:42 2001 From: harri.pasanen@trema.com (Harri Pasanen) Date: Fri, 05 Jan 2001 15:38:42 +0100 Subject: [omniORB] Compiling omniORB with Python 2.0 References: Message-ID: <3A55DC72.7BD58FB8@trema.com> Those are just omkdepend warnings, you can ignore those. -Harri vonWedel@lfpt.rwth-aachen.de wrote: > > Hello, > > we have upgraded from Python 1.5.2 to Python 2.0 and now I want to > upgrade omniORB as well. > I checked out the sources from the development branches for omniORB > and omniORBpy this morning. > Compiling starts with the following warnings which look somewhat > strange to me: > > ../../../../bin/sun4_sosV_5.7/omkdepend -D__SUNPRO_CC -D__cplusplus > -DOMNIPY_MAJOR=0 -DOMNIPY_MINOR=5 -DOMNIORB_VERSION_STRING="3.0.2" > -DOMNIORBPY_FOR_30 -I../../../../src/lib/omniORB2 > -I../../../../src/lib/omniORB2/orbcore -I/usr/local/include > -DPYTHON_INCLUDE= > -DPYTHON_THREAD_INC= -I. -I../../../../include > -D__sparc__ -D__sunos__ -D__OSVERSION__=5 common/pyomniFunc.cc > common/pyThreadCache.cc common/pyTypeCode.cc common/pyMarshal.cc > common/pyExceptions.cc omni30/pyServant.cc omni30/pyCallDescriptor.cc > omni30/pyObjectRef.cc omni30/pyPOAManagerFunc.cc omni30/pyPOAFunc.cc > omni30/pyORBFunc.cc omni30/omnipy.cc > ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from > common/pyomniFunc.cc) /usr/local/include/python2.0/Python.h: 44: # > error "Python.h requires that stdio.h define NULL." > ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from > common/pyomniFunc.cc) /usr/local/include/python2.0/pyport.h: 390: > #error "LONG_BIT definition appears wrong for platform (bad gcc > config?)." > ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from > common/pyMarshal.cc) common/pyMarshal.cc: 255: # error "omniidl > requires Python 1.5.2 or higher" > making export in src/lib/omniORBpy/modules/omni30... > > Are these actually omniORB problems? They look like a Python-related > problem, to some extent... > Anyone seen this before? > > Lars From davidh@cavendish.co.uk Fri Jan 5 14:46:10 2001 From: davidh@cavendish.co.uk (David Hyde) Date: Fri, 5 Jan 2001 14:46:10 -0000 Subject: [omniORB] Object::_nil() Message-ID: <31C9EC5EF9CAD111981300805F06666028B20F@phantom.cavendish.co.uk> I am using OmniORB on winnt to build a COM control. From what I have read (Henning and Vinoski) calling _nil() on an object is guaranteed not to leak any resources even if CORBA::release() is not called using the returned reference. I am calling CORBA::release() on it, but Visual C++ is still reporting a memory leak when the application shuts down. Does anyone know why? Thanks David Hyde From jonas.reimers@se.adtranz.com Fri Jan 5 15:02:13 2001 From: jonas.reimers@se.adtranz.com (Jonas Reimers) Date: Fri, 5 Jan 2001 16:02:13 +0100 Subject: [omniORB] Error compiling with Omniidl Message-ID: <412569CB.00529CF7.00@demalng2.goc.adtranz.com> - OS: WIN NT 4.0 SP6 When running omniidl -bcxx test.idl I receive following error. omniidl: ERROR! omniidl: Could not open Python files for IDL compiler omniidl: Please put them in directory M:\CORBA\omniORB\src\tool\omniidl\cxx omniidl: (or set the PYTHONPATH environment variable) Traceback (innermost last): File "", line 26, in ? NameError: msg Running the PATH comman gives the following: PATH=c:\dmi\win32\bin;C:\WINNT\system32;C:\WINNT;C:\Program Files\Visio;C:\Progr am Files\Microsoft Office\Office;C:\Acrobat3\Reader;C:\Program Files\Adobe\Acrob at 4.0\Reader;C:\ccm45\bin;;C:\MSSQL\BINN;C:\Program Files\IONA\bin;C:\Program F iles\IONA\bin;C:\Program Files\IONA\bin;c:\program files\devstudio\sharedide\bin \ide;c:\program files\devstudio\sharedide\bin;c:\program files\devstudio\vc\bin; M:\CORBA\omniORB\bin\x86_win32;M:\Corba\omniORB\gnuwin\bin; I have searched in your database and found a similar error but In the answer it is said that it is a bug that is take care off? I typed the solution suggested in the answer and sets the libpath to: M:\CORBA\omniORB\lib\x86_win32\ but still gets the error message. Anny ideas? Your sincearly Jonas Reimers From trohed@yahoo.com Fri Jan 5 22:25:35 2001 From: trohed@yahoo.com (trohed) Date: Fri, 5 Jan 2001 14:25:35 -0800 (PST) Subject: [omniORB] example factory Message-ID: <20010105222535.27396.qmail@web10303.mail.yahoo.com> Does anyone have an example of a factory that I could look at? Thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From tran15@rohan.sdsu.edu Sat Jan 6 01:27:16 2001 From: tran15@rohan.sdsu.edu (Malcom X.) Date: Fri, 5 Jan 2001 17:27:16 -0800 (PST) Subject: [omniORB] How does omniNames find omniORB.cfg Message-ID: Hi, does anyone now how to setup the environment so that omniNames will read the omniORB.cfg when it starts. I'm running Win2000 and I tried the following: - set the PATH to the dir containing omniORB.cfg which is in c:\omni\etc - omniORB.cfg contains -ORBInitialHost localhost -ORBInitialPort 2809 - successfully started omniNames - tried to start eg3_impl from the command line c:\...\echo\eg3_impl but get an exception of SystemException When I started omniNames, then started eg3_impl with arguments: c:\...\echo\eg3_impl -ORBInitialHost localhost -ORBInitialPort 2809 everything worked fine. This showed that omniNames does not read omniORB.cfg. Any help is appreciated. Thanks From djr@uk.research.att.com Sat Jan 6 15:44:31 2001 From: djr@uk.research.att.com (David Riddoch) Date: Sat, 6 Jan 2001 15:44:31 +0000 (GMT) Subject: [omniORB] Object::_nil() In-Reply-To: <31C9EC5EF9CAD111981300805F06666028B20F@phantom.cavendish.co.uk> Message-ID: Hi, It is actually impossible to implement nil object references in a way that does not leak any memory at all. omniORB does technically 'leak memory' in this case, in the sense that it allocates an object that it never deletes. However this is a singleton -- it does not leak more and more memory as time goes on. The reason for this is that we have to guarentee that the nil object reference will be around at least as long as any _var instances that reference it. The _var objects might be static objects, in which case we can make no assumptions about when they will be destroyed. Thus the nil singleton has to be dynamically allocated, and we cannot ever delete it. Cheers, David On Fri, 5 Jan 2001, David Hyde wrote: > I am using OmniORB on winnt to build a COM control. From what I have read > (Henning and Vinoski) calling _nil() on an object is guaranteed not to leak > any resources even if CORBA::release() is not called using the returned > reference. I am calling CORBA::release() on it, but Visual C++ is still > reporting a memory leak when the application shuts down. > > Does anyone know why? From rocky1_2@rediffmail.com Fri Jan 5 17:54:50 2001 From: rocky1_2@rediffmail.com (Rocky) Date: Fri, 5 Jan 2001 23:24:50 +0530 Subject: [omniORB] Error compiling with Omniidl References: <412569CB.00529CF7.00@demalng2.goc.adtranz.com> Message-ID: <002d01c07740$9a6fbbc0$aa51c7cb@k.nayar> hi, think u missed a point in the readme.first file might be useful.. i am using the same system as u are and the following has worked for me: omniidl requires Python 1.5.2. You can download the full Python distribution from http://www.python.org/download/download_windows.html or ftp://ftp.uk.research.att.com/pub/omniORB/python/py152.exe Alternatively, for Windows on x86, you can install a minimal version of Python which contains just the functionality required by omniidl. The Win32 binary distribution of omniORB comes with this minimal python package. Download it from ftp://ftp.uk.research.att.com/pub/omniORB/python/omnipython-x86_win32.zip Unpack the zip file at the top of the omniORB tree. It places files in the bin, lib and include directories. ----- Original Message ----- From: Jonas Reimers To: Sent: Friday, January 05, 2001 8:32 PM Subject: [omniORB] Error compiling with Omniidl > - > OS: WIN NT 4.0 SP6 > > When running omniidl -bcxx test.idl I receive following error. > > omniidl: ERROR! > > omniidl: Could not open Python files for IDL compiler > omniidl: Please put them in directory M:\CORBA\omniORB\src\tool\omniidl\cxx > omniidl: (or set the PYTHONPATH environment variable) > > Traceback (innermost last): > File "", line 26, in ? > NameError: msg > > > Running the PATH comman gives the following: > > PATH=c:\dmi\win32\bin;C:\WINNT\system32;C:\WINNT;C:\Program Files\Visio;C:\Progr > am Files\Microsoft Office\Office;C:\Acrobat3\Reader;C:\Program Files\Adobe\Acrob > at 4.0\Reader;C:\ccm45\bin;;C:\MSSQL\BINN;C:\Program Files\IONA\bin;C:\Program F > iles\IONA\bin;C:\Program Files\IONA\bin;c:\program files\devstudio\sharedide\bin > \ide;c:\program files\devstudio\sharedide\bin;c:\program files\devstudio\vc\bin; > M:\CORBA\omniORB\bin\x86_win32;M:\Corba\omniORB\gnuwin\bin; > > > I have searched in your database and found a similar error but In the answer it > is said that it is a bug that is take care off? > I typed the solution suggested in the answer and sets the libpath to: > > M:\CORBA\omniORB\lib\x86_win32\ > > but still gets the error message. > > Anny ideas? > > > Your sincearly > Jonas Reimers > > > > From rocky1_2@rediffmail.com Fri Jan 5 17:47:11 2001 From: rocky1_2@rediffmail.com (Rocky) Date: Fri, 5 Jan 2001 23:17:11 +0530 Subject: [omniORB] OmniORB CFG References: Message-ID: <002201c0773f$886a80a0$aa51c7cb@k.nayar> hi, you don't really need to use an omniorb.cfg file for configuring the naming service. You can make the appropriate settings in the windows registry according to the instructions in the readme.first file. It would also be better if you could spell out the exact nature of the problem you are facing in running the examples.. ----- Original Message ----- From: Malcom X. To: Sent: Friday, January 05, 2001 7:33 AM Subject: [omniORB] OmniORB CFG > Hi, does anyone have a sample OmniORB.CFG file I can look at or have any > idea of what should be in this CFG file? > > What directory should this CFG file resides? Any special environment > setting for naming service. I'm running Win2000 and OmniORB 3.0. > > I'm totally > new to OmniORB naming service and had trouble getting eg3_impl and eg3_clt > to talk. > > Thanks in advance. > > > From chalky@null.net Sun Jan 7 02:18:20 2001 From: chalky@null.net (Stephen Davies) Date: Sun, 7 Jan 2001 13:18:20 +1100 (EST) Subject: [omniORB] Synopsis 0.2 Released Message-ID: Synopsis is a source code documentation tool that follows a modular architecture to adapt to different languages, comment styles and output formats. Currently it supports IDL and C++ languages and HTML output. It has the ability to scale to large projects, integrating well with Makefiles to only update documentation for changed files. One of the goals of Synopsis is to integrate the documentation between different languages, for example linking implementations in any language with their CORBA interfaces and vice versa. It is written in Python except for the C++ parser, which is a module written in C++ based on OpenC++. The IDL parser uses the omniidl tool from omniORB which is also written in Python. Support for a Python parser is planned for the next release. Changes: Release 0.2 adds C++ support and a rewritten HTML formatter. It is complete enough to be in use by the Berlin Project. Homepage: http://synopsis.sourceforge.net/ Download: http://sourceforge.net/projects/synopsis/ From gnana@mips.biochem.mpg.de Mon Jan 8 10:45:30 2001 From: gnana@mips.biochem.mpg.de (Gnana) Date: Mon, 8 Jan 2001 11:45:30 +0100 Subject: [omniORB] Synopsis 0.2 Released In-Reply-To: ; from chalky@null.net on Sun, Jan 07, 2001 at 01:18:20PM +1100 References: Message-ID: <20010108114530.A29231@mips.biochem.mpg.de> Hello, I used Synopsis 0.2 for my CORBA IDL documentation and I was impressed. I would like to know if there is a possibility of parsing an IDL file and writing out a interface and operation diagram (in UML?) so that it is easy to visualise at the whole IDL file. I use Dia to do this right now (manually though!). I am looking for opensource tool and not tools from Rational or Togethersoft. -gnana Quoting Stephen Davies : > > Synopsis is a source code documentation tool that follows a modular > architecture to adapt to different languages, comment styles and output > formats. Currently it supports IDL and C++ languages and HTML output. It > has the ability to scale to large projects, integrating well with > Makefiles to only update documentation for changed files. One of the goals > of Synopsis is to integrate the documentation between different languages, > for example linking implementations in any language with their CORBA > interfaces and vice versa. > > It is written in Python except for the C++ parser, which is a module > written in C++ based on OpenC++. The IDL parser uses the omniidl tool from > omniORB which is also written in Python. Support for a Python parser is > planned for the next release. > > Changes: > Release 0.2 adds C++ support and a rewritten HTML formatter. It is > complete enough to be in use by the Berlin Project. > > Homepage: > http://synopsis.sourceforge.net/ > > Download: > http://sourceforge.net/projects/synopsis/ > > > > > From gnana@mips.biochem.mpg.de Mon Jan 8 11:16:55 2001 From: gnana@mips.biochem.mpg.de (Gnana) Date: Mon, 8 Jan 2001 12:16:55 +0100 Subject: [omniORB] Synopsis 0.2 Released In-Reply-To: ; from chalky@null.net on Mon, Jan 08, 2001 at 10:11:52PM +1100 References: <20010108114530.A29231@mips.biochem.mpg.de> Message-ID: <20010108121655.B31166@mips.biochem.mpg.de> Hi Chalky, Quoting Stephen Davies : > > However, if you want this done then I can have a look into it. Dia's file > format is XML which is easy to generate. The only problem would be > positioning the diagram elements. An easy solution would be to leave this > to the user to open up Dia and rearrange anything, or it's possible that > interfaces and operations as needed. As a feature add, you could implement the 'easy' solution and later on as time permits, you can do the positioning of the Dia objects and also generate code for interface and operation from the Dia diagram. I saw a tool that can take a Dia XML file and output code, but I guess that tool was generating C++ code from the Dia UML diagram (data in XML). I don't know how many people out there need this feature. Definetely, I think this feature is a very good one to spend time on. I understand a lot of thinking has to go in especially in the positioning of the objects in Dia. Your tool came just in time when I was searching for a tool that can document our huge CORBA IDL files. Thanks. -gnana From kissa@iqsoft.hu Mon Jan 8 13:47:38 2001 From: kissa@iqsoft.hu (=?iso-8859-2?Q?Kiss_=C1rp=E1d?=) Date: Mon, 8 Jan 2001 14:47:38 +0100 Subject: [omniORB] Re: A Stab at Python COM-to-CORBA Binding Generatio n Message-ID: <4A93A58449F5D311ADF500508B8B74568B6987@exchange.iqsoft.hu> Hi, I have a little bit different solution for COM-to-Corba bindig. I wrote a simple COM class that wraps Corba interfaces dynamically. I don't use it in real applications, I just want to test it is possible this way or not... Recently I have made some modification on the source, so it works with Python 2.0 too. You can download it from here: http://starship.python.net/crew/arpadk/downloads/COMToCorba0.6.0.zip Cheers, Arpad Kiss From chalky@null.net Mon Jan 8 11:11:52 2001 From: chalky@null.net (Stephen Davies) Date: Mon, 8 Jan 2001 22:11:52 +1100 (EST) Subject: [omniORB] Synopsis 0.2 Released In-Reply-To: <20010108114530.A29231@mips.biochem.mpg.de> Message-ID: Hi Gnana, Synopsis' modular architecture will certainly allow a 'Formatter' that outputs some kind of UML diagram instead of web pages. In fact, we were sort of planning to do this in the future, but I don't think there are any immediate plans. However, if you want this done then I can have a look into it. Dia's file format is XML which is easy to generate. The only problem would be positioning the diagram elements. An easy solution would be to leave this to the user to open up Dia and rearrange anything, or it's possible that the formatter could parse an existing dia file and just update the interfaces and operations as needed. Tell me what you think. Chalky //--------=[ Chalky (Stephen Davies) -- Chalky@null.net ]=--------\\ //-------=[ Powered by Linux -- "Escape the Gates of Hell" ]=-------\\ //--=[ Programmer(C/C++/Java) and 4th Year CSE/CS Student at RMIT ]=--\\ From uche.ogbuji@fourthought.com Mon Jan 8 14:52:55 2001 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 08 Jan 2001 07:52:55 -0700 Subject: [omniORB] A Stab at Python COM-to-CORBA Binding Generation In-Reply-To: Message from "W. Eliot Kimber" of "Fri, 29 Dec 2000 16:46:58 CST." <3A4D1462.5A1DD54A@isogen.com> Message-ID: <200101081452.HAA10235@localhost.localdomain> > Having tried to find a free (or even evaluatable) CORBA-to-COM bridge > and failed, I did some experimentation and realized that writing a COM > wrapper in Python for CORBA objects was pretty easy with OmniORB and > omniidl (scarily easy, actually). The only complication I've found so > far is that our "top-level" class cannot be auto-generated, as it is the > one class that establishes the initial CORBA connection (or at least, I > haven't thought about the problem long enough to figure out how to > generate this class). This is an amazing co-oincidence, I think. I just happened to be working on an XPCOM (Mozilla's COM variation) to CORBA bridge, primarily as a way to bootstrap Mozilla as a console for 4Suite Server. I was using some Python for manipulating the IDLs and all that, but not as a wrapper because XPCOM right now only seems to connect to Javascript or C++ (please someone correct me if I'm wrong). Anyway, even more important than that I ran into this Mozilla bug. http://bugzilla.mozilla.org/show_bug.cgi?id=62196 Which makes it quite difficult to test what I've worked on so far, or to get any further. Or maybe I'm missing something: I've done a lot of work with CORBA but I'm a COM newbie and also a newbie to the Mozilla code-base. If anyone is interested in my work, i.e. if you're interested in developing a console for your CORBA servers using basic Mozilla JavaScript, please help me out by voting for this bug on Mozilla.org. The XPCOM/CORBA bridge will be open source (Apache license) when I get it working. I'll have a look at Eliot's code for possible sharing of ideas, even though he's tackling a somewhat different area with Windows COM (you lucky dog, you get Python/COM out of the box). Thanks all. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From cmeerw@web.de Mon Jan 8 15:27:19 2001 From: cmeerw@web.de (Christof Meerwald) Date: Mon, 8 Jan 2001 16:27:19 +0100 Subject: [omniORB] A Stab at Python COM-to-CORBA Binding Generation In-Reply-To: <200101081452.HAA10235@localhost.localdomain> References: <200101081452.HAA10235@localhost.localdomain> Message-ID: <20010108162719.A809@hacking.meerwald.priv.at> On Mon, 08 Jan 2001 07:52:55 -0700, uche.ogbuji@fourthought.com wrote: >bootstrap Mozilla as a console for 4Suite Server. I was using some Python for >manipulating the IDLs and all that, but not as a wrapper because XPCOM right >now only seems to connect to Javascript or C++ (please someone correct me if >I'm wrong). Take a look at the Blackwood project (http://www.mozilla.org/projects/blackwood) for a Java-XPCOM bridge. And the Komodo beta (http://www.activestate.com) includes a Python-XPCOM bridge (at least on Windows NT, haven't tried the Linux version yet) bye, Christof -- http://cmeerw.cjb.net http://cmeerw.cjb.net/wap/ mailto cmeerw at web.de AIM, Yahoo! Messenger: cmeerw From yan_gao@hp.com Tue Jan 9 06:36:14 2001 From: yan_gao@hp.com (GAO,YAN (HP-Singapore,ex3)) Date: Tue, 9 Jan 2001 14:36:14 +0800 Subject: [omniORB] POA over BOA Message-ID: <912404552D6CD411B57700D0B77532260173DD10@xsg03.sgp.hp.com> Hi, Anybody can tell me a little specifically of the advantage the POA over BOA? Regards, Gao Yan From prapier@coactive.com Tue Jan 9 19:14:06 2001 From: prapier@coactive.com (Peter Rapier) Date: Tue, 9 Jan 2001 11:14:06 -0800 Subject: [omniORB] POA/BOA IOR compatibility Message-ID: <7118259C3044D311942700508B2CA5BB4F256D@balance.coactive.com> We are hearing that clients created with POA based ORB's are having problems understanding a persistent IOR we create on our omniORB 2.6 - based server. It is my understanding that clients should be able to talk to our BOA based orb regardless of their ORB's object adapter and that IOR's have a specified format. Why would there be a problem with one ORB parsing or otherwise understanding anothers ORB's IOR? Any info that can be shared with me on this topic would be greatly appreciated. - Peter Rapier From chris.newbold@laurelnetworks.com Tue Jan 9 23:46:42 2001 From: chris.newbold@laurelnetworks.com (Chris Newbold) Date: Tue, 09 Jan 2001 18:46:42 -0500 Subject: [omniORB] Default for omniORB::diiThrowsSysExceptions is wrong References: <3A549470.7000909@laurelnetworks.com> Message-ID: <3A5BA2E2.1030403@laurelnetworks.com> It appears that the default value for omniORB::diiThrowsSysExceptions is wrong, or at least in disagreement with the documentation in the 3.0.2 release. The documentation claims that, starting with 2.8.0, the default is TRUE. The actual value seems to be FALSE, as found in the static initialization in omniORB.cc -Chris Newbold Laurel Networks, Inc. From john@drystone.co.uk" Hi Hany I believe there are problems with Apache and pthreads. Try a single threaded orb for your module (mico definately works and orbit looks like it ought to). Cheers John On Thursday, January 04, 2001 12:29 PM, Hany Greiss [SMTP:hany@peac.com] wrote: > > > Hello again, > > Just to follow up on my previous e-mail regarding hanging on the call > to ORB_init from within an Apache module. I came across a suggestion to > insert tracing within the argc/argv parameters. When I did this the only > > output I received was, > > omniORB: strand Ripper: start. > > It appears to hang at this point. Any ideas? > > Thanks, > > Hany > hany@portalsphere.com > > > From S.Lo@uk.research.att.com Wed Jan 10 11:53:49 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 10 Jan 2001 11:53:49 +0000 Subject: [omniORB] omni and Apache In-Reply-To: <01C07AF8.120D1820.john@drystone.co.uk> References: <01C07AF8.120D1820.john@drystone.co.uk> Message-ID: <3ozogzk4he.fsf@neem.uk.research.att.com> It looks like my reply to Hany has not been CC to the list. So here it goes again: In one of our projects we have an apache module written to use omniORB. The important point is when to call ORB_init. In our apache module, the module dispatch structure looks like this: static int initialised = 0; // Spirit request content handler. static int spirit_handler(request_rec *r) { .... if (!initialised) { initialised = 1; int argc = 0; char** argv = NULL; CORBA::ORB_init(argc,argv,"omniORB3"); } .... } // Here is the list of content handlers for the module. static const handler_rec spirit_handlers[] = { {"spirit-handler", spirit_handler}, {NULL} }; // We have no command directives for this module. static const command_rec spirit_cmds[] = { {NULL} }; // And here is the list of callback routines. module spirit_module = { STANDARD_MODULE_STUFF, NULL, // Initializer. NULL, // Per-directory config. NULL, // Directory config merger. NULL, // Server config. NULL, // Server config merger. spirit_cmds, // Command table. spirit_handlers, // Handler list. NULL, // Filename-to-URI translation. NULL, // Validate userid. NULL, // Validate userid for this URI. NULL, // Host address access. NULL, // Check mime types. NULL, // Any last minute fixes. NULL, // Log. #if MODULE_MAGIC_NUMBER >= 19970103 NULL, // Header parser. #if MODULE_MAGIC_NUMBER >= 19970719 NULL, // Process initializer. #if MODULE_MAGIC_NUMBER >= 19970728 NULL, // Process cleanup. #if MODULE_MAGIC_NUMBER >= 19970902 NULL // Immediate handler. #endif #endif #endif #endif }; Notice that ORB_init is called in the handler itself. That means it will be called by the worker process that actually serve the http request. After ORB_init is called, the ORB will spawn a few internal threads. If the process call fork() soon afterwards, things will almost certainly not work. By putting ORB_init in the handler, it is certain that the process calling it will not be forking another process to do the work. Regards, Sai-Lai >>>>> John Hedges writes: > Hi Hany > I believe there are problems with Apache and pthreads. > Try a single threaded orb for your module (mico definately works and orbit looks like it ought to). > Cheers > John > On Thursday, January 04, 2001 12:29 PM, Hany Greiss [SMTP:hany@peac.com] wrote: >> >> >> Hello again, >> >> Just to follow up on my previous e-mail regarding hanging on the call >> to ORB_init from within an Apache module. I came across a suggestion to >> insert tracing within the argc/argv parameters. When I did this the only >> >> output I received was, >> >> omniORB: strand Ripper: start. >> >> It appears to hang at this point. Any ideas? >> >> Thanks, >> >> Hany >> hany@portalsphere.com >> >> >> -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From rds@apama.com Wed Jan 10 12:44:40 2001 From: rds@apama.com (Robert Smith) Date: Wed, 10 Jan 2001 12:44:40 -0000 Subject: [omniORB] omniNames and Java In-Reply-To: <3ozogzk4he.fsf@neem.uk.research.att.com> Message-ID: Our company would like to use omniNames as a nameserver for the ORB that comes with jdk1.3. (tnameserv does not persist names to disk so is no good for our purposes). When omniNames 3.0.2 is used the resolve_initial_references method in Java fails with an ArrayIndexOutOfBoundsException. This is due to a well known bug in the jdk1.3 ORB. However, omniNames 2.8.0 works fine with jdk 1.3. Why is this - how does omniNames 3.02 differ from 2.80? Is it perhaps due to the INS support in 3.02? Does the bug only affect the nameservice or can it cause problems if talking to other C++ code which uses omniORB? thanks for your help, Rob From dgrisby@uk.research.att.com Wed Jan 10 14:57:01 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 14:57:01 +0000 Subject: [omniORB] omniNames and Java In-Reply-To: Message from "Robert Smith" of "Wed, 10 Jan 2001 12:44:40 GMT." Message-ID: <200101101457.OAA28264@pineapple.uk.research.att.com> On Wednesday 10 January, "Robert Smith" wrote: > When omniNames 3.0.2 is used the resolve_initial_references method in Java > fails with an ArrayIndexOutOfBoundsException. This is due to a well known > bug in the jdk1.3 ORB. However, omniNames 2.8.0 works fine with jdk 1.3. > > Why is this - how does omniNames 3.02 differ from 2.80? Is it perhaps due to > the INS support in 3.02? Does the bug only affect the nameservice or can it > cause problems if talking to other C++ code which uses omniORB? The problem is with the object key, which is used to identify an object within an address space. omniORB 2.x always uses object keys which are 12 bytes in length. The JDK ORB is happy with that. omniORB 3's object keys vary in length depending on the name and policies of the POA in use. It seems to be the case that the JDK ORB has a bug for object keys shorter than 12 bytes, but only if the object is on the same host as the client. Unfortunately, the INS requires that the root context of the naming service has the object key "NameService", which is only 11 bytes. Not only that, but sub-contexts of the root context have objects keys of only 6 bytes. In C++ code that you write, you just need to make sure that the object keys for all your objects are longer than 12 bytes. omniORB generates the object key as follows: ( POA name )* [ nonce ] object id. Each tag is a single byte. The list of POA names represents the hierarchy of POAs. Transient POAs include an 8 byte nonce, used to keep the object keys unique for all time. System supplied object ids are always 4 bytes; user supplied ones can be any length. In the root POA, for example, the list of POA names is empty, so there is just nonce system id, which is 1 + 8 + 1 + 4 = 14 bytes, so that's OK. However, a persistent POA named "foo" using the system id policy would have "foo" system id = 1 + 3 + 1 + 4 = 9 bytes, which is too short for JavaIDL. If you need persistent POAs, make sure they have names of 10 characters or more, and you'll be OK. Please don't use this information to unpick omniORB's object keys. The details may well change in future. The Sun bug page for the problem is http://developer.java.sun.com/developer/bugParade/bugs/4351366.html Unfortunately, they have closed the issue, claiming that it is not a bug, despite the fact that it quite clearly is. Some of the comments add more details about why it fails. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Wed Jan 10 15:08:40 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 15:08:40 +0000 Subject: [omniORB] omniNames and Java In-Reply-To: Message from Duncan Grisby of "Wed, 10 Jan 2001 14:57:01 GMT." Message-ID: <200101101508.PAA28313@pineapple.uk.research.att.com> Following up my own post, I discovered some more interesting information. Bug number 4332373, which has actually been fixed, is the same problem, in a slightly different situation. It seems like the same buggy code is used in several (at least 3) different places. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From Richard.Turner@aculab.com Wed Jan 10 17:17:14 2001 From: Richard.Turner@aculab.com (Richard.Turner@aculab.com) Date: Wed, 10 Jan 2001 17:17:14 -0000 Subject: [omniORB] Problems building omniORB3 on SunOS 5.6 Message-ID: <0AEF0EB21F09D211AE4E0080C82733BFBFB333@mailhost.aculab.com> Hi This is my first time with omniORB so bear with me if this is obvious ... I'm running gcc 2.95.2 and GNU make 3.76.1 under SunOS 5.6 (Generic_105181-05 kernel). I've downloaded the 3.0.2 source code and the minimal python 1.5.2 material (omnipython-sun4_sosV_5_6_tar.gz) and made the right (well, hopefully right) changes to config/config.mk, mk/unix.mk and mk/platforms/sun4_sosV_5.6.mk. These now define platform as sun4_sosV_5.6, MKDIRHIER as mkdir -p, PYTHON as $(ABSTOP)/$(BINDIR)/omnipython and all the CXX... macros as necessary for using gcc/g++. I do a make export in the src directory. All appears to be well until I get to here ... ../../../../bin/sun4_sosV_5.6/omkdepend -D__cplusplus -D__GNUG__ -D__GNUC__ -DIDLMODULE_VERSION="0x2301" -I/usr/local/src/richard/omni/include -DPYTHON_INCLUDE= -I. -I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 idlc.cc idlpython.cc idlconfig.cc idldump.cc idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc idlutil.cc idlerr.cc lex.yy.cc y.t ab.cc ../../../../bin/sun4_sosV_5.6/omkdepend: warning: (from idlpython.cc) idlpython .cc: 302: # error "omniidl requires Python 1.5.2 or higher" This looks suspicious already as omnipython claims that it _is_ 1.5.2 ... $ ./omnipython Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import exceptions' failed; use -v for traceback Warning! Falling back to string-based exceptions 'import site' failed; use -v for traceback Python 1.5.2 (#3, Feb 17 2000, 12:43:07) [GCC 2.95 19990728 (release)] on sunos 5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> The build continues but eventally collapses at ... make[2]: Entering directory `/usr/local/src/richard/omni/src/lib/omniORB2' + mkdir -p omniORB3 ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 -ComniORB3 ../../../idl/Naming.idl Segmentation Fault make[2]: *** [omniORB3/Naming.hh] Error 139 make[2]: Leaving directory `/usr/local/src/richard/omni/src/lib/omniORB2' I've been through the FAQ and trawled the mailing list archive but I haven't had much luck in finding a cause or cure for this problem. I've since tried downloading the latest source snapshot (omniORB3-20010110_tar.gz) but this fails in exactly the same way. Help - can anyone enlighten me? Thanks, Richard Turner. richard.turner@aculab.com From Ben.Miller@Mercia.Com Wed Jan 10 17:24:15 2001 From: Ben.Miller@Mercia.Com (Ben Miller) Date: Wed, 10 Jan 2001 17:24:15 -0000 Subject: [omniORB] omniORB 3.0.x Message-ID: Hi all, Just a quick question: am I right in thinking that since this version of omniORB complies to the 2.3 CORBA spec, it supports pass by value semantics? Regards, Ben Miller Mercia Software Ltd. Mercia House Ashted Lock Aston Science Park Birmingham B7 4AZ, UK Registered Number: 1868855 (Cardiff) Tel: 44 (0)121 359 5096 Fax: 44 (0)121 359 0375 Web Site: http://www.mercia.com From dgrisby@uk.research.att.com Wed Jan 10 17:42:07 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 17:42:07 +0000 Subject: [omniORB] omniORB 3.0.x In-Reply-To: Message from Ben Miller of "Wed, 10 Jan 2001 17:24:15 GMT." Message-ID: <200101101742.RAA31010@pineapple.uk.research.att.com> On Wednesday 10 January, Ben Miller wrote: > Just a quick question: am I right in thinking that since this version > of omniORB complies to the 2.3 CORBA spec, it supports pass by value > semantics? I assume you mean valuetype? If so, I'm afraid that omniORB does not support it yet. By `complies', we mean that those bits which exist adhere to the spec. There are still some missing features. Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From Ben.Miller@Mercia.Com Wed Jan 10 17:52:40 2001 From: Ben.Miller@Mercia.Com (Ben Miller) Date: Wed, 10 Jan 2001 17:52:40 -0000 Subject: [omniORB] omniORB 3.0.x Message-ID: Okay. Yes, sorry, I do mean valuetype! In that case, can I use omniORB3 with RMI over IIOP? I've seen some discussion on this list previously that suggested that this could be done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's web-site (http://java.sun.com/j2se/1.3/docs/guide/rmi-iiop/rmi_iiop_pg.html#Wha tIs) says: "RMI-IIOP will interoperate with other ORBS that support the CORBA 2.3 specification. It will not interoperate with older ORBs, because these are unable to handle the IIOP encodings for Objects By Value. This support is needed to send RMI value classes (including strings) over IIOP." So I'm a bit confused as to whether the two will co-operate or not. Is it the case that I will have to be careful not to try to manipulate any non-IDL-native types in my interfaces? Can anyone shed any light on this? Cheers, Ben -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: 10 January 2001 17:42 To: Ben Miller Cc: 'omniorb' Subject: Re: [omniORB] omniORB 3.0.x On Wednesday 10 January, Ben Miller wrote: > Just a quick question: am I right in thinking that since this version > of omniORB complies to the 2.3 CORBA spec, it supports pass by value > semantics? I assume you mean valuetype? If so, I'm afraid that omniORB does not support it yet. By `complies', we mean that those bits which exist adhere to the spec. There are still some missing features. Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- Mercia Software Ltd. Mercia House Ashted Lock Aston Science Park Birmingham B7 4AZ, UK Registered Number: 1868855 (Cardiff) Tel: 44 (0)121 359 5096 Fax: 44 (0)121 359 0375 Web Site: http://www.mercia.com From dgrisby@uk.research.att.com Wed Jan 10 18:04:23 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 18:04:23 +0000 Subject: [omniORB] omniORB 3.0.x In-Reply-To: Message from Ben Miller of "Wed, 10 Jan 2001 17:52:40 GMT." Message-ID: <200101101804.SAA31174@pineapple.uk.research.att.com> On Wednesday 10 January, Ben Miller wrote: > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > discussion on this list previously that suggested that this could be > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > web-site I'm pretty certain that omniORB cannot be used with RMI-IIOP at the moment, no matter what types you use in your Java interfaces. If anyone knows otherwise, please let us know. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From popowich@chiliad.com Wed Jan 10 18:37:56 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 10 Jan 2001 13:37:56 -0500 Subject: [omniORB] omniORB 3.0.x In-Reply-To: <200101101804.SAA31174@pineapple.uk.research.att.com> References: <200101101804.SAA31174@pineapple.uk.research.att.com> Message-ID: <14940.44036.867756.866744@buckland.lilybay.com> Duncan Grisby writes: > On Wednesday 10 January, Ben Miller wrote: > > > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > > discussion on this list previously that suggested that this could be > > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > > web-site > > I'm pretty certain that omniORB cannot be used with RMI-IIOP at the > moment, no matter what types you use in your Java interfaces. If > anyone knows otherwise, please let us know. As the one who kicked off the "RMI over IIOP" thread and tried many ways to get omniORB to compile the IDL spit out from Sun's rmic compiler (jdk 1.3) I think I can verify that omniORB cannot be used with RMI-IIOP. The two sticking points for me were the usage of wstring (any usage of String in your java interface was converted to a wstring in the IDL) and valuetype (used liberally throughout the IDL), neither of which are supported by omniORB. I don't know if there are any other sticking points since I couldn't get beyond those problems. If you accept votes for what to develop next: whatever is needed for RMI-IIOP! Daniel Popowich From eliot@isogen.com Wed Jan 10 18:59:49 2001 From: eliot@isogen.com (W. Eliot Kimber) Date: Wed, 10 Jan 2001 12:59:49 -0600 Subject: [omniORB] omniORB 3.0.x References: <200101101804.SAA31174@pineapple.uk.research.att.com> <14940.44036.867756.866744@buckland.lilybay.com> Message-ID: <3A5CB125.DFCD06AD@isogen.com> Daniel Popowich wrote: > > Duncan Grisby writes: > > On Wednesday 10 January, Ben Miller wrote: > > > > > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > > > discussion on this list previously that suggested that this could be > > > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > > > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > > > web-site > > > > I'm pretty certain that omniORB cannot be used with RMI-IIOP at the > > moment, no matter what types you use in your Java interfaces. If > > anyone knows otherwise, please let us know. Just an info question: How is RMI-IIOP different from simply using CORBA object through java? I have the latter working with no difficulty (just ran idltojava on my IDL and imported the resulting client stub classes) against an OmniORB server, so I assume that RMI-IIOP is different from just using the built-in java ORB. Thanks, E. -- . . . . . . . . . . . . . . . . . . . . . . . . W. Eliot Kimber | Lead Brain 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.656.4139 | F 512.419.1860 | eliot@isogen.com w w w . d a t a c h a n n e l . c o m From popowich@chiliad.com Wed Jan 10 20:03:02 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 10 Jan 2001 15:03:02 -0500 Subject: [omniORB] omniORB 3.0.x In-Reply-To: <3A5CB125.DFCD06AD@isogen.com> References: <200101101804.SAA31174@pineapple.uk.research.att.com> <14940.44036.867756.866744@buckland.lilybay.com> <3A5CB125.DFCD06AD@isogen.com> Message-ID: <14940.49142.534595.865334@buckland.lilybay.com> W. Eliot Kimber writes: > Daniel Popowich wrote: > > > > Duncan Grisby writes: > > > On Wednesday 10 January, Ben Miller wrote: > > > > > > > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > > > > discussion on this list previously that suggested that this could be > > > > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > > > > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > > > > web-site > > > > > > I'm pretty certain that omniORB cannot be used with RMI-IIOP at the > > > moment, no matter what types you use in your Java interfaces. If > > > anyone knows otherwise, please let us know. > > Just an info question: How is RMI-IIOP different from simply using CORBA > object through java? I have the latter working with no difficulty (just > ran idltojava on my IDL and imported the resulting client stub classes) > against an OmniORB server, so I assume that RMI-IIOP is different from > just using the built-in java ORB. Simply, instead of being IDL->java, it's java->IDL. With RMI-IIOP, java programmers don't need to know a thing about IDL. They write their interfaces in java and implement their servers in java, just like RMI. Java client programmers can use the java interfaces without having to know any IDL mappings. It works like this: you write your interface in java, implement your server in java and then run the rmic compiler with a special switch, as in: 'rmic -iiop -idl mydomain.Foo' and *poof* you end up with Foo.idl. Now c++ or python programmers can compile Foo.idl and communicate with the java server. The problem folk are having is this: java passes by reference, so to express java in IDL required a new IDL type: valuetype. This allows passing objects by value. Think of it as a struct with methods, or an interface with data. The irony is that no other orb other than Sun's jdk (that I know of) support the new IDL types. So, it will be great, someday. Daniel Popowich From jeff@infohazard.org Wed Jan 10 20:25:11 2001 From: jeff@infohazard.org (Jeff Schnitzer) Date: Wed, 10 Jan 2001 12:25:11 -0800 Subject: [omniORB] omniORB 3.0.x Message-ID: <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> >From: Daniel Popowich [mailto:popowich@chiliad.com] > >The problem folk are having is this: java passes by reference, so to >express java in IDL required a new IDL type: valuetype. This allows >passing objects by value. Think of it as a struct with methods, or an >interface with data. The irony is that no other orb other than Sun's >jdk (that I know of) support the new IDL types. So, it will be great, >someday. I'm in the exact same situation; in fact, I subscribed to this list two days ago because I'm trying to figure out how to use RMI-IIOP to talk to a C++ server object. My guess is that if someone was super careful writing the Java interfaces (use byte[] instead of String, simple types only), rmic will probably produce idl which makes omniORB happy. Unfortunately I need to be able to burst an array of structures across the wire on a single remote call, so I (apparently) need valuetypes. I'm bewildered that CORBA had no standard way to send structs until so recently; Microsoft has had structs in the DCOM IDL for years. I'm going to be taking a look at Orbacus (http://www.ooc.com/ob/) next; it claims to support valuetypes. It's a commercial product but supposedly free for noncommercial use. I believe there are other commercial ORBs which support valuetypes, but they get pretty expensive. Jeff From popowich@chiliad.com Wed Jan 10 21:51:21 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 10 Jan 2001 16:51:21 -0500 Subject: [omniORB] omniORB 3.0.x In-Reply-To: <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> References: <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> Message-ID: <14940.55641.496778.188904@buckland.lilybay.com> Jeff Schnitzer writes: > I'm in the exact same situation; in fact, I subscribed to this list two > days ago because I'm trying to figure out how to use RMI-IIOP to talk to > a C++ server object. Funny. I joined the list a few weeks ago for the same reason. > Unfortunately I need to be able to burst an array of structures across > the wire on a single remote call, so I (apparently) need valuetypes. > I'm bewildered that CORBA had no standard way to send structs until so > recently; Microsoft has had structs in the DCOM IDL for years. You *can* do this with CORBA (a sequence of structs) and always have been able to, it's just that rmic maps java objects to valuetypes. > I'm going to be taking a look at Orbacus (http://www.ooc.com/ob/) next; > it claims to support valuetypes. It's a commercial product but > supposedly free for noncommercial use. I believe there are other > commercial ORBs which support valuetypes, but they get pretty expensive. If you come up with something, please post it. -d From eliot@isogen.com Wed Jan 10 21:52:35 2001 From: eliot@isogen.com (W. Eliot Kimber) Date: Wed, 10 Jan 2001 15:52:35 -0600 Subject: [omniORB] omniORB 3.0.x References: <200101101804.SAA31174@pineapple.uk.research.att.com> <14940.44036.867756.866744@buckland.lilybay.com> <3A5CB125.DFCD06AD@isogen.com> <14940.49142.534595.865334@buckland.lilybay.com> Message-ID: <3A5CD9A3.CC7DB864@isogen.com> Daniel Popowich wrote: > It works like this: you write your interface in java, implement your > server in java and then run the rmic compiler with a special switch, > as in: 'rmic -iiop -idl mydomain.Foo' and *poof* you end up with > Foo.idl. Now c++ or python programmers can compile Foo.idl and > communicate with the java server. So am I correct in understanding this to mean that, modulo the non-support of valuetype, I don't have to explicitly write Java servants (as I would in Python or C++) in order to give remote CORBA clients access to the Java objects? If so, that's pretty handy. However, it seems to me that in real applications, you will almost always need to tailor your CORBA API in a way that is different from a straight Java API (or a straight Python API for that matter), such that a completely automatic mapping from Java classes to IDL classes will usually not be the optimal solution. So maybe it's not such a big deal in practice given that I may be motivated to write special Java CORBA servants anyway? Thanks, E. -- . . . . . . . . . . . . . . . . . . . . . . . . W. Eliot Kimber | Lead Brain 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.656.4139 | F 512.419.1860 | eliot@isogen.com w w w . d a t a c h a n n e l . c o m From Michael Lauer Thu Jan 11 00:41:03 2001 From: Michael Lauer (Michael Lauer) Date: Thu, 11 Jan 2001 01:41:03 +0100 Subject: [omniORB] Is this list active ? Message-ID: No mail since 6.12.2000 hmmm... have I been removed ? If so, why ? :M: -- Michael 'Mickey' Lauer . . . . . . . . . mickey@Vanille.de How could anyone know me - when I don't even know myself ? From Ben.Miller@Mercia.Com Thu Jan 11 09:58:14 2001 From: Ben.Miller@Mercia.Com (Ben Miller) Date: Thu, 11 Jan 2001 09:58:14 -0000 Subject: [omniORB] omniORB 3.0.x Message-ID: Er, snap (only I joined yesterday!)... -----Original Message----- From: Daniel Popowich [mailto:popowich@chiliad.com] Sent: 10 January 2001 21:51 To: Jeff Schnitzer Cc: popowich@chiliad.com; omniorb-list Subject: RE: [omniORB] omniORB 3.0.x Jeff Schnitzer writes: > I'm in the exact same situation; in fact, I subscribed to this list two > days ago because I'm trying to figure out how to use RMI-IIOP to talk to > a C++ server object. Funny. I joined the list a few weeks ago for the same reason. > Unfortunately I need to be able to burst an array of structures across > the wire on a single remote call, so I (apparently) need valuetypes. > I'm bewildered that CORBA had no standard way to send structs until so > recently; Microsoft has had structs in the DCOM IDL for years. You *can* do this with CORBA (a sequence of structs) and always have been able to, it's just that rmic maps java objects to valuetypes. > I'm going to be taking a look at Orbacus (http://www.ooc.com/ob/) next; > it claims to support valuetypes. It's a commercial product but > supposedly free for noncommercial use. I believe there are other > commercial ORBs which support valuetypes, but they get pretty expensive. If you come up with something, please post it. -d Mercia Software Ltd. Mercia House Ashted Lock Aston Science Park Birmingham B7 4AZ, UK Registered Number: 1868855 (Cardiff) Tel: 44 (0)121 359 5096 Fax: 44 (0)121 359 0375 Web Site: http://www.mercia.com From rogerb@harlequin.co.uk Thu Jan 11 10:29:48 2001 From: rogerb@harlequin.co.uk (Roger Barnett) Date: Thu, 11 Jan 2001 10:29:48 +0000 Subject: [omniORB] omniORB 3.0.x Message-ID: <802569D1.0039A980.00@notesman.man.harlequin.co.uk> >From: Daniel Popowich [mailto:popowich@chiliad.com] > >The problem folk are having is this: java passes by reference, so to >express java in IDL required a new IDL type: valuetype. This allows >passing objects by value. Think of it as a struct with methods, or an >interface with data. The irony is that no other orb other than Sun's >jdk (that I know of) support the new IDL types. So, it will be great, >someday. Err no, the problem is that people are trying to express Java in IDL - reverse engineering is never easy ! One good reason for ORB implementors being slow to support the whole objects-by-value thing is that the spec has been through some fairly major revisions (at least twice, IIRC) to try and get it "right". IMO this was largely because until the shape of CORBA Component support was finally decided there was no clear justification for introducing such a language-specific carbuncle onto the OMA and into OMG IDL. This is also why some of the more complex (and expensive) commercial products have now implemented obv - its part of their EJB/"portal" strategy. Roger Barnett From dgrisby@uk.research.att.com Thu Jan 11 10:31:51 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 11 Jan 2001 10:31:51 +0000 Subject: [omniORB] omniORB 3.0.x In-Reply-To: Message from "Jeff Schnitzer" of "Wed, 10 Jan 2001 12:25:11 PST." <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> Message-ID: <200101111031.KAA32609@pineapple.uk.research.att.com> On Wednesday 10 January, "Jeff Schnitzer" wrote: > Unfortunately I need to be able to burst an array of structures across > the wire on a single remote call, so I (apparently) need valuetypes. > I'm bewildered that CORBA had no standard way to send structs until so > recently; Microsoft has had structs in the DCOM IDL for years. CORBA has always had structs and other complex constructed types. The problem is that with most types in Java it is acceptable to use a nil reference to indicate the absence of an object. The original CORBA types have no way to represent that (although it has always been possible to fake it with unions or bounded sequences). Part of the objects by value specification adds "value boxes", which either contain the boxed type, or nil. So, you can have IDL like valuetype StringValue string; which is a type containing either a normal string, or nil. The Java to IDL mapping maps lots of things like that. The other problem is that with RMI, you can transmit objects which have behaviour as well as state. This relies on being able to transmit compiled code (via HTTP) if the receiving process doesn't have it. This clearly isn't going to work when transmitting to a language other than Java. But CORBA has a go anyway. You can declare a valuetype like valuetype Foo { public long l; public string s; long doSomething(in short a, in boolean b); }; When you receive one of those, you have to hope that you have an implementation of the doSomething() method, or you can get one from somewhere. Java can, in theory, transmit the code by HTTP as with RMI, but I'm not sure if it actually does yet. You could do the same thing with Python, as long as both client and server were Python. With C++, there's no hope at all. Anyway, it's all horribly ugly. If you want to be totally confused, read the section of the GIOP spec about marshalling valuetypes. It's going to be a long time before interoperability between ORBs is as good with valuetypes as it is with the other types. That said, we will probably support valuetype in the next major releases of omniORB and omniORBpy. No promises, though. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From erberj@post.ch Thu Jan 11 15:43:35 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 11 Jan 2001 16:43:35 +0100 Subject: [omniORB] error compiling idl generated code Message-ID: <26D7602EA56DD21197BB0000F840029A03EA5512@hceh71.post.ch> When compiling the result of an IDL run, i do get the follwoing error. What is causing it? Thanks in advance Jakob class LongListCT : public _CORBA_Unbounded_Sequence< CORBA::LongLong> { .......................................................^ %CXX-E-EXPTYPSPECIFIER, expected a type specifier at line number 480 in file OMNIROOT:[SRC.EXAMPLES.ECHO]BASECS.HH;1 From prapier@coactive.com Fri Jan 12 01:17:25 2001 From: prapier@coactive.com (Peter Rapier) Date: Thu, 11 Jan 2001 17:17:25 -0800 Subject: [omniORB] corbaloc Message-ID: <7118259C3044D311942700508B2CA5BB4F2585@balance.coactive.com> I have worked with Orbacus 3, a BOA based orb that contains the "corbaloc" feature of the INS. Would it be possible to port this feature, which is in OO3 back into omniORB2.6? From looking through the archives it would appear that the INS has some dependency on the POA. Thanks Peter From erberj@post.ch Fri Jan 12 08:00:53 2001 From: erberj@post.ch (erberj@post.ch) Date: Fri, 12 Jan 2001 09:00:53 +0100 Subject: [omniORB] OmniOrb 3.0 and "long long" Message-ID: <26D7602EA56DD21197BB0000F840029A03EA5516@hceh71.post.ch> Hi, does OmniOrb support this type? The idl compiler translates it, but the ORB Include files seem not to know it. Regards Jakob From vonWedel@lfpt.rwth-aachen.de Fri Jan 12 08:52:38 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Fri, 12 Jan 2001 09:52:38 +0100 Subject: [omniORB] omniORB / omniORBpy binaries for use with Python 2.0 Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0031FBA1C12569D2_= Content-Type: text/plain; charset="us-ascii" Hi omniORBers, the omniORBpy pages state that > These binaries only work with Python 1.5.2. They will not work with later Python versions. Once Python 2.0 is released, we shall provide binaries for that too. Is there a plan when binaries for Python 2.0 will be released? Lars --=_alternative 0031FBA1C12569D2_= Content-Type: text/html; charset="us-ascii"
Hi omniORBers,

the omniORBpy pages state that

> These binaries only work with Python 1.5.2. They will not work with later Python versions. Once Python 2.0 is released, we shall provide binaries for
that too.

Is there a plan when binaries for Python 2.0 will be released?

Lars
--=_alternative 0031FBA1C12569D2_=-- From srowe@adaptivebroadband.com Fri Jan 12 09:20:58 2001 From: srowe@adaptivebroadband.com (Rowe, Simon) Date: Fri, 12 Jan 2001 09:20:58 -0000 Subject: [omniORB] Problems with omniORB app on WinNT Message-ID: <35940AC31FFCD311AAF8009027D0D07D2F5686@cambr-exch1.cambridge.adaptivebroadband.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07C78.F90B21F0 Content-Type: text/plain; charset="iso-8859-1" We're experiencing a problem with our application on Windows NT that is running fine on Linux and would appreciate some help with diagnosing what is wrong. Our application consists of four components, EC, EA, CS and a GUI. The first three are written in C++ using omniORB 2.8.0, the GUI is written in Java. The EC and EA are to run on NT, they can be started and can commuicate with each other. The CS runs on Linux, it fails to contact the EC, it cannot get a reference to the EC object. The GUI runs on either NT or Linux, neither can contact the EC. If I try and telnet to the IIOP port on the NT machine (either from the NT machine or from the Linux machine) I get a connection refused. netstat -a shows something is listening on INADDR_ANY on the expected port. If I shut down our processes and start an omniNames server on the same port I can connect to it. I've tried running with -ORBtraceLevel 25 all this shows is that the accept() is not unblocked for the above cases that fail. The previous version of our product worked fine but we've undergone an extensive re-write recently. I'm wondering if this is an OS issue but the debugging enviroment is so poor (I'm not a Windows fan...) I'm working blind. Any tips? Simon ------_=_NextPart_001_01C07C78.F90B21F0 Content-Type: text/html; charset="iso-8859-1"

We're experiencing a problem with our application on Windows NT that is running fine on Linux and would appreciate some help with diagnosing what is wrong.

Our application consists of four components, EC, EA, CS and a GUI. The first three are written in C++ using omniORB 2.8.0, the GUI is written in Java.

The EC and EA are to run on NT, they can be started and can commuicate with each other. The CS runs on Linux, it fails to contact the EC, it cannot get a reference to the EC object. The GUI runs on either NT or Linux, neither can contact the EC. If I try and telnet to the IIOP port on the NT machine (either from the NT machine or from the Linux machine) I get a connection refused. netstat -a shows something is listening on INADDR_ANY on the expected port.

If I shut down our processes and start an omniNames server on the same port I can connect to it.

I've tried running with -ORBtraceLevel 25 all this shows is that the accept() is not unblocked for the above cases that fail. The previous version of our product worked fine but we've undergone an extensive re-write recently.

I'm wondering if this is an OS issue but the debugging enviroment is so poor (I'm not a Windows fan...) I'm working blind.

Any tips?

Simon

------_=_NextPart_001_01C07C78.F90B21F0-- From srowe@adaptivebroadband.com Fri Jan 12 10:53:07 2001 From: srowe@adaptivebroadband.com (Rowe, Simon) Date: Fri, 12 Jan 2001 10:53:07 -0000 Subject: [omniORB] Problems with omniORB app on WinNT Message-ID: <35940AC31FFCD311AAF8009027D0D07D2F5687@cambr-exch1.cambridge.adaptivebroadband.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07C85.D8DD1AFC Content-Type: text/plain; charset="iso-8859-1" Er, scratch that one. It was a port configuration error. Sorry about that. Simon ------_=_NextPart_001_01C07C85.D8DD1AFC Content-Type: text/html; charset="iso-8859-1"

Er, scratch that one. It was a port configuration error. Sorry about that.

Simon

------_=_NextPart_001_01C07C85.D8DD1AFC-- From dgrisby@uk.research.att.com Fri Jan 12 11:33:54 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 12 Jan 2001 11:33:54 +0000 Subject: [omniORB] POA/BOA IOR compatibility In-Reply-To: Message from Peter Rapier of "Tue, 09 Jan 2001 11:14:06 PST." <7118259C3044D311942700508B2CA5BB4F256D@balance.coactive.com> Message-ID: <200101121133.LAA02806@pineapple.uk.research.att.com> On Tuesday 9 January, Peter Rapier wrote: > We are hearing that clients created with POA based ORB's are having problems > understanding a persistent IOR we create on our omniORB 2.6 - based server. > It is my understanding that clients should be able to talk to our BOA based > orb regardless of their ORB's object adapter and that IOR's have a specified > format. Why would there be a problem with one ORB parsing or otherwise > understanding anothers ORB's IOR? Any info that can be shared with me on > this topic would be greatly appreciated. There should be no problem with using an IOR from any ORB with any version of omniORB. POAs and BOAs don't come into it. What error are you getting? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Fri Jan 12 11:47:30 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 12 Jan 2001 11:47:30 +0000 Subject: [omniORB] Problems building omniORB3 on SunOS 5.6 In-Reply-To: Message from Richard.Turner@aculab.com of "Wed, 10 Jan 2001 17:17:14 GMT." <0AEF0EB21F09D211AE4E0080C82733BFBFB333@mailhost.aculab.com> Message-ID: <200101121147.LAA02853@pineapple.uk.research.att.com> On Wednesday 10 January, Richard.Turner@aculab.com wrote: > All appears to be well until I get to here ... [...] > ../../../../bin/sun4_sosV_5.6/omkdepend: warning: (from idlpython.cc) > idlpython > .cc: 302: # error "omniidl requires Python 1.5.2 or higher" > > This looks suspicious already as omnipython claims that it _is_ 1.5.2 ... Don't worry about that. omkdepend doesn't understand #ifdefs properly, so it tends to output spurious warnings. It doesn't affect anything. > $ ./omnipython > Could not find platform independent libraries [...] The errors you get on loading omnipython are because you are running it with a relative path. The trick it uses to find its libraries relies on it having an absolute path, or being found in $PATH. Again, it's nothing to worry about since the build process uses an absolute path. > The build continues but eventally collapses at ... > > make[2]: Entering directory `/usr/local/src/richard/omni/src/lib/omniORB2' > + mkdir -p omniORB3 > ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 > -ComniORB3 ../../../idl/Naming.idl > Segmentation Fault Now that's bad. I don't know why it would segfault. Can you look at the core file in dbx, and see where it died? The executable for the core is omnipython. There isn't any debugging information in either omnipython or the omniidl shared library, but you should at least be able to see which function it died in. It's possible that the omnipython binary for SunOS 5.6 is broken in some way. We don't have any 5.6 machines here, but someone told us that the 5.5 binary worked fine on 5.6 too. One thing you can try is to compile and install a full version of Python, from the py152.tgz file. That might help. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Fri Jan 12 12:07:33 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 12 Jan 2001 12:07:33 +0000 Subject: [omniORB] OmniOrb 3.0 and "long long" In-Reply-To: Message from erberj@post.ch of "Fri, 12 Jan 2001 09:00:53 +0100." <26D7602EA56DD21197BB0000F840029A03EA5516@hceh71.post.ch> Message-ID: <200101121207.MAA03039@pineapple.uk.research.att.com> On Friday 12 January, erberj@post.ch wrote: > does OmniOrb support this type? > The idl compiler translates it, but the ORB Include files seem not to know > it. omniORB 3.0.2 does support it, as long as you don't use the -Wba flag to omniidl. It is only supported on platforms where we know there is long long support in the C++ compiler. If you have a platform which we don't know about, you need to edit include/omniORB3/CORBA_sysdep.h and #define HAS_LongLong and the other long long macros in the section for your compiler. Recompile everything, and you'll have long long. If you successfully enable long long for a new platform, please let us have the patches, and we'll make it part of the next release. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Fri Jan 12 12:09:00 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 12 Jan 2001 12:09:00 +0000 Subject: [omniORB] omniORB / omniORBpy binaries for use with Python 2.0 In-Reply-To: Message from vonWedel@lfpt.rwth-aachen.de of "Fri, 12 Jan 2001 09:52:38 +0100." Message-ID: <200101121209.MAA03070@pineapple.uk.research.att.com> On Friday 12 January, vonWedel@lfpt.rwth-aachen.de wrote: > the omniORBpy pages state that > > > These binaries only work with Python 1.5.2. They will not work with > later Python versions. Once Python 2.0 is released, we shall provide > binaries for > that too. > > Is there a plan when binaries for Python 2.0 will be released? When we release the next minor update to omniORB and omniORBpy, which will probably be quite soon, we'll do Python 2.0 binaries. Expect it in a few weeks. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Fri Jan 12 12:12:22 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 12 Jan 2001 12:12:22 +0000 Subject: [omniORB] corbaloc In-Reply-To: Message from Peter Rapier of "Thu, 11 Jan 2001 17:17:25 PST." <7118259C3044D311942700508B2CA5BB4F2585@balance.coactive.com> Message-ID: <200101121212.MAA03088@pineapple.uk.research.att.com> On Thursday 11 January, Peter Rapier wrote: > I have worked with Orbacus 3, a BOA based orb that contains the "corbaloc" > feature of the INS. Would it be possible to port this feature, which is in > OO3 back into omniORB2.6? From looking through the archives it would appear > that the INS has some dependency on the POA. Thanks There are two aspects to support for corbaloc. On the client side, string_to_object need to understand the corbaloc and corbaname URI formats. That bit should be relatively easy to back-port to omniORB 2.6. On the server side, you need to be able to create object keys with simple string names, like "NameService". That bit would be very hard to support in omniORB 2.x. To do the client-side bit, you should look at include/omniORB3/omniURI.h and src/lib/omniORB2/orbcore/uri.cc, which is where most of the corbaloc work is done. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From andreas.eglseer@lisec.com Fri Jan 12 14:44:55 2001 From: andreas.eglseer@lisec.com (Andreas Eglseer - Entwicklung) Date: Fri, 12 Jan 2001 15:44:55 +0100 Subject: [omniORB] callTimeOutPeriod() Message-ID: <9AF728C3B988D411B3F000805F0DD5C3079309@swserv3.lisec.com> Hey, is it possible to change the callTimeOutPeriod at Runtime e.g: callTimeOutPeriod(omniORB::clientSide,100); .... // CORBA function call callTimeOutPeriod(omniORB::clientSide,500); .... // CORBA function call I'm using omniORB 3.02 on aix and red hat 6.2 & 7.0 with a Jacorb ( Java Client ) running on win98 Thank's for your help Andreas From prapier@coactive.com Fri Jan 12 16:58:57 2001 From: prapier@coactive.com (Peter Rapier) Date: Fri, 12 Jan 2001 08:58:57 -0800 Subject: [omniORB] corbaloc Message-ID: <7118259C3044D311942700508B2CA5BB4F2587@balance.coactive.com> Hi, Its the server side I need to work with. I have omniOrb2.6 on the server but clients using it are being created with the newer products that include corbaloc. Peter -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: Friday, January 12, 2001 4:12 AM To: Peter Rapier Cc: 'omniorb-list@uk.research.att.com' Subject: Re: [omniORB] corbaloc On Thursday 11 January, Peter Rapier wrote: > I have worked with Orbacus 3, a BOA based orb that contains the "corbaloc" > feature of the INS. Would it be possible to port this feature, which is in > OO3 back into omniORB2.6? From looking through the archives it would appear > that the INS has some dependency on the POA. Thanks There are two aspects to support for corbaloc. On the client side, string_to_object need to understand the corbaloc and corbaname URI formats. That bit should be relatively easy to back-port to omniORB 2.6. On the server side, you need to be able to create object keys with simple string names, like "NameService". That bit would be very hard to support in omniORB 2.x. To do the client-side bit, you should look at include/omniORB3/omniURI.h and src/lib/omniORB2/orbcore/uri.cc, which is where most of the corbaloc work is done. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From djr@uk.research.att.com Fri Jan 12 17:15:10 2001 From: djr@uk.research.att.com (David Riddoch) Date: Fri, 12 Jan 2001 17:15:10 +0000 (GMT) Subject: [omniORB] corbaloc In-Reply-To: <7118259C3044D311942700508B2CA5BB4F2587@balance.coactive.com> Message-ID: On Fri, 12 Jan 2001, Peter Rapier wrote: > Its the server side I need to work with. I have omniOrb2.6 on the server > but clients using it are being created with the newer products that include > corbaloc. Duncan Grisby wrote: > There are two aspects to support for corbaloc. On the client side, > string_to_object need to understand the corbaloc and corbaname URI > formats. That bit should be relatively easy to back-port to omniORB > 2.6. On the server side, you need to be able to create object keys > with simple string names, like "NameService". That bit would be very > hard to support in omniORB 2.x. Just to expand, the difficulty largely stems from the fact the omniORB 2.x uses fixed length (12-byte I think) keys. I think I can see a way to hack a solution if you could live with keys that are <=12 bytes in length ... (by padding out keys that are shorter). Would this be useful? Cheers, David From dgrisby@uk.research.att.com Fri Jan 12 17:19:57 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 12 Jan 2001 17:19:57 +0000 Subject: [omniORB] corbaloc In-Reply-To: Message from Peter Rapier of "Fri, 12 Jan 2001 08:58:57 PST." <7118259C3044D311942700508B2CA5BB4F2587@balance.coactive.com> Message-ID: <200101121719.RAA04088@pineapple.uk.research.att.com> On Friday 12 January, Peter Rapier wrote: > Its the server side I need to work with. I have omniOrb2.6 on the server > but clients using it are being created with the newer products that include > corbaloc. What exactly are you trying to achieve? As David Riddoch says, it may be possible to coerce omniORB 2.6 into doing what you want directly. However, I think a better solution might be to use omniMapper from omniORB 3 to redirect INS-style object keys to objects in the 2.6 server. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From prapier@coactive.com Fri Jan 12 19:34:12 2001 From: prapier@coactive.com (Peter Rapier) Date: Fri, 12 Jan 2001 11:34:12 -0800 Subject: [omniORB] POA/BOA IOR compatibility Message-ID: <7118259C3044D311942700508B2CA5BB4F258E@balance.coactive.com> The problem we had was that our omniOrb 2.6 server object's IOR did not work with a client based on BEA's M3. It did string_to_object but using the object reference did not work. We wound up bootstrapping the object another way. The other things we are hearing I can not verify, but I do know there are some users (of our products) under the general belief that POA based orbs won't interoperate with our omniorb 2.6 server. We do not need any of the POA enhancements. Our concern is interoperability. I am investigating the IOR issue in light of the above. Thank you. Peter One thing that would be very useful is the corbaloc URL for bootstrapping purposes. -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: Friday, January 12, 2001 3:34 AM To: Peter Rapier Cc: 'omniorb-list@uk.research.att.com' Subject: Re: [omniORB] POA/BOA IOR compatibility On Tuesday 9 January, Peter Rapier wrote: > We are hearing that clients created with POA based ORB's are having problems > understanding a persistent IOR we create on our omniORB 2.6 - based server. > It is my understanding that clients should be able to talk to our BOA based > orb regardless of their ORB's object adapter and that IOR's have a specified > format. Why would there be a problem with one ORB parsing or otherwise > understanding anothers ORB's IOR? Any info that can be shared with me on > this topic would be greatly appreciated. There should be no problem with using an IOR from any ORB with any version of omniORB. POAs and BOAs don't come into it. What error are you getting? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From prapier@coactive.com Fri Jan 12 19:45:13 2001 From: prapier@coactive.com (Peter Rapier) Date: Fri, 12 Jan 2001 11:45:13 -0800 Subject: [omniORB] corbaloc Message-ID: <7118259C3044D311942700508B2CA5BB4F258F@balance.coactive.com> Yes this would be very useful Bootstrapping the main server object is the issue and corbaloc seems to address this very well. Its object key is 8 chars long. Peter -----Original Message----- From: David Riddoch [mailto:djr@uk.research.att.com] Sent: Friday, January 12, 2001 9:15 AM To: Peter Rapier Cc: 'omniorb-list@uk.research.att.com' Subject: RE: [omniORB] corbaloc On Fri, 12 Jan 2001, Peter Rapier wrote: > Its the server side I need to work with. I have omniOrb2.6 on the server > but clients using it are being created with the newer products that include > corbaloc. Duncan Grisby wrote: > There are two aspects to support for corbaloc. On the client side, > string_to_object need to understand the corbaloc and corbaname URI > formats. That bit should be relatively easy to back-port to omniORB > 2.6. On the server side, you need to be able to create object keys > with simple string names, like "NameService". That bit would be very > hard to support in omniORB 2.x. Just to expand, the difficulty largely stems from the fact the omniORB 2.x uses fixed length (12-byte I think) keys. I think I can see a way to hack a solution if you could live with keys that are <=12 bytes in length ... (by padding out keys that are shorter). Would this be useful? Cheers, David From steve.brenneis@attws.com Fri Jan 12 19:53:11 2001 From: steve.brenneis@attws.com (Brenneis, Steve) Date: Fri, 12 Jan 2001 14:53:11 -0500 Subject: [omniORB] POA/BOA IOR compatibility Message-ID: Not to be flip, but this explains a lot. BEA's ORB products don't seem to be interoperable with much of anything. -----Original Message----- From: Peter Rapier [mailto:prapier@coactive.com] Sent: Friday, January 12, 2001 2:34 PM To: 'Duncan Grisby'; Peter Rapier Cc: 'omniorb-list@uk.research.att.com' Subject: RE: [omniORB] POA/BOA IOR compatibility The problem we had was that our omniOrb 2.6 server object's IOR did not work with a client based on BEA's M3. It did string_to_object but using the object reference did not work. We wound up bootstrapping the object another way. The other things we are hearing I can not verify, but I do know there are some users (of our products) under the general belief that POA based orbs won't interoperate with our omniorb 2.6 server. We do not need any of the POA enhancements. Our concern is interoperability. I am investigating the IOR issue in light of the above. Thank you. Peter One thing that would be very useful is the corbaloc URL for bootstrapping purposes. -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: Friday, January 12, 2001 3:34 AM To: Peter Rapier Cc: 'omniorb-list@uk.research.att.com' Subject: Re: [omniORB] POA/BOA IOR compatibility On Tuesday 9 January, Peter Rapier wrote: > We are hearing that clients created with POA based ORB's are having problems > understanding a persistent IOR we create on our omniORB 2.6 - based server. > It is my understanding that clients should be able to talk to our BOA based > orb regardless of their ORB's object adapter and that IOR's have a specified > format. Why would there be a problem with one ORB parsing or otherwise > understanding anothers ORB's IOR? Any info that can be shared with me on > this topic would be greatly appreciated. There should be no problem with using an IOR from any ORB with any version of omniORB. POAs and BOAs don't come into it. What error are you getting? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From count0@building2.co.jp Sat Jan 13 04:40:28 2001 From: count0@building2.co.jp (Huw Rogers) Date: Sat, 13 Jan 2001 13:40:28 +0900 Subject: shutdown() SEGVs (was Re: [omniORB] atexit, exit, _exit, and ORB::destroy()) References: <200012041043.KAA07951@pineapple.uk.research.att.com> Message-ID: <3A5FDC3C.4B6BAD5A@building2.co.jp> I'm getting consistent crashes (SEGVs) on both Linux and Solaris in shutdown(). (omniORB 3.0.2, RedHat 7.0 and Solaris 8). This is a problem since I want to embed the code making use of omniORB in a web server. It cannot leak memory and it must clean up after itself. Enclosed is some diagnostic information from Linux. Before I shutdown I set the omniORB trace level to 25 and install a SEGV handler that waits forever so I can attach gdb to the specific thread that SEGV'd and get a stack trace. I took a look at the omniORB code myself, and I wonder if omniORB_Ripper::run_undetached() is interfering with Rope::CutStrands(). There certainly seems to be some inconsistency in the manner of locking and iterating through ropes and strands as they are being disposed of. The omniORB_Ripper code looks dubiously thread unsafe to the casual observer. But unfortunately I don't understand it fully and am also working under a deadline. If anyone has any advice or (hope!) a patch, I would much appreciate it. -Huw Log: omniORB: Preparing to shutdown ORB. omniORB: Starting an ORB shutdown thread. omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1058 omniORB: tcpSocketMTfactory Worker: #### Connection closed. omniORB: tcpSocketMTfactory Worker: exit. omniORB: tcpSocketStrand::~Strand() close socket no. 11 omniORB: ORB shutdown already in progress -- waiting. omniORB: ORB shutdown thread started. omniORB: Deinitialising omniDynamic library. omniORB: Destroying POA(RootPOA). omniORB: Destroying POA(KitDConference). omniORB: Deactivating all POA(KitDConference)'s objects. omniORB: Waiting for requests to complete on POA(KitDConference). omniORB: Etherealising POA(KitDConference)'s objects. omniORB: Destruction of POA(KitDConference) complete. omniORB: Destroying POA(KitDConferenceDSP). omniORB: Deactivating all POA(KitDConferenceDSP)'s objects. omniORB: Waiting for requests to complete on POA(KitDConferenceDSP). omniORB: Etherealising POA(KitDConferenceDSP)'s objects. omniORB: Destruction of POA(KitDConferenceDSP) complete. omniORB: Destroying POA(KitDIsdnLine). omniORB: Deactivating all POA(KitDIsdnLine)'s objects. omniORB: Waiting for requests to complete on POA(KitDIsdnLine). omniORB: Etherealising POA(KitDIsdnLine)'s objects. omniORB: Destruction of POA(KitDIsdnLine) complete. omniORB: Destroying POA(KitDVoiceDSP). omniORB: Deactivating all POA(KitDVoiceDSP)'s objects. omniORB: Waiting for requests to complete on POA(KitDVoiceDSP). omniORB: Etherealising POA(KitDVoiceDSP)'s objects. omniORB: Destruction of POA(KitDVoiceDSP) complete. omniORB: Destroying POA(MvBase). omniORB: Deactivating all POA(MvBase)'s objects. omniORB: Waiting for requests to complete on POA(MvBase). omniORB: Etherealising POA(MvBase)'s objects. omniORB: Destruction of POA(MvBase) complete. omniORB: Deactivating all POA(RootPOA)'s objects. omniORB: Deactivating: root<0> (has local refs). omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: strand Rope_iterator: delete unused Rope. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Waiting for requests to complete on POA(RootPOA). omniORB: Etherealising POA(RootPOA)'s objects. omniORB: omniLocalIdentity deleted. omniORB: Stopping incoming rope factories. omniORB: tcpSocketStrand::real_shutdown() fd no. 7 Done 19488: SEGV #3 __pthread_alt_unlock (lock=0x80a7e78) at spinlock.c:581 #4 0x402fe0f4 in __pthread_mutex_unlock (mutex=0x80a7e68) at mutex.c:194 #5 0x402ea234 in omni_mutex::unlock () from /opt/omniORB3/lib/libomnithread.so.2 #6 0x400ec5f8 in Strand::decrRefCount () from /opt/omniORB3/lib/libomniORB3.so.0 #7 0x40117929 in omniORB_Ripper::run_undetached () from /opt/omniORB3/lib/libomniORB3.so.0 #8 0x402ea975 in omni_thread_wrapper () from /opt/omniORB3/lib/libomnithread.so.2 #9 0x402fda20 in pthread_start_thread (arg=0xbf7ffc00) at manager.c:274 omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1058 19652: SEGV #4 0x402fe0f4 in __pthread_mutex_unlock (mutex=0x80a7e68) at mutex.c:194 #5 0x402ea234 in omni_mutex::unlock () from /opt/omniORB3/lib/libomnithread.so.2 #6 0x400ed40f in Strand_iterator::~Strand_iterator () from /opt/omniORB3/lib/libomniORB3.so.0 #7 0x400ecef7 in Rope::CutStrands () from /opt/omniORB3/lib/libomniORB3.so.0 #8 0x400f86b5 in tcpSocketIncomingRope::cancelThreads () from /opt/omniORB3/lib/libomniORB3.so.0 #9 0x400f794d in tcpSocketMTincomingFactory::stopIncoming () from /opt/omniORB3/lib/libomniORB3.so.0 #10 0x400b597a in omniObjAdapter::adapterInactive () from /opt/omniORB3/lib/libomniORB3.so.0 #11 0x400be812 in omniOrbPOA::do_destroy () from /opt/omniORB3/lib/libomniORB3.so.0 #12 0x400b8d26 in omniOrbPOA::destroy () from /opt/omniORB3/lib/libomniORB3.so.0 #13 0x400bf6cc in omniOrbPOA::shutdown () from /opt/omniORB3/lib/libomniORB3.so.0 #14 0x400d78c7 in omniOrbORB::actual_shutdown () from /opt/omniORB3/lib/libomniORB3.so.0 #15 0x400d7a12 in shutdown_thread_fn () from /opt/omniORB3/lib/libomniORB3.so.0 #16 0x402ea91f in omni_thread_wrapper () from /opt/omniORB3/lib/libomnithread.so.2 #17 0x402fda20 in pthread_start_thread (arg=0xbf1ffc00) at manager.c:274 omniORB: scavenger : scanning connections omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketStrand::~Strand() close socket no. 16 omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: strand Rope_iterator: delete unused Rope. omniORB: tcpSocketStrand::~Strand() close socket no. 15 omniORB: tcpSocketMTfactory ~tcpSocketOutgoingRope: called omniORB: tcpSocketMTfactory Rendezvouser: waiting on shutdown state to change to NO_THREAD. omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1058 From zdx_nari@sina.com Sun Jan 14 06:52:13 2001 From: zdx_nari@sina.com (zdx_nari) Date: Sun, Jan 14 2001 14:52:13 +0800 Subject: [omniORB] Cann't make the echo eg.to run properly! Message-ID: <20010114065253.22820.qmail@sina.com> Hello,every one: When I run the "make all" in omni/src/examples/echo directory,it runs well.Then ,I enter ./eg2_impl,it gives 'IOR: ... '.But after that ,the processor stops (why?).So I have to kill it with "Ctrl+C".After that,I cut and paste the 'IOR: ... ' and run ./eg2_clt 'IOR: ... '.But it gives an error message:"Caught system exception COMM_FAILURE--Unable to contact the object ." My OS is the Redhat Linux 6.2 and I have set the LD_LIBRARY_PATH variable. Could you help me! Best regards! ______________________________________ =================================================================== ��ѵ�� http://mail.sina.com.cn ��ѡ�ֻ��򵥣�(http://mall.sina.com.cn/yesmobile/) From qbxncdy@snt.BellSouth.com Mon Jan 15 03:56:57 2001 From: qbxncdy@snt.BellSouth.com (Harry Tang) Date: Sun, 14 Jan 2001 22:56:57 -0500 Subject: [omniORB] Need help on omniOrb3.02 installation. Message-ID: <3A627509.DDFB2939@snt.bellsouth.com> This is a multi-part message in MIME format. --------------05273AA2E4CB5E25E356F3D4 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Hi, I need help from omniORB expert on this list. I tried to install omniORB 3.02 on unix system SUNOS5.6(which is solaris 2.6), and I plan to use gcc(2.8.1) as my C++ compiler. The tar file I download from att site is source code(not a binary distribution). Following README.unix file for installation and configuration, I stucked in step 3. 3. Building and installing -------------------------- The makefiles in this distribution only work with GNUmake. Make sure that you have the program installed and invoke it directly. You can skip this step if this is a pre-compiled binary distribution. To build and install everything, go into the directory ./src and type 'make export'. If all goes well, the libraries and executables will be installed into ./lib// and ./bin//. 'make export' had fatal failure, don't know how to make target export. In my src directory I do have GNUmake file, which is a very short file. Can someone tell me how to 'make export' successfully? Thanks, Harry --------------05273AA2E4CB5E25E356F3D4 Content-Type: text/x-vcard; charset=big5; name="qbxncdy.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Harry Tang Content-Disposition: attachment; filename="qbxncdy.vcf" begin:vcard n:Tang;Harry x-mozilla-html:FALSE org:Bellsouth;Science and Technology adr:;;;;;; version:2.1 email;internet:harry.tang@snt.bellsouth.com note;quoted-printable:(O)404-9274090=0D=0A(H)770-4512661=0D=0A(P)404-6722977 x-mozilla-cpt:;-25096 fn:Harry Tang end:vcard --------------05273AA2E4CB5E25E356F3D4-- From yan_gao@hp.com Mon Jan 15 07:17:46 2001 From: yan_gao@hp.com (GAO,YAN (HP-Singapore,ex3)) Date: Mon, 15 Jan 2001 15:17:46 +0800 Subject: [omniORB] start process on demand Message-ID: <912404552D6CD411B57700D0B77532260173DD14@xsg03.sgp.hp.com> Hi, I got following query. 1) Do every one know if there is a method in omniOrb that can be called to launch a process for you? For example I got a tow process A and B. In Process A I would like to start the process B. 2) For client to locate the server, I know there are two ways: a) IOR Obviously the IOR is not practical as shown in the example to pass IOR as parameter for the client. b) NameService Is there are other ways? Regards, Gao Yan From dgrisby@uk.research.att.com Mon Jan 15 10:41:09 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 15 Jan 2001 10:41:09 +0000 Subject: [omniORB] POA/BOA IOR compatibility In-Reply-To: Message from Peter Rapier of "Fri, 12 Jan 2001 11:34:12 PST." <7118259C3044D311942700508B2CA5BB4F258E@balance.coactive.com> Message-ID: <200101151041.KAA15885@pineapple.uk.research.att.com> On Friday 12 January, Peter Rapier wrote: > The problem we had was that our omniOrb 2.6 server object's IOR did not work > with a client based on BEA's M3. It did string_to_object but using the > object reference did not work. We wound up bootstrapping the object another > way. > The other things we are hearing I can not verify, but I do know there are > some users (of our products) under the general belief that POA based orbs > won't interoperate with our omniorb 2.6 server. We do not need any of the > POA enhancements. Our concern is interoperability. I am investigating the > IOR issue in light of the above. omniORB 2.6's IORs are perfectly valid for all versions of the CORBA 2 specification, so any ORB which fails is buggy. Nothing has changed between omniORB 2 and omniORB 3, except that the object key within the IOR can now vary in length rather than always being 12 bytes long. To clients, object keys are just an opaque sequence of bytes, so it is irrelevant whether the server is based on the BOA or POA. If your client ORB has difficulties with an omniORB IOR when using string_to_object, but not when receiving it by some other means, the ORB is very broken. The stringified form of an IOR is exactly the same as the form which is transmitted in an operation parameter, just written as hex digits rather than binary data. I think it is a bit of a waste of effort to try to come up with corbaloc based schemes without finding out exactly what M3 has a problem with. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 15 11:49:34 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 15 Jan 2001 11:49:34 +0000 Subject: [omniORB] Cann't make the echo eg.to run properly! In-Reply-To: Message from zdx_nari of "Sun, 14 Jan 2001 14:52:13 +0800." <20010114065253.22820.qmail@sina.com> Message-ID: <200101151149.LAA16177@pineapple.uk.research.att.com> On Sunday 14 January, zdx_nari wrote: Your email program seems to be very broken. Please try to fix it. > When I run the "make all" in omni/src/examples/echo directory,it > runs well.Then ,I enter ./eg2_impl,it gives 'IOR: ... '.But after > that ,the processor stops (why?).So I have to kill it with > "Ctrl+C".After that,I cut and paste the 'IOR: ... ' and run > ./eg2_clt 'IOR: ... '.But it gives an error message:"Caught system > exception COMM_FAILURE--Unable to contact the object ." eg2_impl is meant to stop when you run it -- it is running, waiting for connections. If you kill it with Ctrl-C, it isn't running any more. That's why the client can't connect! You should run eg2_impl in one window, and eg2_clt in another. Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 15 12:30:17 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 15 Jan 2001 12:30:17 +0000 Subject: [omniORB] Need help on omniOrb3.02 installation. In-Reply-To: Message from Harry Tang of "Sun, 14 Jan 2001 22:56:57 EST." <3A627509.DDFB2939@snt.bellsouth.com> Message-ID: <200101151230.MAA17667@pineapple.uk.research.att.com> On Sunday 14 January, Harry Tang wrote: > I tried to install omniORB 3.02 on unix system SUNOS5.6(which is solaris > 2.6), and I plan to use gcc(2.8.1) as my C++ compiler. The tar file I > download from att site is source code(not a binary distribution). I don't think omniORB will work with gcc 2.8.1. You should use gcc 2.95.2. > 'make export' had fatal failure, don't know how to make target export. > In my src directory I do have GNUmake file, which is a very short file. > Can someone tell me how to 'make export' successfully? Are you _sure_ you are using GNU make? What happens if you do "make -v"? If it doesn't claim to be GNU make, then that's the problem. Maybe you need to use "gnumake" rather than just "make". Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 15 12:32:57 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 15 Jan 2001 12:32:57 +0000 Subject: [omniORB] start process on demand In-Reply-To: Message from "GAO,YAN (HP-Singapore,ex3)" of "Mon, 15 Jan 2001 15:17:46 +0800." <912404552D6CD411B57700D0B77532260173DD14@xsg03.sgp.hp.com> Message-ID: <200101151232.MAA17685@pineapple.uk.research.att.com> On Monday 15 January, "GAO,YAN (HP-Singapore,ex3)" wrote: > 1) Do every one know if there is a method in omniOrb that can be called > to launch a process for you? For example I got a tow process A and B. No, omniORB has no built-in way to do that. You have to write it yourself. > 2) For client to locate the server, I know there are two ways: > a) IOR Obviously the IOR is not practical as shown in the example to > pass IOR as parameter for the client. > b) NameService For simple boot-strapping, you can use the corbaloc URI scheme. In most cases, most of the object references you use will be returned from method invocations on other objects. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From aklilu.mehari@distefora.com Mon Jan 15 10:58:20 2001 From: aklilu.mehari@distefora.com (Aklilu Mehari) Date: Mon, 15 Jan 2001 11:58:20 +0100 Subject: [omniORB] naming service problems Message-ID: <000001c07ee2$136504b0$18bea8c0@aklilu.navigon.de> Hallo, I would like to implement a server and client corba application. I have implemented a server application. If i try to execute this application, i am getting an error message "Caught system exception COMM_FAILURE -- unable to contact the naming service." while calling the function bind_new_context(). Can you please write me how i can remove this error? or write me what the causes can be? From dwalter@syr.edu Mon Jan 15 14:10:07 2001 From: dwalter@syr.edu (David Walter) Date: Mon, 15 Jan 2001 09:10:07 -0500 (EST) Subject: [omniORB] naming service problems In-Reply-To: <000001c07ee2$136504b0$18bea8c0@aklilu.navigon.de> Message-ID: On Mon, 15 Jan 2001, Aklilu Mehari wrote: Is the nameservice running on your host? Is omniORB.cfg or if NT the registry correctly pointing to the nameservice host:port? (/etc/omniORB.cfg) Make sure that the -start port number agrees with the port you specify in omniORB.cfg. see ORBInitRef in the documentation for the format of omniORB.cfg. What version of omniORB are you running by way? If you have successfully compiled and run the echo eg3_(impl|clt) applications then these shouldn't be the problem but perhaps that will help. >Hallo, > >I would like to implement a server and client corba application. >I have implemented a server application. If i try to execute this >application, i am getting an error message "Caught >system exception COMM_FAILURE -- unable to contact the naming service." >while calling the function >bind_new_context(). Can you please write me how i can remove this error? or >write me what the causes can be? > > > > -- Respectfully: David Walter Karma: Whenever you are there you go. dwalter@syr.edu Office: CST::1-120 Phone: (315) 443-5811 From daniel.tabouillot@vizionfactory.com Mon Jan 15 14:37:50 2001 From: daniel.tabouillot@vizionfactory.com (Daniel von Tabouillot) Date: Mon, 15 Jan 2001 15:37:50 +0100 Subject: [omniORB] W3C's IDL... Message-ID: <149C1E86A8BED3119F880090277B719728C6BC@STORE> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C07F00.BC3B14D0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F00.BC3B14D0" ------_=_NextPart_001_01C07F00.BC3B14D0 Content-Type: text/plain; charset="iso-8859-1" Hi, W3C have generated some so-called OMG IDL for the SMIL and SVG standards ( attached as zip file ). First of all, there are name clashes ( readOnly and readonly keyword ), and secondly, omniidl has some trouble, as seen below. We are only using the C++ binding, so is there any way to make omniidl case sensitive ? What can I do about error below ? I'm running omniORB 3.0.2 on Win2000, SP1 & MS Visual Studio 6, SP4. Thanks. Sincerely, Daniel von Tabouillot __________________________________________________________________ Performing Custom Build Step on .\html.idl omniidl: Importing back-end `cxx' omniidl: `cxx' imported from `D:\CORBA\OMNI\lib\python\omniidl_be\cxx\__init__.pyc' omniidl: Preprocessing `.\html.idl' with `omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2301 -D__OMNIIDL_CXX__ .\html.idl' omniidl: Running front end omniidl: Running back-end `cxx' omniidl: Fatal error in C++ backend omniidl: omniidl: An AttributeError exception was caught For more information (mailing list archives, bug reports etc) please visit the webpage: http://www.uk.research.att.com/omniORB/omniORB.html Error executing d:\winnt\system32\cmd.exe. ------_=_NextPart_001_01C07F00.BC3B14D0 Content-Type: text/html; charset="iso-8859-1"

Hi,

W3C have generated some so-called OMG IDL for the SMIL and SVG standards ( attached as zip file ). First of all, there are name clashes ( readOnly and readonly keyword ), and secondly, omniidl has some trouble, as seen below. We are only using the C++ binding, so is there any way to make omniidl case sensitive ? What can I do about error below ? I'm running omniORB 3.0.2 on Win2000, SP1 & MS Visual Studio 6, SP4.

Thanks.

Sincerely, Daniel von Tabouillot

__________________________________________________________________

Performing Custom Build Step on .\html.idl
omniidl: Importing back-end `cxx'
omniidl: `cxx' imported from `D:\CORBA\OMNI\lib\python\omniidl_be\cxx\__init__.pyc'
omniidl: Preprocessing `.\html.idl' with `omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2301 -D__OMNIIDL_CXX__ .\html.idl'
omniidl: Running front end
omniidl: Running back-end `cxx'
omniidl: Fatal error in C++ backend
omniidl:
omniidl: An AttributeError exception was caught
For more information (mailing list archives, bug reports etc) please visit
the webpage:
http://www.uk.research.att.com/omniORB/omniORB.html
Error executing d:\winnt\system32\cmd.exe.

------_=_NextPart_001_01C07F00.BC3B14D0-- ------_=_NextPart_000_01C07F00.BC3B14D0 Content-Type: application/octet-stream; name="idl.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="idl.zip" UEsDBBQAAAAIAMaKVig1ZiWmMAcAAHYSAAAOABUAQ09QWVJJR0hULmh0bWxVVAkAAxMMszibMsU4 VXgEAEM2RQC1WG1v47gR/mz/iqlbXBLAtrK3e+i+OAYUW9mo67fKStNF0Q+0RFu8SKKPouL1v78Z SpSdt8XtpTWQxJLIZ2aeGT4zyuAv4/ko/Lrw4DqcTmBxcznxR9DpOc7t25HjjMNx9eBd/xxCxfJC aCFzljqON+u04dlPJ9F6+9Fxdrtdf/e2L9XGCQMn8Ea9RGfpu3MnlbLg/VjHnWF7QPeGiDRIOIuH BnKQcc2AUHr8t1LcX3RGMtc8171wv+UdiKqri47m37RDAJ8gSpgquL4Qhey9f//Lh96bTg2mhU75 EMMBfxHAcn4V3rqBB7N56I+8gVM9Jgcc68FgJeM9rDaRTKW66Pz1ynw6QObw8tx8LHzyZljz8IKJ aplj1w2St3bDSG73SmwSDT9F+PUT/Iy4MEhlBIni64tniOwMb6VKY7gVMYdbvmqQ8kIqLcpsgOxG wy6cPg+TRkU/E7rP4xKxpqwoWJSUSJwuaig/L5CSUnOQawh5lOTIwmZvcZ+HFbkSrL9WiGn313Az VhUMoL8BonGFP8BztLOWKsOnv5V4remWW2pZ3zk2VyM9MXrHheyzqP/rFs1+wQu4ycU9V1ijtbtn fXDTFALi2MYX8IKrex73bV7qdAy2Ni0hOjieT2El8ljkmwKY4rAtV6koEh5DmcdcgcZFlPClXOsd LTgkcya1iHgNxvIYJniZY8Ub5MJuSKu7oKjGFS+gU20k3lm+p4rON3hbqhoqk7FYi8gQWoCWjQ9r kfKiCyKP0pI8Ng9ihim0GDuOBjMW837nqGLQMB6jdN+toTE4Qx/BoxP6MQ9ZWWiIZVRmuA0fM5tk XLnHB5BLTYeTEnvsX6GRBabiT+iiuRmxglsL/nhiLXQPcLBVbJMx/MPX4htuyBEcUonRKFhxONm9 jehAnDyL+Q92z2osC12BsuiObTjkLENSnoDWSCeIi+ctOrHrbalsH1fKYDXEnPGPA2c1NMmVWAGC qr3m0Tr0g5WCJJZ4yNGltcRyA6ZhwI6PwclTZThIgDPhG1ToyJrp2ZLrvfnw4f35338+Pxm+bv/A YcNHnHxH1XDXu14lbew1wsaMrD0D8QpRI8znIP8PglaZ+nNixr4vZfAH0vkduROFKdCdVHdwelAR m/Zuc+ZRZKQCiRWtULZSVJgYhOZZcQbCOrXitHer5D1mEmt4X53OpigSmaJ+FkcyupZpKne0K7VC ebmv0eRKM5GbA1wWtARPiYM+EF6ldOg8Od6FvSzhlPBqFH4GbKM4PxYqWpOwexJdFncrHwotJX6n 47cTSHEks226x+86eeSe5ioraGGNhlIXm3mo+PiSQixwiyiMFKAgYk12jeuVOaO6+yqGpi3QA6GL hnNTblYZjVMYPv2VpX7QEro/5ati+wn9VaZ/bEu1xTmrDqxav+b80E+U3LNU7zF1gAnlmKkNTniY 0+4hfcSdYa0qC/6IEQzLnUwaOraCN53jQUAPgqEAtlSbpo2Rabk+6l7PdbvuwZGM3fHHdMu0UeRU DNstkuJ1ibmkia1yCIOsxjFSeYaiXyHDveA7tkp5nR5l/W+3FI9FoZVYlVTm6DPWirjHXVg+VHF9 a9Ihm8fmXWIf5ZJ/QwCiSSCracojXaJuILdbrpB3hI9SJjI02qXWiWVbHTBTZ+0WEXcosT74a1yV o7YQLFYQFAmyWO+0tB9yQ2rUbp0me7JGPCAF1E65UpTi5hZVqMYQzwivbjvIRFU0VUtst8xEXA8m 3yMmkjH/CJ3HPaDd+s/faCDpyXXTTf77Q+2g9epO0PqfNIHWa/W/9Wek/1j7Wz8k+50Xq/SlafPH 5sx264VBE05vSWZRTfHgx+bo1qoCN4Hf4NqD2G6tlcxgl4goqTsGrsT6NMWFwZ49CWTg2HN/1Myu /eXhBcydjXGCHd1MvVnohv58Bvh0Ecz/5Y+9MXTcJV53O2bZaL74Gvifr8Ma6Ho+GXvBEqbuF3qR g8BbBN7S4ixhHgCaCNxZ6HvLLnj/psfmtj9dTHxvbCXbn40mN2N/9hkub0LSIJj4Uz9E++G8e4QB 8yuYesHoGi/dS3/ih18J7coPZwhcg13hHXf2FRZugFp2M3EDfGUPFvOlR2vDazfEXx7c0PWV+dpw MQ9qjIeE3PqTifHKn10F6KVn8JHGYGyskK0QV2OMDUVLG1sYuGNv6gZfTOBztBdAteLFkbkBaRhu PLj0kBr3cuI1YY79wBuFXfTNflsuvJHvTg7RjDAZ3j9v0EO6PXan7mfk0g38JVE+R8qRCML645y8 6Du1FXp1MC1NK6zyjKk70zGezjcZ25uorJqK3M75MZ5tLcw0Q52QXiwjPOqkxPWwYw9H00Nt/y62 PKKz2cwDiqQ7x5MlCKoZNvBVk/6tQTgHz4yWPx418Oxbv4pCRsLMdA/btZmKsPsyaqiC3pwUBi7y ahpp8O1kW8X/gER8P8L+MWwPnOq/Pb8DUEsDBBQAAAAIALldZygmfvOYMAwAAGR/AAALABUAaWRs L2Nzcy5pZGxVVAkAAz4yxTibMsU4VXgEAEM2RQDtXW1z27gR/u5fgbl8aHKTsVOnd22duQ+yLMec kyWNRMWXfvFAJCSiIQkeCEp2Ov3vXfBFLxQpQTpJq07LmbvIJLF4dvFgsViA5NWPF+RH0hTRq+QT T5G3zjty/eHDB/IkpO+SJ+4y8sRGcEcYC6l4ErzXBd4+0jimjpfETKmYWGGsuEoUI2JMbOZ4ofDF 5PX9/ALpUMVFSH3iMl2+D/cwCf8RFsJNYyEDuOH3BP5W+lQjUSI/8578yrggw5BPmYy5en13SRq+ n0rRkGMQFjM5Ze4lsT0ek0iKiaQBgZ8uj5XkIwDmkiR0mSQKqnz62PxTTAZirGZUpnCsUDHfZ45K AGFPiohJ9Ura3GFhzDaL5aGWqYV4UAx+U0W4IjPu+2TECBhonPjvCdxMniz7oTu0SaPzlTw1+v1G x/76Ce5UnoCrbMpCLUYj5EHkcxAO+CQNAQqY9bHVbz5Akcat1bbsr0RIcm/ZndZgQO67fdIgvUbf tprDdqOvxfSG/V530LokA5ZqXGhDPKWim6ur2Wx2Oft4KeTkatG2V202of4VgfYggchs4zJFuR9f wu+ri4urK3LPfXZDnDi+5K5/8YaPwbBj8twcDJ6tu/bzxRv4k4ds6QzcFDp+AlT6wRWBLvbD0qlY vfos9hhTcfmSpwK/fG7K2Sy/8eJNJOkkoNA2UOVLJn320dFa/XARCDfxmQZ68a8LQtRrxDRQuOfm 5q77OIAmDCdk/utT+Z6WzwIWKpL/u3YdSlrQTunFlN1k7cynCyjEgVxyTB1GwCB9gPSpfHKgLTDQ Fqi+dMccn8pcYumGL9RPyhJFon+vnoQeV5Le/3zbhG4qU5DQrtAJJJjMyUgNupA2cNIn1zdVSrSh DxBtV0Iko64I/VdCVd4toLPFfBKCJF+AjeHwWThR3qf0/lwCWTq4YsFbqHW1HAdmvbzThf69H8gc IJTTf9nQeunfDhBeLeqKPWB/hmPY+bXTfeo894ftFlk/fiEfPm2RMLC/tlt15bWEP2+TAL28P2jZ 9Riut0mwHnvdfq0AkPBxm4TH1p3V2KTFX7ZJuO927Of7RrPGFr+Qn7ZJ6DU+bzAkSPg5JcVm/hXy dM/NKpwfi7sX3iA/wGfY7EWVCmw4gGGS8pjFbwvX0HpxWKR77DsCnkEPkyC/Fu+KE9D3RDAyhWrV MdSVXO1MWcnCz+zRcdJKU5k3pX5kYrqY6XFUSBz7LXlKgKLP7GmER+ZyWmmEitqXRrCbm7Rk6h1J oH9ua7ns1px1+kSclVhzoRohBDpp077N4Oeml3DmPTEwdo2HNW6m2jbKIE8Fd0slXKCDYgXk41W+ RxPfi1Ddw2/TVj44x3p08j/fzyBeEhmlTZpgzQoeBH61HWzvbrnqiuMVJ7yHjk2PSjDs3k3NQke4 eYR68GbeQ59h+C0Us7BCn31Hm2U6mdvluKP0WnWETJgqJodp2L3qhaP8UocG7N080k1vJJUyiqtb xVRAkSwQU1ZI2iDhUL59szl6kgvJNwKpHSLihZj64kbDG1kpPtW23aNclOtyMNPtOj+qMPW2+dGJ QsOMzPNJ1TDkSk+q4m0zGp0I6Dy0+pZdZT6DWZWW0Otbj5ZtfWk9f2m0h61VCdtnVSAhLffctgbr MAxmVVpCcziwwT7VWnzM5yPz45xmGGsapd3DzqdF+0Qvkgdc8SnLSHHzB/mRz7yrLWvEj87w8bbV r2kbI370Wv1mq2PDvLNCghE/Wo+DugY0mHWnEn7bIGHrrDvV4rc6ASaz7pTl1QzPJPxsIuFxk4S/ mkiwKqmQS/ibkR0qnU0u4e9GEpobJPzZiJR3rc8bRBixst+42yDCiJaf62WACCNe1hNbizAiZr0E LcKImQ//2CTCiJq/1ssAEUbcvLMeW52B1a2gKIgwIufA7ludamqACCN2DvtWvSLXRuy07sDd1Yow YmfDtqt9birCbFDtDjt2tecGEUbs7Leadb0dRBixU6fDu+1uFQwQ8dMOucaoGBntedKxOuy99wVV 8ylASU6SD55mEWwaw461vOz/qdSDRbCZ4JVjYgj/mMklMGEWVdWBiNOru1hxdSoQL6QfeSK1rMfB qsoXgpZLQFX52QPXpdeXSiWgLn320BXly1alivKzB61s3xlSmmZaC4j3WCYrJw8OvUw2t+WmpGcp 0Ie73E1TzvLtE8lYuEuBUb6gubMymoG7KKJEtAuudIPETooIpUSwSwmfjfdLMuYd3Txxyl0WKj7m 2TKxWRkfaD0ocr1mRWIW6byekPtolS+86yxx6POQpXWfMD9/3fjOg0R5u3XlIgqgWeFFDHCgZhkJ 4TMaLpzCiHngATYNko1w4rPagXq/IOMUAcZ23EeOLqx5c6xmJtNm2sFmRZuN8Aam61vqfJtIcBRu T8Q87R178Rr+4d9FqKi/kdrr+SYmFXe2lFpf4JnXZu3hsYo6y2Wr6fYwr6uw0Ns5372Dsq26/i85 2vXapyfgerX2pWb0doql82OhxkF9RrUaVUYsKTHdXYmTqlBAr/M+3uLCHk2xtECykIPpl4R0mRxE 1NGYkF3SNseQw8TxC2uVn9YtLFV/AK+A4hTqVdjdJxxFga0diFR1oTz81/ugK+ad82OHuNPk2GlF qgLEUv4tt4zGf+pNDqTeM+VmtUJHZjuB/3tNywsdzmUPyXUzkbGQRv5+Ja2ij0Ty2HwzZyRZtiPd zeo8GxP0fPp6l8i9h71oXt7eaXfrolw5Lj6wUczgAJLT1b42ew74C2LtkkWMnk+n1FsSBh4wb7a9 N84xOdlDBKa3L4I18zJFoGZeYuQne+WctBWKjaED6ezg549HYxOXmD1BZe4DxrmOem/V2dCvMPwT d5UX72R7Gk6Oo4eZ+cMkGDEZ78s4vRN4wL9X7KIxGQdm2ly7zXw8ppPZfyw3WT1ZSdtuMUWZnWB+ 9JAqo+13rHlZ9awiVbWotmTi2Q7ziZNOhVaN9UcmcieFvTETi5i9yHeucraLu8qXBhBjrtE8GXwW IBpKUcc72vxkVzjNRUSDjMQK6NHGtd2QFEnJswDTP17YbAglTVqiAwCi+jSKURlSAMHtMctJZHwc i0VyRBR2sb0BEUN/sWcCEcXt0kYMRBjtfHcHKghgxXl01pQa5wEl48d5YNEkOQ8kwJTzcGQpU84D SsaU88CimXIeSIAp6VwYHUjKlPOAkjHlPLBoppwHEnwUyJGAQ9PCA+5idlvHZxRzgHF8jhmbOsjj qyNChZvrcEpL2/hQ+kdb/DeEkaB2yIQ1xgo1owAQbtlYSFwzHG2B3gyAyyVzkNNcLo/1Cj0iAuaz KUW2Agsi9dpkvl/e6XFKEE4cpw+5IULQC7XI1d/TgPuYfNQg9IrVGUBouP9MYuwGgTNMOZhxdIYC d+6pMXyhklP0DvLEkNOcHjYAHze16UOBc0j/66fUHtDbYvUxPVwM2AuYcyBnsH45x1KxXfOUOAIq JxzTEBkA3PWpDAP2+lSGAn19KoOBvD4FIL4x2R2PcRMBGgbmnCOgL+hDCGDAztQGPMQ3Aw+xzSBk 5NEQk48iUTqswUeAvSqaw8AOrXIY6MScMjn2xQwRQkTdo70WdycEuJFMDgI7lMlhoMcyOQ7kYCbC nfbo6m8lo9+wVxXmQNDXFuZIrDDGXX2NaIK6ZTOtH58YAAKfFBw3j5rW3z/iw0tGIObPg2KCwM/P /J4IxTBDbckdL2QxLgTcKCLGXeaJIxggsOt/YBT34YIURScJmCweucWD0UtC/Vk+ZNcAUJh21AqV nEriOgdFRz5r01eYgmKiYC+q4fMJJh80hjvmCIlNTA3ECl3cLVxq/toAZBC2pGGsH4XHxIGaDEhC 7giX3XL3hC/VWENRvK8Bu5tOecxH3OcKc/fKVHCHoe+hmQo/OdKrHswAzDyumF6iRwXBwUlhDqEz 5LTtTEgXf5/Edz1kHee9O/t+giz73NvN6kfjlq5kT/ebfGVJzEImi48s/f/Lj+f25ccvnM2gAaCp 0y9J39w0RhBYU0fpC3kzV71KOn1zfhBB+7npNa1V8Ylo5hu/DVgfq58bi1niipav9tLmTjhJ/pLs MnmLS8uvza5RrAsDtuQuw1Gs5hV8d+WvaWc6rp0uqTb/biN0K+h7iq1cWO0+iivD/lOtYvolyUI9 reEbFrp8rNVc+vr5fwBQSwMEFAAAAAgAtV1nKCwW54e0CAAAOzYAAAsAFQBpZGwvZG9tLmlkbFVU CQADNTLFOJsyxThVeAQAQzZFANUb227jNvbdX0F0HpoUQTKTdLvdpFlAsZWOsLbsleRmsi+GItE2 AZlURSqJW/Tf91AXRxdKVhJ52gqYGUvkufJcSc7ZdwP0HRqycBuR1VqgI+8YnX/8+BHdsSjw0R3x MbrDDzCDchYJEm9OJMDRxOXc9dYxx0JwZFAuiIgFRmyJHOytKQvYanuyG0CmKwijboB8LOEtmIMj +IMwhUlLFm1gwq8xvAv5SYsFy76coP9gwtCckkcccSK2x6dIC4IEi2SZAzKOo0fsnyJnTTgKI7aK 3A2Cnz7hIiIPwJiPYurjCAkgeXcx/JYjmy3Fkxsl7BhU4CDAnoiBw1nEQhyJLRoTD1OO29ESKnFK JGsAg9+uQESgJxIE6AEjUNAyDk4QTEZ3hvN5OneQZt6jO82yNNO5v4KZYs1gFD9iKtFIDskmDAgg B/4ilwIroNaJbg0/A4h2Y4wN5x6xCN0ajqnbNrqdWkhDM81yjOF8rFkSzWxuzaa2fopsnEicS4PW QoSXZ2dPT0+nTxenLFqdvazt2Riv3OAMwXqgDUt142PhkoCfwu+zweDsDN2SAF8in21OiR8MPpAl KHaJFqPpZGGMxovBB3glFBe+DD6EkbvauKBDGHpG3zxdeJLyN4MN8+MAS2SD3wcIiW2IJTKOYeGp h3+KKScrCprga+Dw3whQ2qB6uroaFKYjtJsXMLpK/4KpDtlgW7ibMJlNYJGjpethNGJevMFUOAB/ pRwpfzWZj8ew5pWv7gb7cmjihuURPcApEviKnz0cStuXDOm7Fyltge1EPPjgATqJ648EFpS9gxgy 6TkwATyqDgePYY70Lwvb+J++0C0LVZ9r9OmqFV6q1rEM82c1jmt03g7/2dAtDUz0fmHp/53rtlNG cY0u2uHvrCnQHk2H84luOgr637fDG+Yv2tgYLcBJLG3o6FaV/j/a4c3pYqQ52kIbj6d3+qjKwDX6 YS/8ZDoybo2h5hhTs4rnGv1zH7yzuJ3OzRrlnP6P++Ht+Ww2tZw69xL+X/v0N7f1heaADdzMnZoB gP18vEptEqJlBH7rpdEP7AaNIXgF6Pyy0wLZjlZHnxD49D4C9j1Exy9q9aUEzvuRoLTOL+SAwMX7 CJjaRLdn2lDtwpLA9/1IoA2HkDgUTvYJvKQSLKcTA9JREtHcQux6YCzALi2Cr11+i10RR/goZSqN 1WiZfjxBA+XClJ4SYJLxGT2+SgD3iY1KgT3D50VAHBcHyrz9CimfLCHZynDeiUMlp2H8EBDP8N+O gW+5wBvDP+6MIHIJx/yomFderakCurKmylqioBwegjnMLaOziD3oWaIorqnPPJn036+jPyolgczj mWGD8uSbpJe8N3uTPtaTXGVOR7qCdpZy2zC8hFsljizptmFw9C+NDKBd2m3DMEzSnq0Pk3BWQ5Ul 3lY9mA5UpJD3b3VLN4dVYbLU2wFDkxxZ8m3DMLOmMqTJ+sUwoZCZl8XJ0m+rHqaT9tX8cR+GXfGi RpGl4E4YnPuZwibyJNwJxa2l/VznJk+ze0oJTW0MOYrzxH3AvbDrMxpskSuyjqjg8tlDwZmk01+V nXYPxC9uEFdBWh5wWpWrI0hXskUF5H2gijDwiR/doFH6mjppFkqumiCSyFN8QmhKqTCzTqARRjYk OxhvTYKkF+Hd6SxJxMVQAnaHCdxXg0DP90hYzG0CGVI2bl0BKX4We4EKPVgCtBviu0w4YX6SeJR5 UGXA1dTIniiOip0hqjMrcwnHkbjB0DsnJUYyheKnRF0dE14OBm1yAtZHLaBgNcJhAEkvIfFeVlng H5bVDXuscHpgkm4YYuqrldMHSXXhPNx58FEza17AKJbfJWM5Hh/jsHPd98iIX0FK5eZbQH7DR52x KETgcRhCxONvrfzfVfd3SkOFErYr3t3Tgjfd0+o1U/UodcA8N8izr6roTdLI741BDVoSuaLl/TVC ffx83BiUy5MlE5iuxFrJQTF+N3KxwiKZaGTclPuSZnfhFbhkihutDhqr2jg9DN2+F6mL7e1ZJdPu u3/cGXLnoLDHIFIW+zSJN7FUMZpeFNesu9775uHajVwP3kaucNFlsY/ePS3hyQeov3GRr/Kdmowy Nz7w5JNUUt1T2XIJ7Hdd3Rq4x2Iq+rBfRW2Q1kI52y+i9eQxCoppGf1uRX0lbn0cYIH74PbrrWlW /b/fFtVcd4bteX2qkUkDdy0HpK5VYmPOrJW9PMRe0lt239t47H1f4+3VYnZO+UIt6XR3p5d1neYA r1arcFcvW0CKCAm1g5ZDN1Z4ClvmrXDdW9lC6yHX52CeJ3N9m6A90E3svvwUtZt3j0oNK2C5AjaZ Bi2x/PdALFdUVaIM/X9flGsbaYmyMjPnN1sntdtGhXU4aGk39r9CobzHr/pn8e1nQf276ZvUU7XO v3jR3kXKDmGjLzHfa68dolTKat9xqluD1yGe9KbJHrSp3o7cn43fjfnQoa9avDj4WVYu5Y41LWGS ofLDw4AI+b2pRj5AL802WXVV57E2Vx7a2thLLmRcpgKo5pVOz/uthmtnL0CGCNJ2BFWFoCy9UsK7 mlQXpvOrGH3izC9n9IkzWSTqBnb8AOak3p/Nbty8euHKOnithLWyXy7s9mtz0fV0OdVR0x53yruF lziSN0qLQlSnziLmYc4Buby2HMXe23QvoJ3FontH2PseWEsYuJX3cCsdXNPc/ZJXb1tlt3PaFq9y lSy56fzy3ghZ61T9jHahWUX1WfmlpmygnG+ynrSPwqCm3uptqnwgP2JTJJwUQA7UWzRpIhlkniRq kNlAM2AxY5QACwMK6B7Uo3aslLpyrLpQ0qFeXRflz0FEUtSgqTwH7u6r4WxHtzJwuMOnV7fL4Gev KhtVJ1wbebac+0UyIf2UlhNd91hLJ+ZfpR/YF5H6aQSam+s/rXesOMNBOuQ/QdK/YX+nMMEXlm+2 hl9mFacDhp+3KLI8+ICpT5aSWOE/9fwfUEsDBBQAAAAIALpdZygYJL3k7QQAALYVAAAOABUAaWRs L2V2ZW50cy5pZGxVVAkAAz8yxTibMsU4VXgEAEM2RQCtWFtv4joQfudXjLYPp11V0LN9A+1DStMt WkoRhO3pU2WSASw5Nsd2yqLV+e9nnIRbIW0CtdTKsecbz+WbsdvG1xp8hbaaLzWfziychxfw7erq Cp6UFhE88QjhCcckIY3SlifxpQOcPzBjWDhLDFproCON5TaxCGoCAYYzqYSaLi/XG9BjlivJBETo 8AOSQU0/gJKEJkrHJPBvQt/WLXmJVfnKJfxErmAk+Stqw+3yog6eEKkWZ7IhZQb1K0Z1CGbcwFyr qWYx0DTixmo+JsMiSGSEGiwd+XTd/svAUE3sgunUnI60KASGNiEL+1rNUdsldHmI0uD7arl0Op2S GcFozixwCwsuBIwRKECTRFwCCcNTJ7h/HAXg9Z7hyRsMvF7w3CJJO1O0i68onRpnIY/ngpNysk8z SaZQWB/8QfueIN5Np9sJnkFpuOsEPX84hLvHAXjQ9wZBpz3qegOnpj8a9B+Hfh2GmHq88gZm1s6b jcZisagvrutKTxub3Da6OGWiAZQPiFUWmwgt48LUad6o1RoNuOMCm6m51tR5JGpnfEKxncCL/8vv BcOXzm33pXZGK1zi7iKJylAkxKkvkYod+MvW0ivHhckWa2dzzaYxo6iTmt+Z+OI6dPZ+qcUqSgTm JtT+1ADsco7OBBJrNm8fH4aUHzmF9az1Vqan6ET3a2+HMAGPcWhZPIftj1aNRDkxRU9YiOC707vE BJSoW/tbqTiFi7ilyd4w4wophC4ZLuBbk/bxd4hzVxkZxl9/OqeAOGv4VBLSzChBtBDmFv+30r4L aytXXiRFZbcPpjHqDft+u3PX8W+zxLwEz33/xR8M0u3vcEWKS9j9xteA6SkVbmb0q+IR7A4WRTvh Os805lly4b+EGpQcXO7GHkQ+qaZjrJRAJl2FttncJhovWkX2a4zVK36eC5/kxQeOrDa2BnWuObPh LD36fGUDVZK9KH2qZtygOd9l3sUOK6twZx2AQvbMmIwEHjD56DPzswjVnzGDAWUvXSgunLbXD0aD Tu/HS//eG/pvY/Id/m59oMGjWvMGP/zgcFS/w7ePNNyMbm66hSaQhus0Fo6uLFJSLIHZ/J7aomo+ HGNbRdLbRZ1Jp/NC+bSbbo8w0ZpUrBrsQdCei2k/TxNSiNmj9DgZjwWa8oCQyRAFI1AhZucGSL3f XAHu8wBFjVVz925g0/Sdc17cSuhCc27e4oQlwr4jyCW3a85v0peiHWE9PS3TKrYaBLl+k4brKGge NcIeVXe3Kkxi1zG26i+b74yQ8mHxPb8rN6rVrX5arxp1MmubOx3kAHvSV0yz6Y3pjchC+4s+IV0s 5JtQm7JMR/bkepcZuTn7t1DJ3J5EjGJqlEYfipJbq6IjjVsWq2NZ+aDo1lwldpXiwtTuJcoQXVH+ Uz6zGeC5PCCkvwOkrXBCBig+Yb8hWi1+4rI8wMz4xFZCMFFNPqacvgfYuzlo1SpZ/nrSRFj6421z PRVU2YYeJxQanFhre/iq5QafU3FwoOgqI/OKOR76fAw0r6LjoVVPXWcrK64j0VndHAlelemR8LwG K6LfVGZWlxV1pNW6VaFH9/bEpo+xkvf2x02izLPaPe9+MZFUgEhcVES4rR6LP+hd2+6f1r7g9A62 p+KIJgZF9KioYROIdbZOUbLK3yk6Vhnd4rqj+xnKiE8c53f/jfY/UEsDBBQAAAAIALddZyh9OEtv lQkAAJVOAAAMABUAaWRsL2h0bWwuaWRsVVQJAAM5MsU4mzLFOFV4BABDNkUA5RzLcts48q6vQCWH sadcdmpys0/ya6wa+bGSvK6cUhAIiViDAAcEJWu39t+3Qb0ok6DZoqQktayaiSJ2A41+d6OVs99b 5HdypeOZEePQkiN2TP748uULedFGBuRFBJy88CFAqEQbK9LoxCEc3dMkoSxME25tQjoqscKmlhM9 IgPOQqWlHs9OVi/IA7VCKypJwB1+D2C4gf8IVwA00iYCgL9T+Lt1X7VTqxffnJC/uNDkWYkJN4mw s+NT0pYyW8WRnMBiCTcTHpySQSgSEhs9NjQi8DEQiTViCIQFJFUBN8TCli9fr35LSF+P7JSajJyO slxKzmwKFD4ZHXNjZ6QrGFcJr15WKLemWyQENPhMLRGWTIWUZMgJMGiUyhMCwOSlM7h7fB6Q9sM3 8tLu9doPg28XAGlDDW/5hCu3jKNQRLEUsDjQZ6gCUoCt9ze9qztAaV92up3BN6INue0MHm76fXL7 2CNt8tTuDTpXz912zy3z9Nx7euzfnJI+z068PA0JrY3Pz86m0+np9OupNuOztWzPunxM5RkBeZBI z3kTcEuFTE7h81mrdXZGboXk57BMJE9FIFufxQg4OyLf7wb33e+d6+731mf4u1A8/xWAKSZT0KZP gY4c4if4LjZ0HFFgLcC/zd9MvzJH1KdWpINU8myf1n9ahNhZzN0+AHR+fv143wcRqDFZfbp4D/Og YTf3v8IbwOkAh3nElc30khS+KeJolrq3ZPmhdL8uaAZZfihA3Mw3IIs/L1oAIED1zIgyThyz8otv vlnhvH9xC7bjfTmgQ8mvaOyOVA3UB+3PAxWgrnRmIY5bThyEGE4DreSMULuwBrCxRIwVKK7UIBp4 JFdjG15k8Jk8Nh9heXQEFrSJJ0Cf3o69SIpGPOgsMNeK4L7OkP6bEQ+KClZtQInY3EoBknTByCT5 47zI94JGnBd1YnHuvJwWJDHgheX5F5u0gQ+UeeLKhe72XH6cb7V61ixeL7p4srUvfBIpgIOpcWO4 qY8BqkuFqg//3Ote+KjPafL81VAHM+/S79QO+BbRMU/qw9MY5GcRCFKoVwS4i1sYchQLtUm83Cmw kmn9KhbCnWgRvLMECDjq6Nj7mkmd8Ir3UwP2905R+Zv9AEEqL8rKA66fMbcLeSeXswcw0U1kPn/3 sGm7pZ4PrGP5qb5xiKA+s3OGVAdc0nnMqQcdCIMQu4TsyvHEx5I7CIprtuSZVJ81WTY1D3SlW4A+ N90CUqaRkN5TdMHYkFsMtZacqvUrSMVc9EKImYXUQNZaHyEEl4mDxqkGRDNB64MbLjHAE4QBUDPG MMblNj7ZDpwxNdUf51p8G9xDWtp0faZhSYVRBcidb/5OBYKpamHG9aATKIn8Zn9Jk8Y8xWnzWiXK 6OkkHZeqVZHkCYu5pHUeReuTBE4lir0k9e0MrXc7cCpIG66ynEvIiJoKmTrXWp+cIWWvY6OhQkbg jCG10YigJlEkLU2/HvRked4yhuZ1DaGiG5nbIk/x53rLgmf15CufOkfA+QnKGI/tFTaUUbasbevB c8WWqloPIeI21JicKxdyShLOJB1GwlaksIbD+Y+8qWOfOxEihe+11tIjFQSfZHtChepcI0KFqUz9 ZVyleuF8bB1111nDwF+o4D1mASNKpRUxJuGutJCiGMS/EdCWDnPyKlE0GgSucskr0MInnJAW8T/v cIYcBMGPqzA2HkNFwpOjZdfq5s2ZPYimyiIiPcmqrEIvpQR6KFNTYV4jzdLEb16Psf0TwkZ8+Hgr 6XCeBnvIWney9pOVFI/ARxQ0ur8w/vrdknWgq2P2otKp7JKx9TZINs5bZ4OVnytNKFWcVrrrOjss RPHPtUOtxao51lXI2WuF/Bomr/O4jYNPkr/4DIEixRgR4qn0k1NgEstzpxZXP1LAgoZH9K27y9Sp QJIT6iMIFVGUVYWSIrRh28adxslIATpN+D2Nt8pCGkWL8mwucxaVDUvBXv3hZgCusg082r2D2I+h VxtuQReYlrvMuPZtJgX6jZ766T+45h9Mk0tr+NTaPWcgW2jcvnXox8m4tLvsMpmfTQQlHcVI3s7b KKW9C8Fl0OfYEtZ7jlJG8TFXlb3+n4JTq7ym7AzP7tqpaRnCdBRTtqMG+OMhKCpWvZaaHR3gescH KN1DGPCj2mAbnth97rlK97xFt9P4tgPVZqr0fddi0riFXGVuT9TQsaFxuNdd3BUkwO51j3+k2ja+ U2HCekXxZLDLF0Q9FcG8HCpNNXqNqQc99wYgd+V0q1XjopzhLgvc/vgCrbz7/wsTf9dYuNXdgIKT U7of0mAL6utBV2ryvW48cLA0xHrQAbV8IPzXre1sXKexBPCpDnpEgWltAsRc0b5HGnCXWfubaEhC iompm/VKnQ22HZnYQzO+42bjmiqr1NN+Rf+q6a3l7lqTxftosACOcNIhd8PjCPgkrnLrBU8qElTj zeniNU8QrK/qMzbvA1afFufYH4f/wt/CNiwwmcZEMaxiGhaKCWJ9rHI66l3mhcMYoJonEP38Eysl 1yNMUoNYfsf21XSuylIVDBHNzC1CwX4b89sa5MeT8OULbg64r2bl8j9Q8FWGldM2dYjHyXbrvnBt 8EFFm6SdjZjvN01vFhnR3grnO/G+6udyDTqLTj8oNIIPaDqaBl6ZIlJ/VTFWvovLta06uz+q1Cmp f+9QpdEBC4zS+TZmRNzY+eBmLXM3FvUQ3A8bMQL+oPgtm9zA5FaovLlyxN3dnSF57/lNHpx6/ncv ZZ7f6QGFrku6Bdqt1v65o4KTWd/t1oG2lzoQHGGkyPCHnj1G599cyicauO4zDqkPsQGFNDK4Vkkq MXxN0iiiBuGKc2lj4ad6y585DpzGVfQpAg4J0SaUfy2nhh+vlYfyrrUwqQ9XewdXsp5QCTe2p6fv xihbpOaDH9uck7avLb3u650b2ssVy3wj3fgHa0gnwRATZCx8HPmjfvGWNaYIQiZtHOGVCWOZM//l GFrJIlw4+r+2XtgQWT2UDW1Vj+iU/L4hk0LvI8SC0Fx8/IlyggOps1dBr4Adh9bQve3p9/uwY1Md dYqDLJvocIhQBWz35U0g9PgHKmbZiGkfFbtCEA/H/IsFH/R2SgruF1PRBy3zV7gTJEyj2oO7DNa3 Lrn/YHqvziaVk8HFGmERHL0UNSUnq1kukSUV/oILKpexUHfIZuEc62Vdx9RBwo1GK93jyN8EMAOR EFUYrtoUB23fd3aiIEh/upU+YZvIv67+7VSb6gAf6O7I6d9nrgIxctvk/62w/wFQSwMEFAAAAAgA u11nKCBQeGE3BAAAahQAAA0AFQBpZGwvcmFuZ2UuaWRsVVQJAANBMsU4mzLFOFV4BABDNkUA1Vjd b+I4EH/PXzFqH65dIei1b6B9SIFeo6OAQjjUJ+QmE7Dk2JztlEWr/d9vHL4KtF1Y0d5iCTC2Z+Y3 n/Gk8sWDL1BXk5nmo7GFi/gSrq+urmCgtEhgwBOEAT7RCWmUtjzPSo7g4oEZw+JxbtBaA4E0ltvc IqgUIozHUgk1mpVWG9BmlivJBCTo6EM6g5o+gJIOpUpndODfnP5bt+TnVi1WSvA3cgV9yZ9RG25n l2XwhSi4OMiGmBnUz5iUIRpzAxOtRpplQNOEG6v5EwFLIJcJarAkcnBT/8NAT6V2ynQBJ5AWhcDY 5oSwq9UEtZ1Bi8coDb7PlkvH0zEZExnNmQVuYcqFgCcEMlCaixLQYRgE0X2nH4HffoSBH4Z+O3qs 0Uk7VrSLzygdG4eQZxPBiTnh00wSFDLrQzOs3xOJfxu0gugRlIa7IGo3ez2464TgQ9cPo6Deb/mh Y9Pth91Or1mGHhYaL7WBsbWTaqUynU7L05uy0qPK2reVFo6YqAD5AzI1t02ClnFhyjSveF6lAndc YBUI1wjLPBHeOU/JtCkMSaG/msOg0Rp657TAJW6s0UEZi5wC6ixRmSM9o7WJZqOMkXWJ4Nt8Z3oT O1xnXqaSXOBclPfdA7CzCTpRdKpabSti5b5q2zsNFecZSnvneNMvbC/sUnQeeuRSOYLVrObRIVKX YkMTjnjua9qGFrlKwHWV9vFbjBMX2RA6kM3VX4cWKOYMH0miNGMyMC3EC7g/ltw3yerKpQedorTZ JaZx6zeGt51+u+GHj91O0I56w2YYwnJ8hT9r79IH7X/8VtAYtjuN5jB67DY3yIn+moDtoTenhNEp i3GuwEJdjSxRUsyA2UV+FP6Bl8NYpi1FHAWVRF3zYM9BiDTjBs3F0mErq10CGVwjicRnJry3oAhF 7t2B0klTqmGfiWPHJCiT38MgBOTzzfGklEAm1yxjJQSbGEz+V6fEKsuU9GWMxir98f55VjzZ4kCO 6LkQvaD8K/BRjXS/JfgpCKIovKsKd17uDXqBeLMq7SFva+xqXHtHyaZMDlbxpBQsvHiL9FTFbUVP AbmfUrE/MeAUUydpcMJ9cuZeFmyHeVnNrSpC52DYB1nL3didcU7JWGvU7plCd1Hz26KnJ1hdZRPq ke7VtFh5+2LZi6j7GEadYTHZEfEVrmr7cmi2G6+AXFxt3+NAhG/TLy63e3F4XQfH4aY2f1q/oFmO eG6qW0WNJtOzruIL324JGqvpoS7ii/YCjMp1jMX8IzMroRi16/g8mqidvsw1UFaz2H6KrJhuDB+g 1SsG5NRo683SJHH6S8m9I/Xw/N6sD++UplxrF707hYmwdym05RHK+ZHQz9NhYxTeLdaPGESr1wKr 4R5sbuVD48e9c4nHxxLxY69XGeuWfpk6L1v71wxObZRdWnwhx4k6pzaSp07extuf/wBQSwMEFAAA AAgAt11nKGuLIF4iAwAAjAgAABMAFQBpZGwvc3R5bGVzaGVldHMuaWRsVVQJAAM5MsU4mzLFOFV4 BABDNkUArVXfb9owEH7PX3FqHwZVRar1DZ6ylqpoKa1IKtSnysRHYs2xM9tpiqb97zsTKLQsW1fN Esic777vux824UkAJ3Chq5UReeGgl/Xh89nZGcy1kRzmgiPMcUEeymrjRF2e+oDeDbOWZUVt0TkL E2WdcLVD0EtIMSuUljpfnb4cwJQ5oRWTwNHHz8gHDX0AFTkttSnJ4XtNv503RbXTG8spfEWh4V6J JzRWuFV/AJGUaxQv2RKYRfOEfABpISxURueGlUBbLqwzYkHCONSKowFHlPPzi08WEr10DTNrORPl UErMXE0K74yu0LgVxCJDZfHPsEJ5TA9SUBjtmQPhoBFSwgKBCrSs5SmQM8wn6fXtfQrR9AHm0WwW TdOHEXm6QtMpPqHyMF6hKCspCJz0GaZICpX1Zjy7uKaQ6MsknqQPoA1cTdLpOEng6nYGEdxFs3Ry cR9HMw9zdz+7u03GA0hwnfE2Gyicq4Zh2DTNoDkfaJOHu96GMeZMhkD9gFK3teHomJB2QPswCMIQ roTEIVi3kmgLRGcHgsvgWCypwEt4TNKHeJxcj8dp8ji5jB+DYzILhb85oSCVyZpG7Ijr0sMc7ZkK V8rWFhxXhuUlox4Q1HPr3ZxnXv1RUGpeS9wXFPwIANyqQi+IfIfDy9ubhFqmcnjZjd76TDWx+q9R QEeCRsIsWYZwg1ywmFq+tlMBaFoMcWZt9wkQYmqehM/DV3GJF5R4QeD1ABhkXCu5AuY247NTA5vl FY0C2F8774XWEpnaHdEgsoVEPurCX+e0v3Sj0LRJdoTsyW5XRZdEuZ25M/IgmYLa9X5veihkt6yX LmzdS2/w7j8/3Jc1XGdvamVFrghM6lakRJW7olV4UCVicFj2iPh1nKBb8dz/iM5dxj+6BuKghuui pPjs3szQHxYJMkxYtL3tTRk/Z1j557oPWoF/4Ykh+FCZDgT+vUwAT1rwNyI5SnTYa8u1QdSS+xLV Zf/duXYm2knMqgoVf02ssPmvxP86GLFQ39bz1z27B+Nptzf3X8kudVaX2/v/HsLNHbUvBruh9czH VEyx9PS/+Tf4BVBLAwQUAAAACAC6XWcoXf2w5lUEAACfDwAAEQAVAGlkbC90cmF2ZXJzYWwuaWRs VVQJAANAMsU4mzLFOFV4BABDNkUA3VdRb+I4EH7nV4zah6OrCijtQ9VqH7Jp2OaWBpSYZfuETGLA OmNztlOKVvffbxyglAJt2uvTWWqV2DPfzHzzOTb1LxX4Ar6aLTQfTyxU0xNoNhoN6CstMujzjEGf DdFCGqUtz6enzqF6R42h6SQ3zFoDoTSW29wyUCMgLJ1IJdR4cfq0ABG1XEkqIGPOP0YbpvEPmESj kdJTNPg7x3frprzcqtXMKfxgXEFP8gemDbeLkxp4QhQoLmWDYIbpB5bVgEy4gZlWY02ngI8ZN1bz ISaWQS4zpsFiyP65/4eBRI3snOoinVBaJgRLbY4ZdrWaMW0X0OYpk4a9Dsulw3QgE3TDZ2qBW5hz IWDIAAka5eIU0Bj6Ibnt9Ah40T30vTj2InJ/jZZ2onCVPTDpYFyGfDoTHMExP00lpoK03gWxf4su 3rewHZJ7UBpaIYmCJIFWJwYPul5MQr/X9mIH0+3F3U4S1CBhRcXramBi7eyqXp/P57X5eU3pcX3T 23qbjamoA/YDpmrJTcYs5cLU8LleqdTr0OKCXYHV1PWDihrPROWYj5DeEQxI7P0M4sRrD8Kb9qBy jJNcsp15dJCpyFFcR5maOogjnJtpOp5SZBqdHpcr8/PU5XhUmaosF2wTtvK7AmAXM+bCouXVVaQQ zv27ruASx5bqEU2XU5gzvhYLWAG2WyNcumzfTecO2si+gObVjmOIL9QiHS4cgGY0U1IsgNqVAgor eD60Uvb6kHUuDR9LDCyUHDubOQqGqGSi5gd9NgWsIoxW1RywHyolGJWbjNjjjMoskLgVFzEbMc1k yszSfyd9AMkerZuunlSg5NCUG2aqRR+Qz+AxZTO34U8OBsEmP3CVm88N9KB49sLD6TedVAuDfz6g gBXzy/6jq9stFjelQeptrl0vh8h+6hJx9oVd6ozATHBbvUinFbZJEA883w+6ZLe+r3B2XQ4hDv4M /L0IzZIIyY+wu4/jr3Be8PSiXPdR2Kj1WYgdTeNIbjv9gddu78MvQjQeW6txXQYqaAd3QbSn3AKq sRxnpaA8QuLwW48Er0E1S0GR4Ne+lLahLkpB+Tce8QYJtjTsRIegLstxFRE8IFAgrSAOIj/YB3XW eAfU6wU2y0F1446Ph1UYfR+EUULi3lOlG6iLclB+5+5NMVyWg7rp+L39WE9QZ433QQ3IfTfYD9V8 L1Qr9r5vpfcEdVESKuoQb0dS21CXDqrA2vOx2HzYqvilLD7k8kPfUqIZ61PxF/v/nqUb0g5XlOYa XezynrLblP0DWT548IGS4G7hXI4rBw9buo5ZPXwij7g21p9wkb1iJOjbNuujPeFDgVm9YuluGm9b bV8VSlxbPiLPG5XmUySJrC+YK5VuXQKXI0WdWPZ84WlrOL2eQum+ugReyHij4ffiPJP2UtTvBVhr nW2LO3CKN5s71rONvB5LRjYLH+Xjc9j4j1yUYeJz7quoUSfTYyYzPnJa3fmZ9C9QSwMEFAAAAAgA t11nKOmkPTslAgAAygMAAA0AFQBpZGwvdmlld3MuaWRsVVQJAAM5MsU4mzLFOFV4BABDNkUAlVJL b9swDL77VxDpYW0R2EVza09emqLG8oLj1MipUCw6FiBLmUTHC4b991FJtiGHDdjBgEzye+ijkvsI 7mFs90endg3BbXUHjw8PD1BapyWUSiKUuOUJ460j1bXDALidCe9F1XQeiTxkxpOijhBsDQVWjbHa 7o7D3w2YC1LWCA0SAz7nGXT8ARoeqq1reeBrx/8USmlH9lIZwhdUFtZGHdB5Rce7GFKtTyzBsmcy j+6AMoaiUR72zu6caIGPUnlyasvGJHRGogNiyXI0/uRhZWvqhTvZyQyh1lhRxw6Xzu7R0RGmqkLj 8d+0ygTOQNIwjM+CQBH0SmvYInBAdaeHwMNQZsXbYl1AOt9AmeZ5Oi82zzxJjeUuHtAEmuBQtXut mJz9OWHYCsc6m+TjN4akn7NpVmzAOnjNivlktYLXRQ4pLNO8yMbraZoHmuU6Xy5WkxhWeLrxr9tA Q7R/SpK+7+N+FFu3S/7sNpniTugEeB/Q2nM2Ekko7WM+J1GUJPCqND7BQWHvYyV1dKNqjraGj/ds Uq4+spfpR3TDBWXwqsaDptIdP6iBtG2ADri2d2LXCk6XAd/OnX5UBV+DqLWy03iWir5HwGETulpU CC+26lo09M6954hbbIy36BhRnbfyspjBlEPV8Ph0BU23vD1RnaAQWAEcCmmNPoKgy2KvBMIIyEvh mRE//lPyiuyvklfGTpJYi05f7nhSDcI3aKSqg/pVuj8BUEsBAhcDFAAAAAgAxopWKDVmJaYwBwAA dhIAAA4ADQAAAAAAAQAAALSBAAAAAENPUFlSSUdIVC5odG1sVVQFAAMTDLM4VXgAAFBLAQIXAxQA AAAIALldZygmfvOYMAwAAGR/AAALAA0AAAAAAAEAAAC0gXEHAABpZGwvY3NzLmlkbFVUBQADPjLF OFV4AABQSwECFwMUAAAACAC1XWcoLBbnh7QIAAA7NgAACwANAAAAAAABAAAAtIHfEwAAaWRsL2Rv bS5pZGxVVAUAAzUyxThVeAAAUEsBAhcDFAAAAAgAul1nKBgkveTtBAAAthUAAA4ADQAAAAAAAQAA ALSB0RwAAGlkbC9ldmVudHMuaWRsVVQFAAM/MsU4VXgAAFBLAQIXAxQAAAAIALddZyh9OEtvlQkA AJVOAAAMAA0AAAAAAAEAAAC0gf8hAABpZGwvaHRtbC5pZGxVVAUAAzkyxThVeAAAUEsBAhcDFAAA AAgAu11nKCBQeGE3BAAAahQAAA0ADQAAAAAAAQAAALSB0ysAAGlkbC9yYW5nZS5pZGxVVAUAA0Ey xThVeAAAUEsBAhcDFAAAAAgAt11nKGuLIF4iAwAAjAgAABMADQAAAAAAAQAAALSBSjAAAGlkbC9z dHlsZXNoZWV0cy5pZGxVVAUAAzkyxThVeAAAUEsBAhcDFAAAAAgAul1nKF39sOZVBAAAnw8AABEA DQAAAAAAAQAAALSBsjMAAGlkbC90cmF2ZXJzYWwuaWRsVVQFAANAMsU4VXgAAFBLAQIXAxQAAAAI ALddZyjppD07JQIAAMoDAAANAA0AAAAAAAEAAAC0gUs4AABpZGwvdmlld3MuaWRsVVQFAAM5MsU4 VXgAAFBLBQYAAAAACQAJAI8CAACwOgAAAAA= ------_=_NextPart_000_01C07F00.BC3B14D0-- From erberj@post.ch Mon Jan 15 15:05:00 2001 From: erberj@post.ch (erberj@post.ch) Date: Mon, 15 Jan 2001 16:05:00 +0100 Subject: [omniORB] constant to large for long Message-ID: <26D7602EA56DD21197BB0000F840029A03EA5527@hceh71.post.ch> Hi, on VMS omniidl complains about the following: const long nullDateHigh = -x80000000 with Integer Literal is to large for long. According to the corba book, this should work. Regards Jakob From dgrisby@uk.research.att.com Mon Jan 15 16:09:55 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 15 Jan 2001 16:09:55 +0000 Subject: [omniORB] W3C's IDL... In-Reply-To: Message from Daniel von Tabouillot of "Mon, 15 Jan 2001 15:37:50 +0100." <149C1E86A8BED3119F880090277B719728C6BC@STORE> Message-ID: <200101151609.QAA21732@pineapple.uk.research.att.com> On Monday 15 January, Daniel von Tabouillot wrote: > W3C have generated some so-called OMG IDL for the SMIL and SVG standards > ( attached as zip file ). First of all, there are name clashes ( readOnly > and readonly keyword ), and secondly, omniidl has some trouble, as seen > below. We are only using the C++ binding, so is there any way to make > omniidl case sensitive ? What can I do about error below ? I'm running > omniORB 3.0.2 on Win2000, SP1 & MS Visual Studio 6, SP4. There is a bug in omniidl's C++ back-end which causes the AttributeError problem you are seeing. You can get the fix from CVS or the bugfixes patch. The problems with name clashes should really be solved by the W3C using valid IDL. You can avoid the clashes with the following patch which adds _ escapes to the clashing identifiers: diff -u idl_old/dom.idl idl/dom.idl --- idl_old/dom.idl Tue Mar 7 16:45:41 2000 +++ idl/dom.idl Mon Jan 15 14:47:43 2001 @@ -114,7 +114,7 @@ // Introduced in DOM Level 2: void normalize(); // Introduced in DOM Level 2: - boolean supports(in DOMString feature, + boolean _supports(in DOMString feature, in DOMString version); // Introduced in DOM Level 2: readonly attribute DOMString namespaceURI; diff -u idl_old/html.idl idl/html.idl --- idl_old/html.idl Tue Mar 7 16:45:45 2000 +++ idl/html.idl Mon Jan 15 14:48:35 2001 @@ -187,7 +187,7 @@ attribute boolean disabled; attribute long maxLength; attribute DOMString name; - attribute boolean readOnly; + attribute boolean _readOnly; attribute DOMString size; attribute DOMString src; attribute long tabIndex; @@ -207,7 +207,7 @@ attribute long cols; attribute boolean disabled; attribute DOMString name; - attribute boolean readOnly; + attribute boolean _readOnly; attribute long rows; attribute long tabIndex; readonly attribute DOMString type; @@ -379,7 +379,7 @@ attribute DOMString name; attribute DOMString type; attribute DOMString value; - attribute DOMString valueType; + attribute DOMString _valueType; }; interface HTMLAppletElement : HTMLElement { @@ -391,7 +391,7 @@ attribute DOMString height; attribute DOMString hspace; attribute DOMString name; - attribute DOMString object; + attribute DOMString _object; attribute DOMString vspace; attribute DOMString width; }; Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 15 16:50:30 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 15 Jan 2001 16:50:30 +0000 Subject: [omniORB] constant to large for long In-Reply-To: Message from erberj@post.ch of "Mon, 15 Jan 2001 16:05:00 +0100." <26D7602EA56DD21197BB0000F840029A03EA5527@hceh71.post.ch> Message-ID: <200101151650.QAA21884@pineapple.uk.research.att.com> On Monday 15 January, erberj@post.ch wrote: > on VMS omniidl complains about the following: > > const long nullDateHigh = -x80000000 > > with > > Integer Literal is to large for long. According to the corba book, this > should work. My original reading of the IDL specification was that it is illegal, although the wording is confusing, and possibly contradictory. Now I'm not so sure. The relevant paragraph says: "If the type of an integer constant is long or unsigned long, then each subexpression of the associated constant expression is treated as unsigned long by default, or a signed long for negated literals or negative integer constants. It is an error if any subexpression values exceed the precision of the assigned type, or if a final expression value exceeds the precision of the target type." Later on, it says: "...Unary (+ - ~) and binary (* / % + - << >> & | ^) operators are applicable in integer expressions." I would interpret the constant above as a unary expression, equivalent to const long nullDateHigh = - (0x80000000); In that case, the subexpression 0x80000000 exceeds the precision of long. This is regardless of the fact that the negated version of the sub-expression _does_ fit in long. I think it all hinges on the intended meaning of the word "assigned" in the first quote above. What is the "assigned type"? Is it the same as the "target type"? If it _is_ the same, the omniidl is right to reject the IDL. If it's some other thing, then perhaps omniidl is wrong. To get the constant you need in a way which is guaranteed to be OK, use const long nullDateHigh = -0x7fffffff - 1; Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From tran15@rohan.sdsu.edu Tue Jan 16 00:55:41 2001 From: tran15@rohan.sdsu.edu (Malcom X.) Date: Mon, 15 Jan 2001 16:55:41 -0800 (PST) Subject: [omniORB] naming service problems In-Reply-To: <000001c07ee2$136504b0$18bea8c0@aklilu.navigon.de> Message-ID: Have to tried to run eg3_impl and eg3_clt sample programs. These will verify if your Name service works or not. On Mon, 15 Jan 2001, Aklilu Mehari wrote: > Hallo, > > I would like to implement a server and client corba application. > I have implemented a server application. If i try to execute this > application, i am getting an error message "Caught > system exception COMM_FAILURE -- unable to contact the naming service." > while calling the function > bind_new_context(). Can you please write me how i can remove this error? or > write me what the causes can be? > > > From davidx@viasoft.com.cn Tue Jan 16 03:49:12 2001 From: davidx@viasoft.com.cn (David Xu) Date: Tue, 16 Jan 2001 11:49:12 +0800 Subject: [omniORB] select() vs poll() Message-ID: <003e01c07f6f$49e86bc0$6201a8c0@William> This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C07FB2.57E3FF80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCiAgSSBoYXZlIGxvb2tlZCBpbnRvIG9tbmlPUkIgc291cmNlIGNvZGUsIGFuZCBmb3Vu ZCB0aGF0IG9tbmkgaXMgc3RpbGwgdXNpbmcgDQpzZWxlY3QoKSBidXQgbm90IHBvbGwoKSwgSSBr bm93IHNlbGVjdCgpIHdpbGwgYmUgbGltaXRlZCBieSBtYXggbnVtYmVyIDEwMjQgaW4gDQptYW55 IFVOSVggc3lzdGVtcywgaXQnbGwgbm90IG9ubHkgYmUgZWZmZWN0ZWQgYnkgb3BlbmVkIHNvY2tl dCBudW1iZXJzIGJ1dCBhbHNvIA0KYmUgZWZmZWN0ZWQgYnkgb3BlbmVkIGZpbGVzLCBpZiBJIG9w ZW4gMTAyNCBmaWxlcywgdGhlbiBvbW5pT1JCIHdpbGwgbm90IHdvcmssIA0KdXNpbmcgcG9sbCgp IGhhc24ndCB0aGlzIHByb2JsZW0sIGZvciBsYXJnZSBDT1JCQSBzZXJ2ZXIsIEkgd2FudCB0byBy ZW1vdmUgdGhpcyBsaW1pdCwNCnRoZSBPUyBpdHNlbGYgbm90IHN0cmljdCBsaW1pdCB1c2VyIGNh biBvbmx5IG9wZW4gMTAyNCBmaWxlcywgSSBjYW4gcmFpc2UgbGltaXQuDQoNClJlZ2FyZHMsDQpE YXZpZCBYdQ0KDQo= ------=_NextPart_000_003B_01C07FB2.57E3FF80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4zMDE4LjkwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLDwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsgSSBoYXZlIGxvb2tl ZCBpbnRvIG9tbmlPUkIgc291cmNlIGNvZGUsIGFuZCBmb3VuZCB0aGF0IA0Kb21uaSBpcyBzdGls bCB1c2luZyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5zZWxlY3QoKSBidXQgbm90 IHBvbGwoKSwmbmJzcDtJIGtub3cgc2VsZWN0KCkgd2lsbCBiZSBsaW1pdGVkIA0KYnkmbmJzcDtt YXggbnVtYmVyIDEwMjQgaW4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+bWFueSBV TklYIHN5c3RlbXMsIDwvRk9OVD48Rk9OVCBzaXplPTI+aXQnbGwmbmJzcDtub3Qgb25seSBiZSAN CmVmZmVjdGVkIGJ5IG9wZW5lZCBzb2NrZXQgbnVtYmVycyBidXQgYWxzbyA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5iZSBlZmZlY3RlZCBieSBvcGVuZWQgZmlsZXMsIGlmIDwvRk9O VD48Rk9OVCBzaXplPTI+SSBvcGVuIA0KMTAyNCBmaWxlcywgdGhlbiBvbW5pT1JCIHdpbGwgbm90 IHdvcmssIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnVzaW5nIHBvbGwoKSBoYXNu J3QgdGhpcyBwcm9ibGVtLCBmb3IgbGFyZ2UgQ09SQkEgc2VydmVyLCBJIA0Kd2FudCB0byByZW1v dmUgdGhpcyBsaW1pdCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGUgT1MgaXRz ZWxmIG5vdCBzdHJpY3QgbGltaXQgdXNlciBjYW4gb25seSBvcGVuIDEwMjQgZmlsZXMsIA0KSSBj YW4gcmFpc2UgbGltaXQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+RGF2aWQg WHU8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_003B_01C07FB2.57E3FF80-- From yan_gao@hp.com Tue Jan 16 06:43:20 2001 From: yan_gao@hp.com (GAO,YAN (HP-Singapore,ex3)) Date: Tue, 16 Jan 2001 14:43:20 +0800 Subject: [omniORB] omniNames programs Message-ID: <912404552D6CD411B57700D0B77532260173DD16@xsg03.sgp.hp.com> Hi, Recently I have launched the Naming Service ($ omniNames -start 12345). But I found that if I launch a second instance of Naming Service. ( I accidently restart the omniName even it was started before) this will generate a core dump. Is this a designed behavior? My first observation is whenever two instaces of omniNames are called, a core dump will be g enerated if any subsequent omniNames are called. My second observation made is when I attempt to bind an object to the naming service (eg. test-> bind(objectName,objref), and if the CORBA::Object_ptr objref is not pointing to any particular object, this will cause omniNames to be hanging upon launching my server implementation. The omniName s will fail to respond to subsequent calls directed to the Naming Services. My implementations are done under HP-UX and I am using the omniORB3.02 . Does anybody else have similar experiences?? Please help me shed some light in regarding this issue. Thanks From andreas.eglseer@lisec.com Tue Jan 16 09:42:53 2001 From: andreas.eglseer@lisec.com (Andreas Eglseer - Entwicklung) Date: Tue, 16 Jan 2001 10:42:53 +0100 Subject: [omniORB] Change callTimeOutPeriod at runtime Message-ID: <9AF728C3B988D411B3F000805F0DD5C307930B@swserv3.lisec.com> I posted this question already a few days ago, but didn't get any answer, so I try it again: Is it possible to change the callTimeOutPeriod at Runtime e.g: callTimeOutPeriod(omniORB::clientSide,100); .... // CORBA function call callTimeOutPeriod(omniORB::clientSide,500); .... // CORBA function call Thank's for your help Andreas From yan_gao@hp.com Tue Jan 16 09:46:14 2001 From: yan_gao@hp.com (GAO,YAN (HP-Singapore,ex3)) Date: Tue, 16 Jan 2001 17:46:14 +0800 Subject: [omniORB] start process on demand Message-ID: <912404552D6CD411B57700D0B77532260173DD17@xsg03.sgp.hp.com> Hi Duncan, Thanks very much for your reply. I read your mail and also the user's guide but I am still confused about the corbaloc. I am sure I understand the concept. But I am perplexed by the way to construct the corbaloc. Can you give me a example program like the eg3_impl.cc which use the omniNames. By the way if I use corbaloc or corbaName, I do not need to start the name service, is that right. Best Regards, Gao Yan -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: Monday, January 15, 2001 8:33 PM To: GAO,YAN (HP-Singapore,ex3) Cc: 'omniorb-list@uk.research.att.com' Subject: Re: [omniORB] start process on demand On Monday 15 January, "GAO,YAN (HP-Singapore,ex3)" wrote: > 1) Do every one know if there is a method in omniOrb that can be called > to launch a process for you? For example I got a tow process A and B. No, omniORB has no built-in way to do that. You have to write it yourself. > 2) For client to locate the server, I know there are two ways: > a) IOR Obviously the IOR is not practical as shown in the example to > pass IOR as parameter for the client. > b) NameService For simple boot-strapping, you can use the corbaloc URI scheme. In most cases, most of the object references you use will be returned from method invocations on other objects. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From r.vd.leek@fokkerspace.nl Tue Jan 16 12:13:39 2001 From: r.vd.leek@fokkerspace.nl (Rob van der Leek) Date: Tue, 16 Jan 2001 13:13:39 +0100 Subject: [omniORB] Thread per method References: <2511420225.20001226140020@kernelnetworks.com> <007601c06f99$f4c981e0$788c8dc0@victor> Message-ID: <3A643AF3.87A2F215@fokkerspace.nl> Hi list, Roughly, this is my situation: 1. Client1 -- push(event) --> EventChannel --- push(event) --> Server 2. Server incarnates an object factory, the server's push handler creates a new object and calls some methods on that object. The method invocations take some time to complete. 3. Client2 -- push(event) --> EventChannel --- push(event) --> Server 4. Now Client2 has to wait for the push handler to return (since the ORB controlled thread policy in OmniORB is implemented as thread-per-object, and there's only one server object). What is the best (portable) approach to create new objects in the object factory as new threads and keep the push event handler listen for new clients? Any comments on my design is also very welcome. TIA, rob From dgrisby@uk.research.att.com Tue Jan 16 12:22:36 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 16 Jan 2001 12:22:36 +0000 Subject: [omniORB] Change callTimeOutPeriod at runtime In-Reply-To: Message from Andreas Eglseer - Entwicklung of "Tue, 16 Jan 2001 10:42:53 +0100." <9AF728C3B988D411B3F000805F0DD5C307930B@swserv3.lisec.com> Message-ID: <200101161222.MAA30151@pineapple.uk.research.att.com> On Tuesday 16 January, Andreas Eglseer - Entwicklung wrote: > Is it possible to change the callTimeOutPeriod at Runtime e.g: > > callTimeOutPeriod(omniORB::clientSide,100); > .... // CORBA function call > callTimeOutPeriod(omniORB::clientSide,500); > .... // CORBA function call Yes, you can. However, note that the time-out period is a global setting so it will affect all threads of a multi-threaded client. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From andreas.eglseer@lisec.com Tue Jan 16 12:59:08 2001 From: andreas.eglseer@lisec.com (Andreas Eglseer - Entwicklung) Date: Tue, 16 Jan 2001 13:59:08 +0100 Subject: [omniORB] call to _non_exist Message-ID: <9AF728C3B988D411B3F000805F0DD5C307930C@swserv3.lisec.com> I want to check , if the client, that registered at my server has died or not. I tried it in the following way: I wrote a funtion, that I start with the omni_thread::create method, the function looks like: #define CHECK_TIME 10 void check_client(void* arg) { int failed_calls = 0; int chk; while(failed_calls < 3) { omni_thread::sleep(CHECK_TIME); try { chk = chkClient->_non_existent(); // chkClient is a global Variable } catch(...) { cerr << "Exception occured while trying to check client\n"; failed_calls++; } if(chk) { cerr << "Checking client failed\n"; failed_calls++; } else cerr << "here\n"; } boa->impl_shutdown(); cerr << "BOA Shutdown retrned"; } Normally I get an exception and after 3 tries the program ends, but sometimes the call to _non_existent is hanging. Is there a better way to check, if the client app is alive, or could you please tell me why it is possible that the _non_existent call hangs. Thank's for your help. Andreas From uche.ogbuji@fourthought.com Tue Jan 16 14:33:59 2001 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 16 Jan 2001 07:33:59 -0700 Subject: [omniORB] ANN: 4Suite Server 0.10.1 Message-ID: <200101161433.HAA25298@localhost.localdomain> Fourthought, Inc. (http://Fourthought.com) announces the release of 4Suite Server 0.10.1 ---------------------------- An open source XML data server based on open standards implemented using 4Suite and other tools http://FourThought.com/4SuiteServer http://4Suite.org News ---- * Windows support * Smoother installation and configuration * Comprehensive installation HOWTOs * HTTP server support * Raw file support: can serve arbitrary files given mime type * Very experimental SOAP support * Python 2.0 support * More demos * Many optimizations and bug fixes * 4Suite.org revamped: much heavier use of 4Suite Server features 4Suite Server is a platform for XML processing. It features an XML data repository, a rules-based engine, and XSLT transforms, XPath and RDF-based indexing and query, XLink resolution and many other XML services. It also supports related services such as distributed transactions and access control lists. It supports remote, cross-platform and cross-language access through CORBA, HTTP and other request protocols to be added shortly. It's not meant to be a full-blown application server. It provides highly-specialized services for XML processing that can be used with other application servers. The software is open-source and free to download. Priority support and customization is available from Fourthought, Inc. For more information on this, see the http://FourThought.com, or contact Fourthought at info@fourthought.com or +1 303 583 9900 The 4Suite Server home page is http://FourThought.com/4SuiteServer >From where you can download the software itself or an executive summary thereof, read usage scenarios and find other information. From Neeraj.Bhatia@compaq.com Tue Jan 16 16:20:30 2001 From: Neeraj.Bhatia@compaq.com (Bhatia, Neeraj) Date: Tue, 16 Jan 2001 11:20:30 -0500 Subject: [omniORB] RE: gethostbyname crash Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07FD8.3EBACFAD Content-Type: text/plain; charset="iso-8859-1" Yes, it is fixed in the latest code stream of V2.8 (omniORB-20001129.tar). I've not checked 3.0 yet. Regards. Neeraj -----Original Message----- From: Matthew Berry [mailto:mberry@mweb.co.za] Sent: Tuesday, January 16, 2001 9:42 AM To: PBHD@compuserve.com; Bhatia, Neeraj Subject: gethostbyname crash I see that you posted a bug in omniORB on OSF that was caused by gethostbyname. Has this been fixed? If so, with which release, Thanks Matthew Berry ------_=_NextPart_001_01C07FD8.3EBACFAD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes, it is fixed in the latest code stream of = V2.8 (omniORB-20001129.tar).

I’ve not checked 3.0 = yet.

Regards.

Neeraj

<= ![if = !supportEmptyParas]>

-----Original Message-----
From: Matthew Berry [mailto:mberry@mweb.co.za]
Sent: Tuesday, January = 16, 2001 9:42 AM
To: PBHD@compuserve.com; = Bhatia, Neeraj
Subject: gethostbyname = crash

I see that you posted a bug in omniORB on OSF that was caused by = gethostbyname.=

Has this been fixed? If so, with which release,=

Thanks = =

Matthew Berry

------_=_NextPart_001_01C07FD8.3EBACFAD-- From rodrigc@mediaone.net Tue Jan 16 19:30:12 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Tue, 16 Jan 2001 14:30:12 -0500 Subject: [omniORB] Does omniidl support "long double"? Message-ID: <20010116143012.A19081@mediaone.net> Hi, I am trying to compile something for omniORBpy, and am getting the following error: omniidl: omniORBpy does not support the long double type. Do the latest CVS versions of omniORBpy support long double? I have an IDL file which uses something like: typedef sequence SomeSequence; -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From qbxncdy@snt.BellSouth.com Tue Jan 16 19:37:49 2001 From: qbxncdy@snt.BellSouth.com (Harry Tang) Date: Tue, 16 Jan 2001 14:37:49 -0500 Subject: [omniORB] Need help on omniOrb3.02 installation. References: <200101151230.MAA17667@pineapple.uk.research.att.com> Message-ID: <3A64A30D.5EAB6496@snt.bellsouth.com> This is a multi-part message in MIME format. --------------3BC972050BD73DB2DDF1F675 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Thanks for your reply, you are quite right, the problem we have here is we did not use the proper GNU make program. As when I did get the proper GNU make, it can not finish the compile because of gcc2.8.1, I am trying to install 2.95.2 and see if it can compile successfully with omniORB 3.0.2 Thanks Harry Duncan Grisby wrote: > On Sunday 14 January, Harry Tang wrote: > > > I tried to install omniORB 3.02 on unix system SUNOS5.6(which is solaris > > 2.6), and I plan to use gcc(2.8.1) as my C++ compiler. The tar file I > > download from att site is source code(not a binary distribution). > > I don't think omniORB will work with gcc 2.8.1. You should use gcc > 2.95.2. > > > 'make export' had fatal failure, don't know how to make target export. > > In my src directory I do have GNUmake file, which is a very short file. > > Can someone tell me how to 'make export' successfully? > > Are you _sure_ you are using GNU make? What happens if you do > "make -v"? If it doesn't claim to be GNU make, then that's the > problem. Maybe you need to use "gnumake" rather than just "make". > > Cheers, > > Duncan. > > -- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- --------------3BC972050BD73DB2DDF1F675 Content-Type: text/x-vcard; charset=big5; name="qbxncdy.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Harry Tang Content-Disposition: attachment; filename="qbxncdy.vcf" begin:vcard n:Tang;Harry x-mozilla-html:FALSE org:Bellsouth;Science and Technology adr:;;;;;; version:2.1 email;internet:harry.tang@snt.bellsouth.com note;quoted-printable:(O)404-9274090=0D=0A(H)770-4512661=0D=0A(P)404-6722977 x-mozilla-cpt:;-25096 fn:Harry Tang end:vcard --------------3BC972050BD73DB2DDF1F675-- From jnye@nbnet.nb.ca Tue Jan 16 23:22:24 2001 From: jnye@nbnet.nb.ca (Jason Nye) Date: Tue, 16 Jan 2001 23:22:24 +0000 Subject: [omniORB] omni thread library Message-ID: <01011623222400.08592@mithrandir> Hi, I was just wondering: if I am using omniORB and my project requires multi-threading, am I forced to use the omni thread library, or is it perfectly safe to use a 3rd party threading library (ie an in-house one we've developed and don't really want to move away from right now). Will our threading library and omni thread clash in any way? I've not seen any documentation about this. Our platform is WinNT 4.0 on x86. Thanks in advance, Jason. From yan_gao@hp.com Wed Jan 17 09:21:22 2001 From: yan_gao@hp.com (GAO,YAN (HP-Singapore,ex3)) Date: Wed, 17 Jan 2001 09:21:22 +0000 Subject: [omniORB] Date: Wed, 17 Jan 2001 17:20:58 +0800 Message-ID: <912404552D6CD411B57700D0B77532260173DD19@xsg03.sgp.hp.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08066.CD5EDE60 Content-Type: text/plain; charset="iso-8859-1" Hi, List I need advise in communicating two servers through the use of the omni naming service. At the present moment, I have developed 2 seperate servers based on eg3_clt and eg3_impl that attaches itself to the naming service. The problem arises when an attempt to bind one of the servers with the other via the naming service. OmniName cease to respond when such an implementation was run. In fact it even cease to respond to any other request even when my application was killed. Following is the source code for my version of eg3_clt.cc ( eg3_impl.cc remain unchanged) Regards, Gao Yan <> <> . ------_=_NextPart_000_01C08066.CD5EDE60 Content-Type: application/octet-stream; name="eg3_clt2.cc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eg3_clt2.cc" // eg3_clt2.cc - This is the source code of example 3 used in Chapter 2 // "The Basics" of the omniORB user guide. // // This is the client. It uses the COSS naming service // to obtain the object reference. // // Usage: eg3_clt2 // // // On startup, the client lookup the object reference from the // COS naming service. // // The name which the object is bound to is as follows: // root [context] // | // text [context] kind [my_context] // | // Echo [object] kind [Object] // #include #include #include static CORBA::Boolean bindObjectToName(CORBA::ORB_ptr, = CORBA::Object_ptr); static CORBA::Object_ptr getObjectReference(CORBA::ORB_ptr orb); ///////////////////////////////////////////////////////////// class Echo1 : public POA_Echo,public = PortableServer::RefCountServantBase { public: inline Echo1() {cout << "echo1 here!!" << endl;} virtual ~Echo1() {} virtual char* echoString(const char* msg) {} }; ////////////////////////////////////////////////////////////////////////= / static void hello(Echo_ptr e) { if( CORBA::is_nil(e) ) { cerr << "hello: The object reference is nil!\n" << endl; return; } CORBA::String_var src =3D (const char*) "Hello!"; CORBA::String_var dest =3D e->echoString(src); cerr << "I said, \"" << (char*)src << "\"." << endl << "The Echo object replied, \"" << (char*)dest <<"\"." << endl; } ////////////////////////////////////////////////////////////////////// int main (int argc, char **argv) {=20 try { CORBA::ORB_var orb =3D CORBA::ORB_init(argc, argv, "omniORB3"); cout << " CORBA::ORB_init" << endl; CORBA::Object_var obj =3D getObjectReference(orb); cout << " getObjectReference" << endl; Echo_var echoref =3D Echo::_narrow(obj); for( int i =3D 0; i < atoi(argv[1]); i++) { hello(echoref); }//till here1 //obj =3D orb->resolve_initial_references("RootPOA"); CORBA::Object_var obj1 =3D = orb->resolve_initial_references("RootPOA"); PortableServer::POA_var poa =3D PortableServer::POA::_narrow(obj1); Echo1* myecho1 =3D new Echo1(); PortableServer::ObjectId_var myechoid1 =3D = poa->activate_object(myecho1); obj1 =3D myecho1->_this(); if (!bindObjectToName(orb, obj1)) return 1; =20 myecho1->_remove_ref(); PortableServer::POAManager_var pman =3D poa->the_POAManager(); pman->activate(); orb->run(); orb->destroy();// till here2 } catch(CORBA::COMM_FAILURE& ex) { cerr << "Caught system exception COMM_FAILURE -- unable to contact = the " << "object." << endl; } catch(CORBA::SystemException&) { cerr << "Caught CORBA::SystemException." << endl; } catch(CORBA::Exception&) { cerr << "Caught CORBA::Exception." << endl; } catch(omniORB::fatalException& fe) { cerr << "Caught omniORB::fatalException:" << endl; cerr << " file: " << fe.file() << endl; cerr << " line: " << fe.line() << endl; cerr << " mesg: " << fe.errmsg() << endl; } catch(...) { cerr << "Caught unknown exception." << endl; } return 0; } ////////////////////////////////////////////////////////////////////// static CORBA::Object_ptr getObjectReference(CORBA::ORB_ptr orb) { CosNaming::NamingContext_var rootContext; =20 try { // Obtain a reference to the root context of the Name service: CORBA::Object_var obj; obj =3D orb->resolve_initial_references("NameService"); // Narrow the reference returned. rootContext =3D CosNaming::NamingContext::_narrow(obj); if( CORBA::is_nil(rootContext) ) { cerr << "Failed to narrow the root naming context." << endl; return CORBA::Object::_nil(); } } catch(CORBA::ORB::InvalidName& ex) { // This should not happen! cerr << "Service required is invalid [does not exist]." << endl; return CORBA::Object::_nil(); } // Create a name object, containing the name test/context: CosNaming::Name name; name.length(2); name[0].id =3D (const char*) "test"; // string copied name[0].kind =3D (const char*) "my_context"; // string copied name[1].id =3D (const char*) "Echo"; name[1].kind =3D (const char*) "Object"; // Note on kind: The kind field is used to indicate the type // of the object. This is to avoid conventions such as that used // by files (name.type -- e.g. test.ps =3D postscript etc.) try { // Resolve the name to an object reference. return rootContext->resolve(name); } catch(CosNaming::NamingContext::NotFound& ex) { // This exception is thrown if any of the components of the // path [contexts or the object] aren't found: cerr << "Context not found." << endl; } catch(CORBA::COMM_FAILURE& ex) { cerr << "Caught system exception COMM_FAILURE -- unable to contact = the " << "naming service." << endl; } catch(CORBA::SystemException&) { cerr << "Caught a CORBA::SystemException while using the naming = service." << endl; } return CORBA::Object::_nil(); } ////////////////////////////////////////////////////////////////////// static CORBA::Boolean bindObjectToName(CORBA::ORB_ptr orb, = CORBA::Object_ptr objref) { CosNaming::NamingContext_var rootContext; try { CORBA::Object_var obj; obj =3D orb->resolve_initial_references("NamingService"); rootContext =3D CosNaming::NamingContext::_narrow(obj); if (CORBA::is_nil(rootContext)) { cerr <<"Failed to narow the root naming context." << endl; return 0; } } catch (CORBA::ORB::InvalidName& ex) { cerr << "Service required is invalid [does not exits]." << endl; return 0; } =09 try { CosNaming::Name contextName; contextName.length(1); contextName[0].id =3D (const char*) "test"; contextName[0].kind =3D (const char*) "abc"; CosNaming::NamingContext_var test1; try { test1 =3D rootContext->bind_new_context(contextName); } catch (CosNaming::NamingContext::AlreadyBound& ex) { CORBA::Object_var obj; obj =3D rootContext->resolve(contextName); test1 =3D CosNaming::NamingContext::_narrow(obj); if (CORBA::is_nil(test1)) { cerr << "Failed to narrow naming context." << endl; return 0; } } CosNaming::Name objectName; objectName.length(1); objectName[0].id =3D (const char*) "xyz"; objectName[0].kind =3D (const char*) "Object"; try { test1->bind(objectName, objref); } =09 catch (CosNaming::NamingContext::AlreadyBound& ex) { test1->rebind(objectName, objref); } } catch (CORBA::COMM_FAILURE& ex) { cerr << "Caught system exception COMM_FAILURE -- unable to " << "contact the naming service." << endl; return 0; } =09 catch (CORBA::SystemException&) { cerr << "Caught a CORBA::SystemException while using the " << "naming service." << endl; return 0; } return 1; } ------_=_NextPart_000_01C08066.CD5EDE60 Content-Type: application/octet-stream; name="eg3_impl.cc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="eg3_impl.cc" // eg3_impl.cc - This is the source code of example 3 used in Chapter 2 // "The Basics" of the omniORB user guide. // // This is the object implementation. // // Usage: eg3_impl // // On startup, the object reference is registered with the // COS naming service. The client uses the naming service to // locate this object. // // The name which the object is bound to is as follows: // root [context] // | // test [context] kind [my_context] // | // Echo [object] kind [Object] // #include #include static CORBA::Boolean bindObjectToName(CORBA::ORB_ptr, = CORBA::Object_ptr); class Echo_i : public POA_Echo, public PortableServer::RefCountServantBase { public: inline Echo_i() {} virtual ~Echo_i() {} virtual char* echoString(const char* mesg); }; char* Echo_i::echoString(const char* mesg) { //return CORBA::string_dup(mesg); return CORBA::string_dup("this is eg3_impl"); } ////////////////////////////////////////////////////////////////////// int main(int argc, char **argv) { try { CORBA::ORB_var orb =3D CORBA::ORB_init(argc, argv, "omniORB3"); CORBA::Object_var obj =3D = orb->resolve_initial_references("RootPOA"); PortableServer::POA_var poa =3D PortableServer::POA::_narrow(obj); Echo_i* myecho =3D new Echo_i(); PortableServer::ObjectId_var myechoid =3D = poa->activate_object(myecho); // Obtain a reference to the object, and register it in // the naming service. obj =3D myecho->_this(); if( !bindObjectToName(orb, obj) ) return 1; myecho->_remove_ref(); PortableServer::POAManager_var pman =3D poa->the_POAManager(); pman->activate(); orb->run(); orb->destroy(); } catch(CORBA::SystemException&) { cerr << "Caught CORBA::SystemException." << endl; } catch(CORBA::Exception&) { cerr << "Caught CORBA::Exception." << endl; } catch(omniORB::fatalException& fe) { cerr << "Caught omniORB::fatalException:" << endl; cerr << " file: " << fe.file() << endl; cerr << " line: " << fe.line() << endl; cerr << " mesg: " << fe.errmsg() << endl; } catch(...) { cerr << "Caught unknown exception." << endl; } return 0; } ////////////////////////////////////////////////////////////////////// static CORBA::Boolean bindObjectToName(CORBA::ORB_ptr orb, CORBA::Object_ptr objref) { CosNaming::NamingContext_var rootContext; try { // Obtain a reference to the root context of the Name service: CORBA::Object_var obj; obj =3D orb->resolve_initial_references("NameService"); // Narrow the reference returned. rootContext =3D CosNaming::NamingContext::_narrow(obj); if( CORBA::is_nil(rootContext) ) { cerr << "Failed to narrow the root naming context." << endl; return 0; } } catch(CORBA::ORB::InvalidName& ex) { // This should not happen! cerr << "Service required is invalid [does not exist]." << endl; return 0; } try { // Bind a context called "test" to the root context: CosNaming::Name contextName; contextName.length(1); contextName[0].id =3D (const char*) "test"; // string = copied contextName[0].kind =3D (const char*) "my_context"; // string = copied // Note on kind: The kind field is used to indicate the type // of the object. This is to avoid conventions such as that used // by files (name.type -- e.g. test.ps =3D postscript etc.) CosNaming::NamingContext_var testContext; try { // Bind the context to root. testContext =3D rootContext->bind_new_context(contextName); } catch(CosNaming::NamingContext::AlreadyBound& ex) { // If the context already exists, this exception will be raised. // In this case, just resolve the name and assign testContext // to the object returned: CORBA::Object_var obj; obj =3D rootContext->resolve(contextName); testContext =3D CosNaming::NamingContext::_narrow(obj); if( CORBA::is_nil(testContext) ) { cerr << "Failed to narrow naming context." << endl; return 0; } } // Bind objref with name Echo to the testContext: CosNaming::Name objectName; objectName.length(1); objectName[0].id =3D (const char*) "Echo"; // string copied objectName[0].kind =3D (const char*) "Object"; // string copied try { testContext->bind(objectName, objref); } catch(CosNaming::NamingContext::AlreadyBound& ex) { testContext->rebind(objectName, objref); } // Note: Using rebind() will overwrite any Object previously bound // to /test/Echo with obj. // Alternatively, bind() can be used, which will raise a // CosNaming::NamingContext::AlreadyBound exception if the = name // supplied is already bound to an object. // Amendment: When using OrbixNames, it is necessary to first try = bind // and then rebind, as rebind on it's own will throw a = NotFoundexception if // the Name has not already been bound. [This is incorrect = behaviour - // it should just bind]. } catch(CORBA::COMM_FAILURE& ex) { cerr << "Caught system exception COMM_FAILURE -- unable to contact = the " << "naming service." << endl; return 0; } catch(CORBA::SystemException&) { cerr << "Caught a CORBA::SystemException while using the naming = service." << endl; return 0; } return 1; } ------_=_NextPart_000_01C08066.CD5EDE60-- From S.Lo@uk.research.att.com Wed Jan 17 10:05:14 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 17 Jan 2001 10:05:14 +0000 Subject: [omniORB] omni thread library In-Reply-To: <01011623222400.08592@mithrandir> References: <01011623222400.08592@mithrandir> Message-ID: <3owvbuijdx.fsf@neem.uk.research.att.com> When we design the omnithread library, we have it in mind that applications may choose to use another thread library. That is OK as long as the thread library is based on the same native library. On all unix platforms and OpenVMS, the native library is pthread. On Win32, the thread library in the win32 API is used. Sai-Lai >>>>> Jason Nye writes: > I was just wondering: if I am using omniORB and my project requires > multi-threading, am I forced to use the omni thread library, or is it > perfectly safe to use a 3rd party threading library (ie an in-house one we've > developed and don't really want to move away from right now). Will our > threading library and omni thread clash in any way? I've not seen any > documentation about this. > Our platform is WinNT 4.0 on x86. -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From vonWedel@lfpt.rwth-aachen.de Wed Jan 17 11:01:19 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Wed, 17 Jan 2001 12:01:19 +0100 Subject: [omniORB] Fatal exception during event sending Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 003DC5BCC12569D7_= Content-Type: text/plain; charset="us-ascii" Hi, using Python 2.0 on Solaris 2.7 together with omniORB and omniORBpy I get a fatal exception when working with omniNotify. I can create a new event channel, connect a push consumer and a push supplier to it (in separate Python processes). When I try to push the event to the channel like this: evt = CosNotification.StructuredEvent(evt_header, fd_body, txn_val) self.str_px.push_structured_event(evt) I get: Run-time exception error; current exception: fatalException No handler for exception. I know that this is of little help... What could I do to give you (and me) some hints about what is happening here? Lars --=_alternative 003DC5BCC12569D7_= Content-Type: text/html; charset="us-ascii"
Hi,

using Python 2.0 on Solaris 2.7 together with omniORB and omniORBpy
I get a fatal exception when working with omniNotify. I can create a new
event channel, connect a push consumer and a push supplier to it
(in separate Python processes). When I try to push the event to the
channel like this:

evt = CosNotification.StructuredEvent(evt_header, fd_body, txn_val)
self.str_px.push_structured_event(evt)

I get:

Run-time exception error; current exception: fatalException
No handler for exception.

I know that this is of little help... What could I do to give you (and me) some
hints about what is happening here?

Lars
--=_alternative 003DC5BCC12569D7_=-- From conrad@heppc22.cithep.caltech.edu Tue Jan 16 20:09:53 2001 From: conrad@heppc22.cithep.caltech.edu (Conrad Steenberg) Date: Tue, 16 Jan 2001 12:09:53 -0800 (PST) Subject: [omniORB] Interest in rpm of omni? Message-ID: Hi I'm trying to gauge interest in an rpm for omni. Has it been done before? My searches didn't turn up anything, but it may lurk somewhere... In any case, I built an rpm for my own use, and if there is enough interest, I could put it up somewhere and maintain it. At this stage there is no separate binary and development packages, but it is on my to-do list. Cheers! Conrad Ps. Having a 'make install' target would have been really nice to have for building packages ;-) -- *-----------------------------------------* | Conrad Steenberg | | Caltech, Mail Code 356-48 | | Pasadena, CA, 91125 | | e-mail: conrad@hep.caltech.edu | | Tel: (626) 395-8758 | *-----------------------------------------* From jonas.reimers@se.adtranz.com Wed Jan 17 11:38:42 2001 From: jonas.reimers@se.adtranz.com (Jonas Reimers) Date: Wed, 17 Jan 2001 12:38:42 +0100 Subject: [omniORB] Problems with omninames Message-ID: <412569D7.003FFB2F.00@demalng2.goc.adtranz.com> -OmniORB302 win NT 4.0 sp6 MSVC++ 5.0 sp3 Whe I trying to run my own appl. the Naming Service doesnt respond? When running some of the examples it runs ok I hav tried to just copythe code from examle eg1 inte my own appl. just to check. Still doesnt work? Even if they are in the same directory and all. The only diff is the name of the appl and that my appl is compiled/build in MSVC++ 5.0 sp3 Any ideas? From vonWedel@lfpt.rwth-aachen.de Wed Jan 17 11:45:10 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Wed, 17 Jan 2001 12:45:10 +0100 Subject: [omniORB] Fatal exception during event sending Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0041C964C12569D7_= Content-Type: text/plain; charset="us-ascii" Hi again, okay -- got the reason almost, I think. Running the script with ORBtraceLevel = 5 gives me omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6 omniORB: The omniDynamic library is not linked which is probably the error. Do I have to tell omniORBpy to explicitly link omniDynamic or did something go wrong during the build process? Lars vonWedel@lfpt.RWTH-Aachen.DE Sent by: owner-omniorb-list@uk.research.att.com 17/01/01 12:01 To: omniorb-list@uk.research.att.com cc: Subject: [omniORB] Fatal exception during event sending Hi, using Python 2.0 on Solaris 2.7 together with omniORB and omniORBpy I get a fatal exception when working with omniNotify. I can create a new event channel, connect a push consumer and a push supplier to it (in separate Python processes). When I try to push the event to the channel like this: evt = CosNotification.StructuredEvent(evt_header, fd_body, txn_val) self.str_px.push_structured_event(evt) I get: Run-time exception error; current exception: fatalException No handler for exception. I know that this is of little help... What could I do to give you (and me) some hints about what is happening here? Lars --=_alternative 0041C964C12569D7_= Content-Type: text/html; charset="us-ascii"
Hi again,

okay -- got the reason almost, I think. Running the script with ORBtraceLevel = 5 gives me

omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6
omniORB: The omniDynamic library is not linked

which is probably the error. Do I have to tell omniORBpy to explicitly link
omniDynamic or did something go wrong during the build process?

Lars

vonWedel@lfpt.RWTH-Aachen.DE
Sent by: owner-omniorb-list@uk.research.att.com

17/01/01 12:01

To: omniorb-list@uk.research.att.com
cc:
Subject: [omniORB] Fatal exception during event sending

vonWedel@lfpt.RWTH-Aachen.DE
Sent by: owner-omniorb-list@uk.research.att.com

17/01/01 12:01

To: omniorb-list@uk.research.att.com
cc:
Subject: [omniORB] Fatal exception during event sending

Hi,

using Python 2.0 on Solaris 2.7 together with omniORB and omniORBpy
I get a fatal exception when working with omniNotify. I can create a new
event channel, connect a push consumer and a push supplier to it
(in separate Python processes). When I try to push the event to the
channel like this:

evt = CosNotification.StructuredEvent(evt_header, fd_body, txn_val)
self.str_px.push_structured_event(evt)

I get:

Run-time exception error; current exception: fatalException
No handler for exception.

I know that this is of little help... What could I do to give you (and me) some
hints about what is happening here?

Lars

--=_alternative 0049E3BBC12569D7_=-- From zdx_nari@sina.com Wed Jan 17 16:16:48 2001 From: zdx_nari@sina.com (zdx_nari) Date: Thu, Jan 18 2001 00:16:48 +0800 Subject: [omniORB] A simple question! Message-ID: <20010117161648.941.qmail@sina.com> Hello,everyone: I only have a simple question:does omniORB3 support mandrake linux(kernel 2.2.17)? Thank you ! ______________________________________ =================================================================== ��ѡ�ֻ��򵥣�(http://mall.sina.com.cn/yesmobile/) From djr@uk.research.att.com Wed Jan 17 17:43:21 2001 From: djr@uk.research.att.com (David Riddoch) Date: Wed, 17 Jan 2001 17:43:21 +0000 (GMT) Subject: [omniORB] Re: corbaloc In-Reply-To: <7118259C3044D311942700508B2CA5BB4F259D@balance.coactive.com> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1804928587-979753401=:25994 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Peter, Yep, it's not too difficult. I have attached a patch to the omniORB 2.6.1 source that persuades it to accept any key <= 12 bytes long. Untested, but it looks okay! You will need to back port the client-side corbaloc and corbaname stuff yourself (if you need it) -- see omniURI.cc in the omniORB 3 distribution. Then all you need is a way to set the object key in your object implementation in the server. The following function sets up the omniORB::objectKey properly: void set_corbaloc_key(omniORB::objectKey& k, const char* name) { int len = strlen(name); if( len > sizeof(omniORB::objectKey) ) throw something; memcpy(&k, name, len); memset((char*) &k + len, 0, sizeof(omniORB::objectKey) - len); } And you need to pass this key down to the constructor of the skeleton class your object implementation is derived from ... as usual for servers with persistent keys. Hope that works! David ---559023410-1804928587-979753401=:25994 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="omni261_corbaloc.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="omni261_corbaloc.diff" ZGlmZiAtcmMgb21uaU9SQl8yLjYuMS9zcmMvbGliL29tbmlPUkIyL2dpb3BT ZXJ2ZXIuY2MgMjYxL3NyYy9saWIvb21uaU9SQjIvZ2lvcFNlcnZlci5jYw0K KioqIG9tbmlPUkJfMi42LjEvc3JjL2xpYi9vbW5pT1JCMi9naW9wU2VydmVy LmNjCUZyaSBBdWcgMjEgMjA6MDg6NTEgMTk5OA0KLS0tIDI2MS9zcmMvbGli L29tbmlPUkIyL2dpb3BTZXJ2ZXIuY2MJV2VkIEphbiAxNyAxNzoyNzowNCAy MDAxDQoqKioqKioqKioqKioqKioNCioqKiA0NjgsNDkyICoqKioNCiAgICAg IGlmIChrZXlzaXplID09IHNpemVvZihvbW5pT2JqZWN0S2V5KSkgew0KICAg ICAgICBnZXRfY2hhcl9hcnJheSgoQ09SQkE6OkNoYXIgKikmcGRfb2Jqa2V5 LGtleXNpemUpOw0KICAgICAgfQ0KISAgICAgZWxzZSB7DQohICAgICAgIC8v IFRoaXMga2V5IGRpZCBub3QgY29tZSBmcm9tIHRoaXMgb3JiLg0KISAgICAg ICAvLyBzaWxlbnRseSBza2lwIHRoZSBrZXkuIEluaXRpYWxpc2UgcGRfb2Jq a2V5IHRvIGFsbCB6ZXJvcyBhbmQNCiEgICAgICAgLy8gbGV0IHRoZSBjYWxs IHRvIGxvY2F0ZU9iamVjdCgpIGJlbG93IHRvIHJhaXNlIHRoZSBwcm9wZXIg ZXhjZXB0aW9uDQohICAgICAgIHBkX29iamtleSA9IG9tbmlPUkI6Om51bGxr ZXkoKTsNCiEgICAgICAgDQohICAgICAgIC8vIEhvd2V2ZXIsIHdlIG1ha2Ug YSBzcGVjaWFsIGNhc2UgZm9yIHRoZSBib290c3RyYXBwaW5nIGFnZW50Lg0K ISAgICAgICAvLyBUaGUgb2JqZWN0IGtleSBpcyAiSU5JVCIuIElmIHRoZSBr ZXkgbWF0Y2ggYW5kIHdlIGRvIGhhdmUNCiEgICAgICAgLy8gdGhlIGJvb3Rz dHJhcHBpbmcgYWdlbnQgcnVubmluZywgaW5pdGlhbGlzZSBvYmogdG8gcG9p bnQgdG8gaXQuIA0KISAgICAgICBpZiAoa2V5c2l6ZSA9PSA0KSB7DQohIAlD T1JCQTo6Q2hhciBrWzRdOw0KISAJZ2V0X2NoYXJfYXJyYXkoayw0KTsNCiEg CWlmIChrWzBdID09ICdJJyAmJiBrWzFdID09ICdOJyAmJiBrWzJdID09ICdJ JyAmJiBrWzNdID09ICdUJykgew0KISAJICBvYmogPSBvbW5pSW5pdGlhbFJl ZmVyZW5jZXM6OnNpbmdsZXRvbigpLT5oYXNfYm9vdHN0cmFwX2FnZW50SW1w bCgpOw0KISAJfQ0KISAgICAgICB9DQohICAgICAgIGVsc2Ugew0KISAJc2tp cChrZXlzaXplKTsNCiAgICAgICAgfQ0KICAgICAgfQ0KICANCiAgICAgIENP UkJBOjpVTG9uZyBvY3RldGxlbjsNCi0tLSA0NjgsNDg5IC0tLS0NCiAgICAg IGlmIChrZXlzaXplID09IHNpemVvZihvbW5pT2JqZWN0S2V5KSkgew0KICAg ICAgICBnZXRfY2hhcl9hcnJheSgoQ09SQkE6OkNoYXIgKikmcGRfb2Jqa2V5 LGtleXNpemUpOw0KICAgICAgfQ0KISAgICAgZWxzZSBpZigga2V5c2l6ZSA8 IHNpemVvZihvbW5pT2JqZWN0S2V5KSApIHsNCiEgICAgICAgLy8gUGFkIHdp dGggemVyb3MgdG8gZmlsbCBhbiBvbW5pT2JqZWN0S2V5LiAgVGhpcyBpcyBh IGRpcnR5DQohICAgICAgIC8vIGhhY2sgdG8gc3VwcG9ydCBjb3JiYWxvYyAu Li4NCiEgICAgICAgQ09SQkE6OkNoYXIqIGsgPSAmcGRfb2Jqa2V5Ow0KISAg ICAgICBnZXRfY2hhcl9hcnJheShrLCBrZXlzaXplKTsNCiEgICAgICAgbWVt c2V0KGsgKyBrZXlzaXplLCAwLCBzaXplb2Yob21uaU9iamVjdEtleSkgLSBr ZXlzaXplKTsNCiEgDQohICAgICAgIC8vIENoZWNrIHRvIHNlZSBpZiBpdCBp cyBpbiBmYWN0IHRoZSBib290c3RyYXBwaW5nIGFnZW50Lg0KISAgICAgICBp Zigga2V5c2l6ZSA9PSA0ICYmDQohIAkgIGtbMF0gPT0gJ0knICYmIGtbMV0g PT0gJ04nICYmIGtbMl0gPT0gJ0knICYmIGtbM10gPT0gJ1QnICkgew0KISAJ b2JqID0gb21uaUluaXRpYWxSZWZlcmVuY2VzOjpzaW5nbGV0b24oKS0+aGFz X2Jvb3RzdHJhcF9hZ2VudEltcGwoKTsNCiEgCXBkX29iamtleSA9IG9tbmlP UkI6Om51bGxrZXkoKTsNCiAgICAgICAgfQ0KKyAgICAgfQ0KKyAgICAgZWxz ZSB7DQorICAgICAgIHNraXAoa2V5c2l6ZSk7DQogICAgICB9DQogIA0KICAg ICAgQ09SQkE6OlVMb25nIG9jdGV0bGVuOw0K ---559023410-1804928587-979753401=:25994-- From Roumen.Ivanov@dresdner-bank.com Thu Jan 18 09:01:05 2001 From: Roumen.Ivanov@dresdner-bank.com (Ivanov, Roumen) Date: Thu, 18 Jan 2001 10:01:05 +0100 Subject: [omniORB] scanGranularity(0) bug under WinNT Message-ID: Hi, omniORB 3.0.2 WinNT 4.0 SP 5 MSVC 6.0 SP 4 I have the following combination of omniORB options: //--- Tune the ORB ------------------------------------------ omniORB::idleConnectionScanPeriod(omniORB::idleIncoming, 0); omniORB::callTimeOutPeriod(omniORB::serverSide, 0); omniORB::callTimeOutPeriod(omniORB::clientSide, 0); omniORB::MaxMessageSize(8*1024*1024); // The default is 2MB #ifndef WIN32 omniORB::scanGranularity(0); // Bug under NT - looping instead of waiting forever #endif The last one misbehaves under NT taking a lot of processor's time. Roumen From roger.hughes@actfs.co.uk Thu Jan 18 09:12:50 2001 From: roger.hughes@actfs.co.uk (Roger Hughes) Date: Thu, 18 Jan 2001 09:12:50 -0000 Subject: [omniORB] TIE Implementation Warning Messages Message-ID: <001501c0812e$d51e37e0$265b100a@actfs.co.uk> This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C0812E.D50A61C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Call me a bit of a novice, but I've just used the TIE implementation = method on Windows NT for the first time and get loads of warnings (see = below) in the IDL generated source code. I guess that it's to do with = the same method being in both base classes. Is this normal for TIE = implementations or have I done something wrong (again)?!?! The IDL Command line I use is: omniidl.exe -bcxx -K -Wbexample -Wbtp -Wbh=3D.h -Wbs=3DSK.cpp = -Wbd=3DDynSK.cpp -Cr:\nova\corba\inc filename.idl Also, am I right in thinking that the -WBexample arguement only = generates example source for the inheritance implementation? P.S. I've included the warnings below...... r:\nova\corba\inc\novautility.h(370) : warning C4250: = 'POA_NovaUtility::FactoryService_tie' : inherits = 'NovaUtility::_impl_FactoryService::_ptrToInterface' via dominance r:\nova\corba\inc\novautility.h(191) : see declaration of = '_ptrToInterface' R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to = class template instantiation 'POA_NovaUtility::FactoryService_tie' being compiled r:\nova\corba\inc\novautility.h(370) : warning C4250: = 'POA_NovaUtility::FactoryService_tie' : inherits = 'PortableServer::ServantBase::_downcast' via dominance d:\devstudio\myprojects\omni\include\omniorb3\poa.h(653) : see = declaration of '_downcast' R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to = class template instantiation 'POA_NovaUtility::FactoryService_tie' being compiled r:\nova\corba\inc\novautility.h(370) : warning C4250: = 'POA_NovaUtility::FactoryService_tie' : inherits = 'NovaUtility::_impl_FactoryService::_mostDerivedRepoId' via dominance r:\nova\corba\inc\novautility.h(192) : see declaration of = '_mostDerivedRepoId' R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to = class template instantiation 'POA_NovaUtility::FactoryService_tie' being compiled r:\nova\corba\inc\novautility.h(370) : warning C4250: = 'POA_NovaUtility::FactoryService_tie' : inherits = 'PortableServer::ServantBase::_do_get_interface' via dominance d:\devstudio\myprojects\omni\include\omniorb3\poa.h(652) : see = declaration of '_do_get_interface' R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to = class template instantiation 'POA_NovaUtility::FactoryService_tie' being compiled r:\nova\corba\inc\novautility.h(370) : warning C4250: = 'POA_NovaUtility::FactoryService_tie' : inherits = 'NovaUtility::_impl_FactoryService::_dispatch' via dominance r:\nova\corba\inc\novautility.h(188) : see declaration of = '_dispatch' R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to = class template instantiation 'POA_NovaUtility::FactoryService_tie' being compiled Roger Hughes =20 ------=_NextPart_000_0012_01C0812E.D50A61C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

Call me a bit of a novice, but I've just used the = TIE=20 implementation method on Windows NT for the first time and get loads of = warnings=20 (see below) in the IDL generated source code. I guess that it's to do = with the=20 same method being in both base classes. Is this normal for TIE = implementations=20 or have I done something wrong (again)?!?!

The IDL Command line I use is:

omniidl.exe -bcxx -K -Wbexample -Wbtp -Wbh=3D.h = -Wbs=3DSK.cpp=20 -Wbd=3DDynSK.cpp -Cr:\nova\corba\inc filename.idl

Also, am I right in thinking that the -WBexample = arguement=20 only generates example source for the inheritance = implementation?

P.S. I've included the warnings = below......

r:\nova\corba\inc\novautility.h(370) : warning = C4250:=20 'POA_NovaUtility::FactoryService_tie<class = NovaUtility::ServicesServant>'=20 : inherits 'NovaUtility::_impl_FactoryService::_ptrToInterface' via=20 dominance
       =20 r:\nova\corba\inc\novautility.h(191) : see declaration of=20 '_ptrToInterface'
       =20 R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to class = template=20 instantiation 'POA_NovaUtility::FactoryService_tie<class=20 NovaUtility::ServicesServant>' being=20 compiled
r:\nova\corba\inc\novautility.h(370) : warning C4250:=20 'POA_NovaUtility::FactoryService_tie<class = NovaUtility::ServicesServant>'=20 : inherits 'PortableServer::ServantBase::_downcast' via=20 dominance
       =20 d:\devstudio\myprojects\omni\include\omniorb3\poa.h(653) : see = declaration of=20 '_downcast'
       =20 R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to class = template=20 instantiation 'POA_NovaUtility::FactoryService_tie<class=20 NovaUtility::ServicesServant>' being=20 compiled
r:\nova\corba\inc\novautility.h(370) : warning C4250:=20 'POA_NovaUtility::FactoryService_tie<class = NovaUtility::ServicesServant>'=20 : inherits 'NovaUtility::_impl_FactoryService::_mostDerivedRepoId' via=20 dominance
       =20 r:\nova\corba\inc\novautility.h(192) : see declaration of=20 '_mostDerivedRepoId'
       =20 R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to class = template=20 instantiation 'POA_NovaUtility::FactoryService_tie<class=20 NovaUtility::ServicesServant>' being=20 compiled
r:\nova\corba\inc\novautility.h(370) : warning C4250:=20 'POA_NovaUtility::FactoryService_tie<class = NovaUtility::ServicesServant>'=20 : inherits 'PortableServer::ServantBase::_do_get_interface' via=20 dominance
       =20 d:\devstudio\myprojects\omni\include\omniorb3\poa.h(652) : see = declaration of=20 '_do_get_interface'
       =20 R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to class = template=20 instantiation 'POA_NovaUtility::FactoryService_tie<class=20 NovaUtility::ServicesServant>' being=20 compiled
r:\nova\corba\inc\novautility.h(370) : warning C4250:=20 'POA_NovaUtility::FactoryService_tie<class = NovaUtility::ServicesServant>'=20 : inherits 'NovaUtility::_impl_FactoryService::_dispatch' via=20 dominance
       =20 r:\nova\corba\inc\novautility.h(188) : see declaration of=20 '_dispatch'
       =20 R:\nova\corba\dev\corbakit\orbmanager.cpp(83) : see reference to class = template=20 instantiation 'POA_NovaUtility::FactoryService_tie<class=20 NovaUtility::ServicesServant>' being compiled

Roger Hughes

------=_NextPart_000_0012_01C0812E.D50A61C0-- From dgrisby@uk.research.att.com Thu Jan 18 10:29:49 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 18 Jan 2001 10:29:49 +0000 Subject: [omniORB] call to _non_exist In-Reply-To: Message from Andreas Eglseer - Entwicklung of "Tue, 16 Jan 2001 13:59:08 +0100." <9AF728C3B988D411B3F000805F0DD5C307930C@swserv3.lisec.com> Message-ID: <200101181029.KAA03315@pineapple.uk.research.att.com> On Tuesday 16 January, Andreas Eglseer - Entwicklung wrote: > Normally I get an exception and after 3 tries the program ends, but > sometimes the call to _non_existent is hanging. > Is there a better way to check, if the client app is alive, or could you > please tell me why it is possible that the _non_existent call > hangs. The problem occurs if the TCP connection to the object is still open, or can be opened, but the program has died in a way which means it can't respond. One easy way to see this effect is to stop a server program in a debugger. The OS still sees a process sitting on the socket, so it doesn't send any TCP errors. The client just blocks waiting for a reply. It has no way to tell whether the server is frozen, or just being slow. If you set a timeout for operation invocations, the call will be stopped after a while with no response. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 18 10:35:17 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 18 Jan 2001 10:35:17 +0000 Subject: [omniORB] Does omniidl support "long double"? In-Reply-To: Message from Craig Rodrigues of "Tue, 16 Jan 2001 14:30:12 EST." <20010116143012.A19081@mediaone.net> Message-ID: <200101181035.KAA03371@pineapple.uk.research.att.com> On Tuesday 16 January, Craig Rodrigues wrote: > I am trying to compile something for omniORBpy, and am getting the following > error: > omniidl: omniORBpy does not support the long double type. > > Do the latest CVS versions of omniORBpy support long double? Not yet, I'm afraid. It's on the list of things to do, for both C++ and Python. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 18 10:39:39 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 18 Jan 2001 10:39:39 +0000 Subject: [omniORB] Interest in rpm of omni? In-Reply-To: Message from Conrad Steenberg of "Tue, 16 Jan 2001 12:09:53 PST." Message-ID: <200101181039.KAA03423@pineapple.uk.research.att.com> On Tuesday 16 January, Conrad Steenberg wrote: > I'm trying to gauge interest in an rpm for omni. Has it been done before? > My searches didn't turn up anything, but it may lurk somewhere... Jared Peterson has been working on some RPMs, based on work started by Sander Steffann. I expect they will be publicly announced very soon. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 18 12:31:36 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 18 Jan 2001 12:31:36 +0000 Subject: Possible bug? (was Re: [omniORB] Fatal exception during event sending) In-Reply-To: Message from vonWedel@lfpt.rwth-aachen.de of "Wed, 17 Jan 2001 14:13:40 +0100." Message-ID: <200101181231.MAA04804@pineapple.uk.research.att.com> On Wednesday 17 January, vonWedel@lfpt.rwth-aachen.de wrote: > The transmission of the structured event is only possible if the > typecode for the Any value is either CosNaming._tc_NamingContext > or CosNaming._tc_NamingContextExt. Formerly, I used > CORBA._tc_Object which has led to a fatal exception as described > previously. There is a bug in the TypeCode marshaller which prevented CORBA::Object's TypeCode from being sent correctly. It's fixed in CVS and the bugfixes patch. Thanks for the bug report. Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 18 12:37:47 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 18 Jan 2001 12:37:47 +0000 Subject: [omniORB] Thread per method In-Reply-To: Message from Rob van der Leek of "Tue, 16 Jan 2001 13:13:39 +0100." <3A643AF3.87A2F215@fokkerspace.nl> Message-ID: <200101181237.MAA04863@pineapple.uk.research.att.com> On Tuesday 16 January, Rob van der Leek wrote: > 1. Client1 -- push(event) --> EventChannel --- push(event) --> Server > > 2. Server incarnates an object factory, the server's push handler > creates a new object and calls some methods on that object. The method > invocations take some time to complete. > > 3. Client2 -- push(event) --> EventChannel --- push(event) --> Server > > 4. Now Client2 has to wait for the push handler to return (since the ORB > controlled thread policy in OmniORB is implemented as thread-per-object, > and there's only one server object). omniORB's thread policy is not thread per object. It is thread per connection. The EventChannel should open a new connection, so the server will use a different thread. Are you actually seeing a problem, or do you just suspect that there might be one? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From erberj@post.ch Thu Jan 18 16:10:58 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 18 Jan 2001 17:10:58 +0100 Subject: [omniORB] #pragma version MirrorCSI 1.0 Message-ID: <26D7602EA56DD21197BB0000F840029A03EA554B@hceh71.post.ch> Does OmniOrb support this pragma. IDL parses it, but is ist correctly processed? Thanks Jakob From seefeld@sympatico.ca Thu Jan 18 17:40:24 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Thu, 18 Jan 2001 12:40:24 -0500 Subject: [omniORB] new omniidl features Message-ID: <3A672A88.59B606B2@sympatico.ca> I'd like to propose a new feature for omniidl. With the modular backend design, wouldn't it be possible to provide another backend that separates output in the client/server parts (aka proxy/skeleton) ? While I usually need both parts in all processes, I start to see applications where it is clear upfront that one process always acts as a server, and the other only as the client w.r.t. specific interfaces. Having separate source files for proxy/skeleton code may be convenient. Of course, if I compile the generated code into a shared library, it doesn't count much, but if all I need is a single interface, I may want to link the generated/compiled code into the respective executables. Best regards, Stefan _______________________________________________________ Stefan Seefeld Departement de Physique Universite de Montreal email: seefelds@magellan.umontreal.ca _______________________________________________________ ...ich hab' noch einen Koffer in Berlin... From christoph.langner@navigon.de Thu Jan 18 14:48:49 2001 From: christoph.langner@navigon.de (Christoph Langner) Date: Thu, 18 Jan 2001 15:48:49 +0100 Subject: [omniORB] problem with NamingService Message-ID: <3A670251.108F63D@navigon.de> Hello! I use omniORB 3.0.2 and have problems with client / server communication using Naming Services. I succeed in getting the reference for my server object (object is not nil!), but as soon as I like to invoke some method of this object I get a CORBA system exception. Can anybody help me? Christoph Langner Distefora Navigation R&D GmbH, Wuerzburg, Germany From dgrisby@uk.research.att.com Thu Jan 18 17:58:34 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 18 Jan 2001 17:58:34 +0000 Subject: [omniORB] #pragma version MirrorCSI 1.0 In-Reply-To: Message from erberj@post.ch of "Thu, 18 Jan 2001 17:10:58 +0100." <26D7602EA56DD21197BB0000F840029A03EA554B@hceh71.post.ch> Message-ID: <200101181758.RAA05480@pineapple.uk.research.att.com> On Thursday 18 January, erberj@post.ch wrote: > Does OmniOrb support this pragma. IDL parses it, but is ist correctly > processed? Yes, omniORB supports #pragma version. Are you having a problem with it? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From mberry@mweb.co.za Fri Jan 19 12:20:11 2001 From: mberry@mweb.co.za (Matthew Berry) Date: Fri, 19 Jan 2001 14:20:11 +0200 Subject: [omniORB] Exception problems Message-ID: Within my IDL file I have a number of exceptions defined, having added "unexpectedResult" this morning. .... // Exceptions exception dbOutputFailed {}; exception unknownProduct {}; exception undefinedError {}; exception unexpectedResult {}; In my server code, I am throw an exception like: throw CTP::unexpectedResult() but on my client I get a SystemException. I ORB trace from the server looks like: ll_send: 68 bytes 4749 4f50 0100 0101 3800 0000 0000 0000 GIOP....8....... 0200 0000 0200 0000 1e00 0000 4944 4c3a ............IDL: 6f6d 672e 6f72 672f 434f 5242 412f 554e omg.org/CORBA/UN 4b4e 4f57 4e3a 312e 3000 0000 0000 0000 KNOWN:1.0....... 0200 0000 .... If I change the line to throw CTP::undefinedError() Everthing works fine, the tracing being ll_send: 68 bytes 4749 4f50 0100 0101 3800 0000 0000 0000 GIOP....8....... 0200 0000 0100 0000 2800 0000 4944 4c3a ........(...IDL: 6272 6f6e 6572 2e63 6f2e 756b 2f43 5450 broner.co.uk/CTP 2f75 6e64 6566 696e 6564 4572 726f 723a /undefinedError: 312e 3000 1.0. I tried renaming "unexpectedResult" to "badAnswerFromON" and I still get the SystemException. Any ideas on what's/where I am going wrong. Configuration: 2.80 / RH 6.2 / gcc 2.91.66 From jheintz@isogen.com Fri Jan 19 22:24:57 2001 From: jheintz@isogen.com (John D. Heintz) Date: Fri, 19 Jan 2001 16:24:57 -0600 Subject: [omniORB] Can't connect to server when launched from Linux?!? Message-ID: <3A68BEB9.2050301@isogen.com> Hello,every one: Our system setup is pretty simple and common. We are launching an "omniNames -logdir " and our Python server script with "python launch.py -ORBInitRef NameService=corbaname::localhost". This script creates a servant and object reference, gets a ref to the NameService, and binds (actually rebinds) a string name to the object reference. A client test script uses "corbaname::hostname#ServerName" to connect. This works perfectly for localhost client and server, it works for windows based server and any client, it does not work for linux based server and any non-localhost clients! We have also checked our hosts.allow and hosts.deny files, ultimately trying "ALL : ALL" in hosts.allow just to be sure. Here is the trace from the failing client connection, followed by the start where the successful client connections pick up and continue. Thanks for any help! John ################## Failing client connection script trace######### omniORB: The omniDynamic library is not linked. omniORB: strand Ripper: start. omniORB: scavenger : start. omniORB: Python thread state scavenger start. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x4e616d6553657276696365> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: ll_send: 108 bytes 4749 4f50 0100 0100 6000 0000 0000 0000 GIOP....`....... 0100 0000 0100 0000 0b00 0000 4e61 6d65 ............Name 5365 7276 6963 6500 0600 0000 5f69 735f Service....._is_ 6100 0000 0700 0000 6e6f 626f 6479 0000 a.......nobody.. 2800 0000 4944 4c3a 6f6d 672e 6f72 672f (...IDL:omg.org/ 436f 734e 616d 696e 672f 4e61 6d69 6e67 CosNaming/Naming 436f 6e74 6578 743a 312e 3000 Context:1.0. ll_recv: 25 bytes 4749 4f50 0100 0101 0d00 0000 0000 0000 GIOP............ 0100 0000 0000 0000 01 ......... omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating ref to remote: key<0x4e616d6553657276696365> target id : IDL:omg.org/CosNaming/NamingContext:1.0 most derived id: omniORB: string_to_object attempting to resolve `BonnellServer' from naming service ll_send: 108 bytes 4749 4f50 0100 0100 6000 0000 0000 0000 GIOP....`....... 0200 0000 0100 0000 0b00 0000 4e61 6d65 ............Name 5365 7276 6963 6500 0600 0000 5f69 735f Service....._is_ 6100 0000 0700 0000 6e6f 626f 6479 0000 a.......nobody.. 2800 0000 4944 4c3a 6f6d 672e 6f72 672f (...IDL:omg.org/ 436f 734e 616d 696e 672f 4e61 6d69 6e67 CosNaming/Naming 436f 6e74 6578 743a 312e 3000 Context:1.0. ll_recv: 25 bytes 4749 4f50 0100 0101 0d00 0000 0000 0000 GIOP............ 0200 0000 0000 0000 01 ......... ll_send: 93 bytes 4749 4f50 0100 0100 5100 0000 0000 0000 GIOP....Q....... 0300 0000 0100 0000 0b00 0000 4e61 6d65 ............Name 5365 7276 6963 6500 0800 0000 7265 736f Service.....reso 6c76 6500 0700 0000 6e6f 626f 6479 0000 lve.....nobody.. 0100 0000 0e00 0000 426f 6e6e 656c 6c53 ........BonnellS 6572 7665 7200 696e 0100 0000 00 erver.in..... ll_recv: 110 bytes 4749 4f50 0100 0101 6200 0000 0000 0000 GIOP....b....... 0300 0000 0000 0000 1e00 0000 4944 4c3a ............IDL: 626f 6e6e 656c 6c2f 426f 6e6e 656c 6c53 bonnell/BonnellS 6572 7665 723a 312e 3000 0000 0100 0000 erver:1.0....... 0000 0000 2600 0000 0101 0000 0a00 0000 ....&........... 3132 372e 302e 302e 3100 0e0c 0e00 0000 127.0.0.1....... fec0 6068 3a00 0001 ab00 0000 0000 ..`h:......... omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: root<0> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:bonnell/BonnellServer:1.0 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef() -- deleted. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef() -- deleted. omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating Python ref to remote: root<0> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:bonnell/BonnellServer:1.0 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(IDL:bonnell/BonnellServer:1.0) -- deleted. omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating Python ref to remote: root<0> target id : IDL:bonnell/BonnellServer:1.0 most derived id: IDL:bonnell/BonnellServer:1.0 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(IDL:bonnell/BonnellServer:1.0) -- deleted. omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1085 omniORB: tcpSocketStrand::~Strand() close socket no. 4294967295 omniORB: throw COMM_FAILURE from remoteIdentity.cc:178 Traceback (innermost last): File "client.py", line 15, in ? bServ.getSession("admin", "admin") File "C:\home\joshu\bonnell-impl\Bonnell_idl.py", line 2453, in getSession omniORB.CORBA.COMM_FAILURE: Minor: 0, Completed: COMPLETED_NO. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:bonnell/BonnellServer:1.0) -- deleted. ######################### end of failing trace #################### ############### Fragment of successful trace ###################### # I have duplicated the first line from the common parts of the # trace to help locate the branch-point omniORB: ObjRef(IDL:bonnell/BonnellServer:1.0) -- deleted. ll_send: 102 bytes 4749 4f50 0100 0100 5a00 0000 0000 0000 GIOP....Z....... 0100 0000 0100 0000 0e00 0000 fec0 6068 ..............`h 3a00 0001 ab00 0000 0000 0000 0600 0000 :............... 5f69 735f 6100 0000 0700 0000 6e6f 626f _is_a.......nobo 6479 0000 1e00 0000 4944 4c3a 626f 6e6e dy......IDL:bonn 656c 6c2f 426f 6e6e 656c 6c53 6572 7665 ell/BonnellServe 723a 312e 3000 r:1.0. ll_recv: 25 bytes 4749 4f50 0100 0101 0d00 0000 0000 0000 GIOP............ 0100 0000 0000 0000 01 ......... ll_send: 94 bytes 4749 4f50 0100 0100 5200 0000 0000 0000 GIOP....R....... 0200 0000 0100 0000 0e00 0000 fec0 6068 ..............`h 3a00 0001 ab00 0000 0000 0000 0b00 0000 :............... 6765 7453 6573 7369 6f6e 0000 0700 0000 getSession...... 6e6f 626f 6479 0000 0600 0000 6164 6d69 nobody......admi 6e00 6c2f 0600 0000 6164 6d69 6e00 n.l/....admin. omniORB: Python thread state scavenger start. ll_recv: 176 bytes 4749 4f50 0100 0101 a400 0000 0000 0000 GIOP............ 0200 0000 0000 0000 1f00 0000 4944 4c3a ............IDL: 626f 6e6e 656c 6c2f 426f 6e6e 656c 6c53 bonnell/BonnellS 6573 7369 6f6e 3a31 2e30 0000 0100 0000 ession:1.0...... 0000 0000 6800 0000 0101 0000 0a00 0000 ....h........... 3132 372e 302e 302e 3100 0e0c 5000 0000 127.0.0.1...P... ff5a 4f44 4243 6f72 6261 5365 7276 6572 .ZODBCorbaServer 3937 3939 3139 3034 302e 3037 36ff 3937 979919040.076.97 3939 3139 3034 362e 3239 302e 3433 3431 9919046.290.4341 3831 3937 3338 3335 fec0 6068 3a02 0001 81973835..`h:... ab00 426f 6e6e 656c 6c53 6573 7369 6f6e ..BonnellSession omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating Python ref to remote: root/ZODBCorbaServer979919040.076/979919046.290.434181973835 target id : IDL:bonnell/BonnellSession:1.0 most derived id: IDL:bonnell/BonnellSession:1.0 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(IDL:bonnell/BonnellSession:1.0) -- deleted. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:bonnell/BonnellServer:1.0) -- deleted. ################### end of successful client script fragment ########## From rodrigc@mediaone.net Fri Jan 19 22:52:25 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Fri, 19 Jan 2001 17:52:25 -0500 Subject: [omniORB] Can't connect to server when launched from Linux?!? In-Reply-To: <3A68BEB9.2050301@isogen.com>; from jheintz@isogen.com on Fri, Jan 19, 2001 at 04:24:57PM -0600 References: <3A68BEB9.2050301@isogen.com> Message-ID: <20010119175225.A3853@mediaone.net> On Fri, Jan 19, 2001 at 04:24:57PM -0600, John D. Heintz wrote: > Hello,every one: > > Our system setup is pretty simple and common. > > We are launching an "omniNames -logdir " and our Python > server script with > "python launch.py -ORBInitRef NameService=corbaname::localhost". How about trying: launch.py -ORBInitRef NameService=corbaloc:iiop:[hostname]:[port]/NameService Where [hostname] and [port] are substituted by the host and port that your NameService is running on? -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From jheintz@isogen.com Fri Jan 19 22:57:15 2001 From: jheintz@isogen.com (John D. Heintz) Date: Fri, 19 Jan 2001 16:57:15 -0600 Subject: [omniORB] Can't connect to server when launched from Linux?!? References: <3A68BEB9.2050301@isogen.com> <20010119175225.A3853@mediaone.net> Message-ID: <3A68C64B.4050303@isogen.com> The NameService is connection is always working fine on the server side. This launch.py script is our server script and has always correctly accessed the NameServer and bound an object reference to a name. To further remove dependencies on any NameService issues we also just ran a test where we transferred the string IOR to the client and never used a NameServer. We got the same failure on the client.py script when running remotely to a linux server. Thanks for the help though, John Craig Rodrigues wrote: > On Fri, Jan 19, 2001 at 04:24:57PM -0600, John D. Heintz wrote: > >> Hello,every one: >> >> Our system setup is pretty simple and common. >> >> We are launching an "omniNames -logdir " and our Python >> server script with >> "python launch.py -ORBInitRef NameService=corbaname::localhost". > > > How about trying: > > launch.py -ORBInitRef NameService=corbaloc:iiop:[hostname]:[port]/NameService > > Where [hostname] and [port] are substituted by the host and port > that your NameService is running on? -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | jheintz@isogen.com w w w . d a t a c h a n n e l . c o m From S.Lo@uk.research.att.com Mon Jan 22 11:00:23 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 22 Jan 2001 11:00:23 +0000 Subject: [omniORB] Can't connect to server when launched from Linux?!? In-Reply-To: <3A68BEB9.2050301@isogen.com> ("John D. Heintz"'s message of "Fri, 19 Jan 2001 16:24:57 -0600") References: <3A68BEB9.2050301@isogen.com> Message-ID: <3o3deb97i0.fsf@neem.uk.research.att.com> This is another frequently encountered problem with recent redhat installations. I don't know if other installations do the same. IMO, it is not how one should configure a networked machine. Redhat always put something like this in your /etc/hosts: 127.0.0.1 foo localhost.localdomain localhost This is ok if yours is a home machine with just a dialup interface. But on a networked machine, if you have that entry and one do a name to address lookup for "foo", what you get is 127.0.0.1. In other words, one cannot find out what the real IP address of your host is. By default, omniORB always try to use the IP address, instead of the hostname in the IORs it gives out. So it uses host to address lookup. And it gets 127.0.0.1. Being a local loopback network interface, the address obviously cannot work on other machines. The solution is either: 1. Remove "foo" from the /etc/hosts, (PREFERRED) 2. Start your server with this ORB option: $./eg2_impl -ORBpoa_iiop_name_port "foo" Regards, Sai-Lai >>>>> John D Heintz writes: > Hello,every one: > Our system setup is pretty simple and common. > We are launching an "omniNames -logdir " and our Python > server script with > "python launch.py -ORBInitRef NameService=corbaname::localhost". > This script creates a servant and object reference, gets a ref to the > NameService, and binds (actually rebinds) a string name to the object > reference. > A client test script uses "corbaname::hostname#ServerName" to connect. > This works perfectly for localhost client and server, it works for > windows based server and any client, it does not work for linux based > server and any non-localhost clients! > We have also checked our hosts.allow and hosts.deny files, ultimately > trying "ALL : ALL" in hosts.allow just to be sure. > Here is the trace from the failing client connection, followed by the > start where the successful client connections pick up and continue. -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From vonWedel@lfpt.rwth-aachen.de Mon Jan 22 14:46:21 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Mon, 22 Jan 2001 15:46:21 +0100 Subject: [omniORB] More on any's... Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00525F0FC12569DC_= Content-Type: text/plain; charset="us-ascii" Hi, I'm experiencing another problem using the any type. The patch from last week (bug #7) worked fine, now it seems that there is a problem in coercing an any into a certain type using the proprietary omniORB way, giving a type code as an argument to the value function of the any. However, it returns None when I call it the first time and returns an object reference (in this case) only when calling it a second time... # obtain an any called 'item' from somewhere mc = item.value(CORBA.TypeCode(CORBA.id(X.Y))) mc = item.value(CORBA.TypeCode(CORBA.id(X.Y))) if mc is not None: pass else: print 'Hello!' Is it possible that there is some initialization not working? Lars --=_alternative 00525F0FC12569DC_= Content-Type: text/html; charset="us-ascii"
Hi,

I'm experiencing another problem using the any type.

The patch from last week (bug #7) worked fine, now it seems
that there is a problem in coercing an any into a certain type
using the proprietary omniORB way, giving a type code
as an argument to the value function of the any. However,
it returns None when I call it the first time and returns an
object reference (in this case) only when calling it a second
time...

# obtain an any called 'item' from somewhere

mc = item.value(CORBA.TypeCode(CORBA.id(X.Y)))
mc = item.value(CORBA.TypeCode(CORBA.id(X.Y)))
if mc is not None:
pass
else:
print 'Hello!'

Is it possible that there is some initialization not working?

Lars

--=_alternative 00525F0FC12569DC_=-- From lars@ibp.de Mon Jan 22 18:24:11 2001 From: lars@ibp.de (Lars Immisch) Date: Mon, 22 Jan 2001 19:24:11 +0100 Subject: [omniORB] Dynamic stub doesn't compile under MSVC (struct inside union inside namespace) Message-ID: <200101221824.TAA10174@googleplex.ibp.de> Dear all, I have a problem with the code generated from the following idl file. The idl file is a stripped down version of my real definition, don't be surprised it's not very useful in itself. module test { enum TermType { terminal, expression }; enum Operator { plus, minus }; union ParseTree switch(TermType) { case terminal: long digit; case expression: struct Exp { Operator op; sequence operands; } ex; }; }; When I compile the resulting DynSK.cpp file, I get an error on the second line of the following code snippet; MSVC complains that test_ParseTree does not exist or is not a namespace. namespace test_ParseTree = test::ParseTree; namespace test_ParseTree { const CORBA::TypeCode_ptr _tc_Exp = _0RL_tc_test_mParseTree_mExp; } These two lines seem to be a workaround specifically for MSVC, since the enclosing lines read: #if defined(HAS_Cplusplus_Namespace) && defined(_MSC_VER) // MSVC++ does not give the constant external linkage otherwise. namespace test_ParseTree = test::ParseTree; namespace test_ParseTree { const CORBA::TypeCode_ptr _tc_Exp = _0RL_tc_test_mParseTree_mExp; } #else const CORBA::TypeCode_ptr test::ParseTree::_tc_Exp = _0RL_tc_test_mParseTree_mExp; #endif The workaround is to remove the workaround in the DynSK.cpp file :-) Trying to understand why the workaround exists in the first place, I tried to reference CORBA::TypeCode_ptr test::ParseTree::_tc_Exp in another .cpp file after removing the workaround and that compiled and linked ok. >From the comment, I was assuming I would get a linker error. I have applied Service Pack 3 to my VC++ 6.0, maybe the behaviour is not consistent across versions? I'd appreciate any comments. Thanks, Lars Immisch From jiwils@acxiom.com Mon Jan 22 20:26:29 2001 From: jiwils@acxiom.com (jiwils - Jimmy Wilson) Date: Mon, 22 Jan 2001 14:26:29 -0600 Subject: [omniORB] COMM_FAILURE Error On Usable Remote Object In omniORBpy Message-ID: <3E54A6BA1EAFD311AD75009027DEA5C00781F115@conmsx04.conway.acxiom.com> I have a servant written with Iona's implementation. It has a configurable thread pool, and it should be noted that increasing or decreasing the thread pool doesn't seem to change what happens (described below). I have a simple test script written in Python/omniORBpy that tries to make one remote procedure call. If I then use the "start " syntax in NT to simultaneously run that script 10 times from a batch file, between 7-8 of the new processes work fine. Between two and three report a COM_FAILURE. Does anyone know what might be happening in this scenario? I have tried to set the scan granularity to 30 seconds and to 0, but that did not seem to have an effect either. Any help/ideas are greatly appreciated. Jimmy -- James "Jimmy" Wilson Software Developer, Acxiom Corporation From jheintz@isogen.com Mon Jan 22 22:54:19 2001 From: jheintz@isogen.com (John D. Heintz) Date: Mon, 22 Jan 2001 16:54:19 -0600 Subject: [omniORB] Can't connect to server when launched from Linux?!? References: <3A68BEB9.2050301@isogen.com> <3o3deb97i0.fsf@neem.uk.research.att.com> Message-ID: <3A6CBA1B.6080302@isogen.com> Thanks so much Sai-Lai, That fixed our problem. We were running on a Debian box. I don't know if I added that configuration or if it installed that way. John Sai-Lai Lo wrote: > This is another frequently encountered problem with recent redhat > installations. I don't know if other installations do the same. IMO, it is > not how one should configure a networked machine. > > Redhat always put something like this in your /etc/hosts: > > 127.0.0.1 foo localhost.localdomain localhost > > This is ok if yours is a home machine with just a dialup interface. > But on a networked machine, if you have that entry and one do a name to > address lookup for "foo", what you get is 127.0.0.1. In other words, one > cannot find out what the real IP address of your host is. > > By default, omniORB always try to use the IP address, instead of the > hostname in the IORs it gives out. So it uses host to address lookup. > And it gets 127.0.0.1. Being a local loopback network interface, the > address obviously cannot work on other machines. > > The solution is either: > > 1. Remove "foo" from the /etc/hosts, (PREFERRED) > 2. Start your server with this ORB option: > $./eg2_impl -ORBpoa_iiop_name_port "foo" > > Regards, > > Sai-Lai > > > > >>>>>> John D Heintz writes: >>>>> > >> Hello,every one: >> Our system setup is pretty simple and common. > > >> We are launching an "omniNames -logdir " and our Python >> server script with >> "python launch.py -ORBInitRef NameService=corbaname::localhost". > > >> This script creates a servant and object reference, gets a ref to the >> NameService, and binds (actually rebinds) a string name to the object >> reference. > > >> A client test script uses "corbaname::hostname#ServerName" to connect. > > >> This works perfectly for localhost client and server, it works for >> windows based server and any client, it does not work for linux based >> server and any non-localhost clients! > > >> We have also checked our hosts.allow and hosts.deny files, ultimately >> trying "ALL : ALL" in hosts.allow just to be sure. > > >> Here is the trace from the failing client connection, followed by the >> start where the successful client connections pick up and continue. -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | jheintz@isogen.com w w w . d a t a c h a n n e l . c o m From MKeay@SeeBeyond.com Mon Jan 22 23:02:33 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Mon, 22 Jan 2001 15:02:33 -0800 Subject: [omniORB] CORBA::COMM_FAILURE Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC1D@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C084C7.67555DA0 Content-Type: text/plain; charset="iso-8859-1" We have been working on a project, to connect to a thirdparty system. We are getting a COMM_FAILURE exception when trying to invoke a method on an object reference. But we do have a valid object reference. Yet, when we use the supplied, sample client, everything works fine. Does, anyone have any idea why we would experience such an exception? I have read the manual that comes with omni orb and it suggests to keep retrying, but this does not explain what is happening, each and everytime. Server on Solaris, client on NT, using omniorb 3.0.1 Mikey ------_=_NextPart_001_01C084C7.67555DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CORBA::COMM_FAILURE

We have been working on a project, to = connect to a thirdparty system. We are getting a COMM_FAILURE exception = when trying to invoke a method on an object reference. But we do have a = valid object reference. Yet, when we use the supplied, sample client, = everything works fine. Does, anyone have any idea why we would = experience such an exception?

I have read the manual that comes with = omni orb and it suggests to keep retrying, but this does not explain = what is happening, each and everytime.

Server on Solaris, client on NT, using = omniorb 3.0.1

Mikey

------_=_NextPart_001_01C084C7.67555DA0-- From Val.Goldring@tradingtechnologies.com Mon Jan 22 23:22:58 2001 From: Val.Goldring@tradingtechnologies.com (Val Goldring (TT)) Date: Mon, 22 Jan 2001 17:22:58 -0600 Subject: [omniORB] OMNIORB_USEHOSTNAME Message-ID: <1081D62B673CD411A8D8005004A1AF80124C19@chntexchangsrvr.tradingtechnologies> Hello. Did anyone try to use OMNIORB_USEHOSTNAME or -ORBpoa_iiop_name_port to work through a firewall? What will happen if the name or address given is not a real address of the host? Another one: Can -ORBpoa_iiop_name_port be used to give one host name or address and multiple ports? Will they all add up? Thanks in advance, Val Goldring TradingTechnolgies Ph.: (847) 448-8425 From MKeay@SeeBeyond.com Mon Jan 22 23:53:08 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Mon, 22 Jan 2001 15:53:08 -0800 Subject: [omniORB] CORBA::COMM_FAILURE Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC1F@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C084CE.786EA360 Content-Type: text/plain; charset="iso-8859-1" Further to this e-mail I was able to switch on tracing an extrapolate the following information omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x494e4954> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: omg.org/CORBA/InitialReferences:1.0 omniORB: Initialising omniDynamic library. omniORB: Trying to resolve initial reference `NameService' with boot agent: IOR:01000000240000006f6d672e6f72672f434f5242412f496e697469616c5265666572656e 6365733a312e30000100000000000000180000000101000006000000474150533100e71d0400 0000494e4954 omniORB: strand Ripper: start. omniORB: scavenger : start. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x4e616d6553657276696365> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0 omniORB: Initial reference `NameService' resolved with boot agent. omniORB: LocateRequest to remote: key<0x4e616d6553657276696365> omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: boa<0x3a6cc44d905f85c600000002> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:ZImporter:1.0 omniORB: LocateRequest to remote: boa<0x3a6cc44d905f85c600000002> omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1067 omniORB: tcpSocketStrand::~Strand() close socket no. 208 omniORB: defaultTransientExceptionHandler: retry 0th times. omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1091 omniORB: tcpSocketStrand::~Strand() close socket no. 4294967295 omniORB: throw COMM_FAILURE from remoteIdentity.cc:181 omniORB: Preparing to shutdown ORB. omniORB: Deinitialising omniDynamic library. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(omg.org/CORBA/InitialReferences:1.0) -- deleted. omniORB: scavenger : woken by poke() omniORB: scavenger : exit. omniORB: strand Ripper: exit. omniORB: ORB shutdown is complete. omniORB: No more references to the ORB -- deleted. Can anyone explain what we is going on here? -----Original Message----- From: Michael Keay [mailto:MKeay@SeeBeyond.com] Sent: Monday, January 22, 2001 3:03 PM To: Omniorb-List@Uk. Research. Att. Com (E-mail) Subject: [omniORB] CORBA::COMM_FAILURE We have been working on a project, to connect to a thirdparty system. We are getting a COMM_FAILURE exception when trying to invoke a method on an object reference. But we do have a valid object reference. Yet, when we use the supplied, sample client, everything works fine. Does, anyone have any idea why we would experience such an exception? I have read the manual that comes with omni orb and it suggests to keep retrying, but this does not explain what is happening, each and everytime. Server on Solaris, client on NT, using omniorb 3.0.1 Mikey ------_=_NextPart_001_01C084CE.786EA360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CORBA::COMM_FAILURE

Further to this e-mail I was able to switch on tracing an = extrapolate the=20 following information

omniORB: strand Rope::incrRefCount: old value =3D = 0
omniORB: Creating=20 ref to remote: key<0x494e4954>
target=20 id      : = IDL:omg.org/CORBA/Object:1.0
most=20 derived id: omg.org/CORBA/InitialReferences:1.0
omniORB: = Initialising=20 omniDynamic library.
omniORB: Trying to resolve initial reference=20 `NameService'
with boot agent:=20 IOR:01000000240000006f6d672e6f72672f434f5242412f496e697469616c5265666572= 656e6365733a312e30000100000000000000180000000101000006000000474150533100= e71d04000000494e4954
omniORB:=20 strand Ripper: start.
omniORB: scavenger : start.
omniORB: strand = Rope::incrRefCount: old value =3D 0
omniORB: Creating ref to remote: = key<0x4e616d6553657276696365>
target=20 id      : = IDL:omg.org/CORBA/Object:1.0
most=20 derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
omniORB: = Initial=20 reference `NameService' resolved with boot agent.
omniORB: = LocateRequest to=20 remote: key<0x4e616d6553657276696365>
omniORB: strand=20 Rope::incrRefCount: old value =3D 0
omniORB: Creating ref to remote: = boa<0x3a6cc44d905f85c600000002>
target=20 id      : = IDL:omg.org/CORBA/Object:1.0
most=20 derived id: IDL:ZImporter:1.0
omniORB: LocateRequest to remote:=20 boa<0x3a6cc44d905f85c600000002>
omniORB: throw = omniConnectionBroken=20 from tcpSocketMTfactory.cc:1067
omniORB: tcpSocketStrand::~Strand() = close=20 socket no. 208
omniORB: defaultTransientExceptionHandler: retry 0th=20 times.
omniORB: throw omniConnectionBroken from=20 tcpSocketMTfactory.cc:1091
omniORB: tcpSocketStrand::~Strand() close = socket=20 no. 4294967295
omniORB: throw COMM_FAILURE from=20 remoteIdentity.cc:181
omniORB: Preparing to shutdown = ORB.
omniORB:=20 Deinitialising omniDynamic library.
omniORB: omniRemoteIdentity=20 deleted.
omniORB: strand Rope::decrRefCount: old value =3D = 1
omniORB:=20 ObjRef(omg.org/CORBA/InitialReferences:1.0) -- deleted.
omniORB: = scavenger :=20 woken by poke()
omniORB: scavenger : exit.
omniORB: strand = Ripper:=20 exit.
omniORB: ORB shutdown is complete.
omniORB: No more = references to=20 the ORB -- deleted.

Can=20 anyone explain what we is going on here?

-----Original Message-----
From: Michael Keay=20 [mailto:MKeay@SeeBeyond.com]
Sent: Monday, January 22, 2001 = 3:03=20 PM
To: Omniorb-List@Uk. Research. Att. Com=20 (E-mail)
Subject: [omniORB] = CORBA::COMM_FAILURE

We have been working on a project, to = connect to a=20 thirdparty system. We are getting a COMM_FAILURE exception when = trying to=20 invoke a method on an object reference. But we do have a valid object = reference. Yet, when we use the supplied, sample client, everything = works=20 fine. Does, anyone have any idea why we would experience such an=20 exception?

I have read the manual that comes with = omni orb and=20 it suggests to keep retrying, but this does not explain what is = happening,=20 each and everytime.

Server on Solaris, client on NT, using = omniorb=20 3.0.1

Mikey =

------_=_NextPart_001_01C084CE.786EA360-- From jcoruna@umd.es Tue Jan 23 08:45:00 2001 From: jcoruna@umd.es (=?iso-8859-1?Q?Juan_Carlos_Coru=F1a?=) Date: Tue, 23 Jan 2001 09:45:00 +0100 Subject: [omniORB] problem with insPOA and Factory object Message-ID: Hello all! I'm new to this mailing list and new to CORBA in general. I try to implement a Factory object to create instances of another = object, but without success. This is the server code: #!/usr/bin/python import sys from omniORB import CORBA, PortableServer import MQ_module, MQ_module__POA import corba_MQ orb =3D CORBA.ORB_init(['./corba_server.py', '-ORBpoa_iiop_port', = '2809'], CORBA.ORB_ID) inspoa =3D orb.resolve_initial_references('omniINSPOA') class MQ_class_i(corba_MQ.MQ_class, MQ_module__POA.MQ): pass class MQ_Factory_i(MQ_module__POA.MQ_Factory): def create_MQ(self): print 'creating MQ' mq =3D MQ_class_i() return mq._this() mq_Factory =3D MQ_Factory_i() inspoa.activate_object_with_id("MQ_Factory", mq_Factory) poaManager =3D inspoa._get_the_POAManager() poaManager.activate() orb.run() This is the idl: // echo.idl module MQ_module { interface MQ { typedef sequence pairs; typedef sequence list; string Version(); string Login(in string user); short Logout(); short SetDictionary(in string attr, in string val); short Send(in string recipient); short GetPriority(); void SetPriority(in short prio); short Count(); short GetMessage(); short WaitMessage(in float sec); string GetFrom(); short NextMsq(); string Attrib(); string Value(); string Attributes(in short index); string Values(in short index); list GetPairs(); short SetPairs(in pairs list); short Clear(); }; interface MQ_Factory { MQ create_MQ(); }; }; And this is the client: #!/usr/bin/env python import sys, time from omniORB import CORBA import MQ_module orb =3D CORBA.ORB_init(sys.argv, CORBA.ORB_ID) ior =3D 'corbaloc::localhost:2809/MQ_Factory' obj =3D orb.string_to_object(ior) mq_factory =3D obj._narrow(MQ_module.MQ_Factory) if mq_factory is None: print "Object reference is not an MQ_interface" sys.exit(1) mq_jcoruna =3D mq_factory.create_MQ() mq_dsilva =3D mq_factory.create_MQ() session =3D mq_jcoruna.Login('jcoruna') The problem appears here in the last line ("session =3D = mq_jcoruna.Login('jcoruna')"). The system doesn't return any value and = waits until timeout. The system works correctly without the Factory. What's wrong? From jonas.reimers@se.adtranz.com Tue Jan 23 10:19:03 2001 From: jonas.reimers@se.adtranz.com (Jonas Reimers) Date: Tue, 23 Jan 2001 11:19:03 +0100 Subject: [omniORB] Naming Service problems on NT4 Message-ID: <412569DD.0038AFB8.00@demalng2.goc.adtranz.com> - omniORB 3.02 WIN NT 4.0 sp6 MSVC++ 5.0 sp3 I am trying to run the eg3 examples but all I gets is: Caught CORBA::SystemException. My omniORB.cfg file looks like follows: # omniOrb configuration file - basic options # ORBInitRef NameService=corbaname::GBGPC0019:2809 #ORBDefaultInitRef corbaname::GBGPC0019#services NAMESERVICE IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4................................ #ORBInitialHost GBGPC0019 #ORBInitialPort 2809 The IOR string is also available in the registry. I have set the enviroment variables OMNIORB_LOGDIR and OMNIORB_CONFIG to point to my log and cfg directories. Any ideas? /Jonas Reimers From S.Lo@uk.research.att.com Tue Jan 23 10:44:25 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 23 Jan 2001 10:44:25 +0000 Subject: [omniORB] CORBA::COMM_FAILURE In-Reply-To: <9B85913BDA568742B72DAF6DF54ECBC60159CC1F@mail01.stc.com> (Michael Keay's message of "Mon, 22 Jan 2001 15:53:08 -0800") References: <9B85913BDA568742B72DAF6DF54ECBC60159CC1F@mail01.stc.com> Message-ID: <3osnmabl9y.fsf@neem.uk.research.att.com> Here is what happened: 1. ORB starts up and was given "GAPS1" port 7655 to resolve initial references. It managed to the root naming context from GAPS1. 2. May be a lookup is done to the naming service to get an object reference of type ZImporter. This also succeeded. Notice that this step is not shown on the trace. I'm just guessing. 3. The application involves on the ZImporter object. The ORB issues a locate request. It tries to connect to the remote address space where the ZImporter resides and failed. A COMM_FAILURE is then raised. You should check wheter you indeed have a ZImporter object running somewhere and it has been registered with the naming service. Sai-Lai >>>>> Michael Keay writes: > Further to this e-mail I was able to switch on tracing an extrapolate the > following information > omniORB: strand Rope::incrRefCount: old value = 0 > omniORB: Creating ref to remote: key<0x494e4954> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: omg.org/CORBA/InitialReferences:1.0 > omniORB: Initialising omniDynamic library. > omniORB: Trying to resolve initial reference `NameService' > with boot agent: > IOR:01000000240000006f6d672e6f72672f434f5242412f496e697469616c5265666572656e > 6365733a312e30000100000000000000180000000101000006000000474150533100e71d0400 > 0000494e4954 > omniORB: strand Ripper: start. > omniORB: scavenger : start. > omniORB: strand Rope::incrRefCount: old value = 0 > omniORB: Creating ref to remote: key<0x4e616d6553657276696365> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0 > omniORB: Initial reference `NameService' resolved with boot agent. > omniORB: LocateRequest to remote: key<0x4e616d6553657276696365> > omniORB: strand Rope::incrRefCount: old value = 0 > omniORB: Creating ref to remote: boa<0x3a6cc44d905f85c600000002> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: IDL:ZImporter:1.0 > omniORB: LocateRequest to remote: boa<0x3a6cc44d905f85c600000002> > omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1067 > omniORB: tcpSocketStrand::~Strand() close socket no. 208 > omniORB: defaultTransientExceptionHandler: retry 0th times. > omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1091 > omniORB: tcpSocketStrand::~Strand() close socket no. 4294967295 > omniORB: throw COMM_FAILURE from remoteIdentity.cc:181 > omniORB: Preparing to shutdown ORB. > omniORB: Deinitialising omniDynamic library. > omniORB: omniRemoteIdentity deleted. > omniORB: strand Rope::decrRefCount: old value = 1 > omniORB: ObjRef(omg.org/CORBA/InitialReferences:1.0) -- deleted. > omniORB: scavenger : woken by poke() > omniORB: scavenger : exit. > omniORB: strand Ripper: exit. > omniORB: ORB shutdown is complete. > omniORB: No more references to the ORB -- deleted. > Can anyone explain what we is going on here? > -----Original Message----- > From: Michael Keay [mailto:MKeay@SeeBeyond.com] > Sent: Monday, January 22, 2001 3:03 PM > To: Omniorb-List@Uk. Research. Att. Com (E-mail) > Subject: [omniORB] CORBA::COMM_FAILURE > We have been working on a project, to connect to a thirdparty system. We are > getting a COMM_FAILURE exception when trying to invoke a method on an object > reference. But we do have a valid object reference. Yet, when we use the > supplied, sample client, everything works fine. Does, anyone have any idea > why we would experience such an exception? > I have read the manual that comes with omni orb and it suggests to keep > retrying, but this does not explain what is happening, each and everytime. > Server on Solaris, client on NT, using omniorb 3.0.1 > Mikey -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From S.Lo@uk.research.att.com Tue Jan 23 10:49:53 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 23 Jan 2001 10:49:53 +0000 Subject: [omniORB] OMNIORB_USEHOSTNAME In-Reply-To: <1081D62B673CD411A8D8005004A1AF80124C19@chntexchangsrvr.tradingtechnologies> ("Val Goldring's message of "Mon, 22 Jan 2001 17:22:58 -0600") References: <1081D62B673CD411A8D8005004A1AF80124C19@chntexchangsrvr.tradingtechnologies> Message-ID: <3on1cibl0u.fsf@neem.uk.research.att.com> >>>>> Val Goldring (TT) writes: > What will happen if the name or address given is not a real address of the > host? If the ORB is given a host name, it will just use it even if it is not the real address of the host. By use I mean every object reference it is giving out will have that host name in it instead of the real host name. > Another one: Can -ORBpoa_iiop_name_port be used to give one host name or > address and multiple ports? Will they all add up? The option can be given multiple times, the ORB will insert multiple addresses into the object reference it gives out. HOWEVER, there is no guarentee that the client side ORB will diligently try all the addresses in turn. omniORB 4 currently under development will have a better support for multiple addresses and firewall navigation. Sai-Lai -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From S.Lo@uk.research.att.com Tue Jan 23 11:04:51 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 23 Jan 2001 11:04:51 +0000 Subject: [omniORB] Dynamic stub doesn't compile under MSVC (struct inside union inside namespace) In-Reply-To: <200101221824.TAA10174@googleplex.ibp.de> (Lars Immisch's message of "Mon, 22 Jan 2001 19:24:11 +0100") References: <200101221824.TAA10174@googleplex.ibp.de> Message-ID: <3ohf2qbkbw.fsf@neem.uk.research.att.com> Lars, There is a bug in the stub code. The idl compiler backend has treated ParseTree as if it is a module. The correct code should be: #if defined(HAS_Cplusplus_Namespace) && defined(_MSC_VER) // MSVC++ does not give the constant external linkage otherwise. namespace test { const CORBA::TypeCode_ptr ParseTree::_tc_Exp = _0RL_tc_test_mParseTree_mExp; } #else I have not checked recently but the work around is really needed or else you create a DLL out of this code and the symbol for the constant will be missing. Fix to the compiler will be checked-in to the CVS later. Regards, Sai-Lai >>>>> Lars Immisch writes: > Dear all, > I have a problem with the code generated from the following idl file. > The idl file is a stripped down version of my real definition, don't be > surprised it's not very useful in itself. > module test > { > enum TermType > { > terminal, > expression > }; > enum Operator > { > plus, > minus > }; > union ParseTree switch(TermType) > { > case terminal: > long digit; > case expression: > struct Exp > { > Operator op; > sequence operands; > } ex; > }; > }; > When I compile the resulting DynSK.cpp file, I get an error on the second line > of the following code snippet; MSVC complains that test_ParseTree does not > exist or is not a namespace. > namespace test_ParseTree = test::ParseTree; > namespace test_ParseTree { > const CORBA::TypeCode_ptr _tc_Exp = _0RL_tc_test_mParseTree_mExp; > } > These two lines seem to be a workaround specifically for MSVC, since the > enclosing lines read: > #if defined(HAS_Cplusplus_Namespace) && defined(_MSC_VER) > // MSVC++ does not give the constant external linkage otherwise. > namespace test_ParseTree = test::ParseTree; > namespace test_ParseTree { > const CORBA::TypeCode_ptr _tc_Exp = _0RL_tc_test_mParseTree_mExp; > } > #else > const CORBA::TypeCode_ptr test::ParseTree::_tc_Exp = _0RL_tc_test_mParseTree_mExp; > #endif > The workaround is to remove the workaround in the DynSK.cpp file :-) > Trying to understand why the workaround exists in the first place, I tried to > reference CORBA::TypeCode_ptr test::ParseTree::_tc_Exp in another .cpp file > after removing the workaround and that compiled and linked ok. >> From the comment, I was assuming I would get a linker error. > I have applied Service Pack 3 to my VC++ 6.0, maybe the behaviour is not > consistent across versions? > I'd appreciate any comments. -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From tran15@rohan.sdsu.edu Tue Jan 23 17:44:54 2001 From: tran15@rohan.sdsu.edu (Malcom X.) Date: Tue, 23 Jan 2001 09:44:54 -0800 (PST) Subject: [omniORB] Naming Service problems on NT4 In-Reply-To: <412569DD.0038AFB8.00@demalng2.goc.adtranz.com> Message-ID: Try this... 1. set OMNIORB_LOGDIR to points to your log dir (eg set OMNIORB_LOGDIR=c:\omni\log) 2. set OMNIORB_CONFIG to point to the CFG FILENAME (not only the dir) (set OMNIOB_LOGDIR=c:\omni\etc\omniORB.cfg) 3. your CFG file looks OK. all you really need in the CFG is the OmniInitRef NameService=corbaname::localhost:2809 if you have the name service running on the same machine as eg3. You can comment out the rest On Tue, 23 Jan 2001, Jonas Reimers wrote: > - > omniORB 3.02 > WIN NT 4.0 sp6 > MSVC++ 5.0 sp3 > > > I am trying to run the eg3 examples but all I gets is: > > Caught CORBA::SystemException. > > My omniORB.cfg file looks like follows: > > # omniOrb configuration file - basic options > # > ORBInitRef NameService=corbaname::GBGPC0019:2809 > #ORBDefaultInitRef corbaname::GBGPC0019#services > NAMESERVICE > IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4................................ > #ORBInitialHost GBGPC0019 > #ORBInitialPort 2809 > > The IOR string is also available in the registry. > > I have set the enviroment variables OMNIORB_LOGDIR and OMNIORB_CONFIG to point > to my log and cfg directories. > > Any ideas? > > /Jonas Reimers > > > From lars@ibp.de Tue Jan 23 23:18:36 2001 From: lars@ibp.de (Lars Immisch) Date: Wed, 24 Jan 2001 00:18:36 +0100 Subject: [omniORB] compile problems on Win32, NT4 Message-ID: <200101232318.AAA11443@googleplex.ibp.de> Dear all, I updated my cvs repository to the latest omni3_develop branch to see whether it had the bugfix Sai-Lai mentioned earlier today. I then tried to compile the latest version, but failed. During the make, omniidl dumped core (figuratively). Just before it did, the message: omnicpp: stdout: Bad file descriptor appeared. The stack backtrace from Dev Studio pointed to yy_get_next_buffer from idl.ll, but the line numbers seemed to be out of sync I then tried two things: - I did a fresh checkout on the omni3_0_2 branch - I removed my latest cygwin installation and replaced it with the minimal gnuwin32 environment from ftp://ftp.uk.research.att.compub/omniORB/gnu-win32-lite.zip. I removed all cygwin registry entries and files before I installed that version. Neither worked. omniidl keeps crashing at the same point and I am running out of ideas. In the past, I had compiled the omni3_0_2 branch successfully. Since then, I have updated my cygwin environment to the latest version, but I went back to an older version to eliminate that discrepancy. I would appreciate any comments. On a side note, I have problems with 'make clean' when run from $OMNI_ROOT/src. make clean does not finish. It complains in src/lib/omniORB2/orbcore/debug: 'No rule to make target 'clean'. Stop.' Thanks, Lars From jnye@nbnet.nb.ca Tue Jan 23 21:18:28 2001 From: jnye@nbnet.nb.ca (Jason Nye) Date: Tue, 23 Jan 2001 21:18:28 +0000 Subject: [omniORB] Licensing Issues Message-ID: <01012321182800.01109@mithrandir> Hi all, I know that there is a question about this in the FAQ, but I am trying to be as paranoid as possible over this. Here is a description of the project I am working on (I am the software architect): My company provides turnkey solutions for the optics industry -- machines that process eyeglass lenses. These machines are considered 'black boxes' -- you turn them on, they run, you turn them off when you're done. The architecture of the software that controls this system has to be distributed for proper process management, monitoring etc. I did an evaluation of many products (including DCOM which is an absolute mess) and my final decision is omniORB due to its excellent price ;) and its performance. We weren't looking for umpteen million CORBA services -- in fact, the plan is that we are not even going to have a naming service! We were just looking for bare bones features so we did not have to spend our time coding TCP/IP messages manually and creating proprietary protocols -- we needed to be able to develop this quickly. That being said, our customers are not really software users. They care that these machines have high uptimes and they care about the numbers at the end of the day. When the machine gets installed at a customer site, the LGPL will be included with the release notes and any of our licenses. The customer will know that omniORB is the foundation on which the machines run and they will know that if they have a programming staff, they are free to change the source of omniORB at will to provide further functionality or fix bugs. However, our source code is by NO MEANS available at any cost. We have physicists working on optical problems and providing software solutions that cannot be disclosed because of the amount of $$ invested and for intellectual property reasons. Our software will be distributed to customers along with the omniORB run-time libraries. Is there anything I've missed in my interpretation of how your omniORB is licensed? My understanding is that our code can remain closed as long as we tell our customers that we are using omniORB and that they are free to change the omniORB source and since it is a dll, the changes will automatically work with our software. I don't want to open up a bag of licensing issues that force us to open our sourcecode and give all our secrets away which we absolutely cannot afford. Thanks for your help, Jason. From MKeay@SeeBeyond.com Wed Jan 24 01:16:11 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Tue, 23 Jan 2001 17:16:11 -0800 Subject: [omniORB] CORBA::COMM_FAILURE Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC2C@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C085A3.3D0A9100 Content-Type: text/plain; charset="iso-8859-1" Thanks for the prompt reply. I have been able to step through my code and I am able to determine the following. The server object process is started. The server object process is terminated when the client side attempts to invoke the relevant method. Any ideas? Mikey -----Original Message----- From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com] Sent: Tuesday, January 23, 2001 2:44 AM To: Michael Keay Cc: omniorb-list@uk.research.att.com Subject: Re: [omniORB] CORBA::COMM_FAILURE Here is what happened: 1. ORB starts up and was given "GAPS1" port 7655 to resolve initial references. It managed to the root naming context from GAPS1. 2. May be a lookup is done to the naming service to get an object reference of type ZImporter. This also succeeded. Notice that this step is not shown on the trace. I'm just guessing. 3. The application involves on the ZImporter object. The ORB issues a locate request. It tries to connect to the remote address space where the ZImporter resides and failed. A COMM_FAILURE is then raised. You should check wheter you indeed have a ZImporter object running somewhere and it has been registered with the naming service. Sai-Lai >>>>> Michael Keay writes: > Further to this e-mail I was able to switch on tracing an extrapolate the > following information > omniORB: strand Rope::incrRefCount: old value = 0 > omniORB: Creating ref to remote: key<0x494e4954> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: omg.org/CORBA/InitialReferences:1.0 > omniORB: Initialising omniDynamic library. > omniORB: Trying to resolve initial reference `NameService' > with boot agent: > IOR:01000000240000006f6d672e6f72672f434f5242412f496e697469616c5265666572656e > 6365733a312e30000100000000000000180000000101000006000000474150533100e71d0400 > 0000494e4954 > omniORB: strand Ripper: start. > omniORB: scavenger : start. > omniORB: strand Rope::incrRefCount: old value = 0 > omniORB: Creating ref to remote: key<0x4e616d6553657276696365> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0 > omniORB: Initial reference `NameService' resolved with boot agent. > omniORB: LocateRequest to remote: key<0x4e616d6553657276696365> > omniORB: strand Rope::incrRefCount: old value = 0 > omniORB: Creating ref to remote: boa<0x3a6cc44d905f85c600000002> > target id : IDL:omg.org/CORBA/Object:1.0 > most derived id: IDL:ZImporter:1.0 > omniORB: LocateRequest to remote: boa<0x3a6cc44d905f85c600000002> > omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1067 > omniORB: tcpSocketStrand::~Strand() close socket no. 208 > omniORB: defaultTransientExceptionHandler: retry 0th times. > omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1091 > omniORB: tcpSocketStrand::~Strand() close socket no. 4294967295 > omniORB: throw COMM_FAILURE from remoteIdentity.cc:181 > omniORB: Preparing to shutdown ORB. > omniORB: Deinitialising omniDynamic library. > omniORB: omniRemoteIdentity deleted. > omniORB: strand Rope::decrRefCount: old value = 1 > omniORB: ObjRef(omg.org/CORBA/InitialReferences:1.0) -- deleted. > omniORB: scavenger : woken by poke() > omniORB: scavenger : exit. > omniORB: strand Ripper: exit. > omniORB: ORB shutdown is complete. > omniORB: No more references to the ORB -- deleted. > Can anyone explain what we is going on here? > -----Original Message----- > From: Michael Keay [mailto:MKeay@SeeBeyond.com] > Sent: Monday, January 22, 2001 3:03 PM > To: Omniorb-List@Uk. Research. Att. Com (E-mail) > Subject: [omniORB] CORBA::COMM_FAILURE > We have been working on a project, to connect to a thirdparty system. We are > getting a COMM_FAILURE exception when trying to invoke a method on an object > reference. But we do have a valid object reference. Yet, when we use the > supplied, sample client, everything works fine. Does, anyone have any idea > why we would experience such an exception? > I have read the manual that comes with omni orb and it suggests to keep > retrying, but this does not explain what is happening, each and everytime. > Server on Solaris, client on NT, using omniorb 3.0.1 > Mikey -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND ------_=_NextPart_001_01C085A3.3D0A9100 Content-Type: text/html; charset="iso-8859-1" RE: [omniORB] CORBA::COMM_FAILURE

Thanks for the prompt reply.

I have been able to step through my code and I am able to determine the following.

The server object process is started.
The server object process is terminated when the client side attempts to invoke the relevant method.

Any ideas?

Mikey
-----Original Message-----
From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com]
Sent: Tuesday, January 23, 2001 2:44 AM
To: Michael Keay
Cc: omniorb-list@uk.research.att.com
Subject: Re: [omniORB] CORBA::COMM_FAILURE

Here is what happened:

1. ORB starts up and was given "GAPS1" port 7655 to resolve initial
references. It managed to the root naming context from GAPS1.

2. May be a lookup is done to the naming service to get an object reference
of type ZImporter. This also succeeded. Notice that this step is not
shown on the trace. I'm just guessing.

3. The application involves on the ZImporter object. The ORB issues a
locate request. It tries to connect to the remote address space where
the ZImporter resides and failed. A COMM_FAILURE is then raised.

You should check wheter you indeed have a ZImporter object running somewhere
and it has been registered with the naming service.

Sai-Lai

>>>>> Michael Keay writes:

> Further to this e-mail I was able to switch on tracing an extrapolate the
> following information

> omniORB: strand Rope::incrRefCount: old value = 0
> omniORB: Creating ref to remote: key<0x494e4954>
> target id      : IDL:omg.org/CORBA/Object:1.0
> most derived id: omg.org/CORBA/InitialReferences:1.0
> omniORB: Initialising omniDynamic library.
> omniORB: Trying to resolve initial reference `NameService'
> with boot agent:
> IOR:01000000240000006f6d672e6f72672f434f5242412f496e697469616c5265666572656e
> 6365733a312e30000100000000000000180000000101000006000000474150533100e71d0400
> 0000494e4954
> omniORB: strand Ripper: start.
> omniORB: scavenger : start.
> omniORB: strand Rope::incrRefCount: old value = 0
> omniORB: Creating ref to remote: key<0x4e616d6553657276696365>
> target id      : IDL:omg.org/CORBA/Object:1.0
> most derived id: IDL:omg.org/CosNaming/NamingContextExt:1.0
> omniORB: Initial reference `NameService' resolved with boot agent.
> omniORB: LocateRequest to remote: key<0x4e616d6553657276696365>
> omniORB: strand Rope::incrRefCount: old value = 0
> omniORB: Creating ref to remote: boa<0x3a6cc44d905f85c600000002>
> target id      : IDL:omg.org/CORBA/Object:1.0
> most derived id: IDL:ZImporter:1.0
> omniORB: LocateRequest to remote: boa<0x3a6cc44d905f85c600000002>
> omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1067
> omniORB: tcpSocketStrand::~Strand() close socket no. 208
> omniORB: defaultTransientExceptionHandler: retry 0th times.
> omniORB: throw omniConnectionBroken from tcpSocketMTfactory.cc:1091
> omniORB: tcpSocketStrand::~Strand() close socket no. 4294967295
> omniORB: throw COMM_FAILURE from remoteIdentity.cc:181
> omniORB: Preparing to shutdown ORB.
> omniORB: Deinitialising omniDynamic library.
> omniORB: omniRemoteIdentity deleted.
> omniORB: strand Rope::decrRefCount: old value = 1
> omniORB: ObjRef(omg.org/CORBA/InitialReferences:1.0) -- deleted.
> omniORB: scavenger : woken by poke()
> omniORB: scavenger : exit.
> omniORB: strand Ripper: exit.
> omniORB: ORB shutdown is complete.
> omniORB: No more references to the ORB -- deleted.

> Can anyone explain what we is going on here?

> -----Original Message-----
> From: Michael Keay [mailto:MKeay@SeeBeyond.com]
> Sent: Monday, January 22, 2001 3:03 PM
> To: Omniorb-List@Uk. Research. Att. Com (E-mail)
> Subject: [omniORB] CORBA::COMM_FAILURE

> We have been working on a project, to connect to a thirdparty system. We are
> getting a COMM_FAILURE exception when trying to invoke a method on an object
> reference. But we do have a valid object reference. Yet, when we use the
> supplied, sample client, everything works fine. Does, anyone have any idea
> why we would experience such an exception?

> I have read the manual that comes with omni orb and it suggests to keep
> retrying, but this does not explain what is happening, each and everytime.

> Server on Solaris, client on NT, using omniorb 3.0.1

> Mikey

--
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND

------_=_NextPart_001_01C085A3.3D0A9100-- From peter.nyquist@tankebolaget.se Wed Jan 24 08:16:52 2001 From: peter.nyquist@tankebolaget.se (Peter Nyquist) Date: Wed, 24 Jan 2001 09:16:52 +0100 Subject: [omniORB] Nested call blocked Message-ID: We have a system with one client/server using omniORB on Linux (A) and another client/server using Visibroker on Windows 2000 (B). In A there are two CORBA objects, Gateway and GatewaySession. In B there are two CORBA objects, ConnectManager and ApplicationSession. At startup, Gateway receives a reference to ConnectManager from the naming service. A client connects to the GatewaySession, which using Gateway's reference calls newConnection(GatewaySession-ref) in ConnectManager. Connect manager passes the GatewaySession-ref to ApplicationSession. No calls are now "hanging". The following nested calls now occur: Visibroker side omniORB side ApplicationSession -----> display(ApplicationSession-ref) -----> GatewaySession ApplicationSession <----- request() <--------------------------< GatewaySession ApplicationSession -----> push() ------------------------------> blocked in omniORB. The push() call does not reach the GatewaySession code. It seems that since omniORB is already processing the display() call, it cannot handle the nested push() call. Is this a correct analysis of the problem? Is this a known problem? Can we set up omniORB to somehow handle this type of nested call? When we run VisiBroker on both sides, it works just fine. Running JavaORB -> omniBroker still shows the same problem. Thanks /Peter ------------------------------------------------------ Peter Nyquist peter.nyquist@tankebolaget.se ph: +46-(0)8-442 96 11, mob: +46-(0)708-104 964 Tankebolaget, Kungstensgatan 21b 2tr, 113 57 Stockholm www.tankebolaget.se / ICQ: 7 615 442 From peter.nyquist@tankebolaget.se Wed Jan 24 08:51:17 2001 From: peter.nyquist@tankebolaget.se (Peter Nyquist) Date: Wed, 24 Jan 2001 09:51:17 +0100 Subject: [omniORB] RE: Nested call blocked Message-ID: Additional information: we run omniORB 3.0.2. Nested calls with better formatting: Visibroker side omniORB side ApplicationSession --> display(AppSess-ref) -> GatewaySession ApplicationSession <-- request() <------------ GatewaySession ApplicationSession --> push() ---------------> blocked in omniORB. /Peter From spinchak@yahoo.com Wed Jan 24 05:20:39 2001 From: spinchak@yahoo.com (Pinchak Stanley) Date: Tue, 23 Jan 2001 21:20:39 -0800 (PST) Subject: [omniORB] packaging omniorb Message-ID: <20010124052039.39855.qmail@web12211.mail.yahoo.com> Hi my name is Stanley Pinchak and I would like to create a debian package of omniorb 3.0.2. There is an older debian package of 2.8.0, which I have been using as an example to create my new package. However since the idl compiler change and other changes between the 2.8 and 3.0 branches, many of the libraries have changed, disappeared, or been newly created. The format of the old package split omniorb into 3 parts, a document package (containing the examples and user guide) , a development package (containing the headers, .a libraries, and the old omniidl2 and its man page) and and a runtime/binary package (containing the utilities and binaries except omniidl2, and the runtime libraries and their man pages). If you can help me out with the new library names or are interested in helping me package this, I would appreciate it. I am mainly interested in which libraries are necessary to run an application which has been linked to omniorb. Any ponters to other unix or linux packages of omniorb would be helpful. The contents of the older debian packages is listed below. Thank you for your time. Stanley Pinchak spinchak@yahoo.com DOCUMENT PACKAGE examples from the examples directory, repackaged to be built with the development package user documents from the doc directory copyright DEVELOPMENT PACKAGE binaries omniidl2 libraries all of the .a libraries header files all of the header files from the include directory manpages omniidl manpage misc documents copyright README.FIRST RUNTIME/BINARIES PACKAGE binaries catior convertior genior nameclt omkdepend omniNames libraries libomniDynamic2* libomniLC* libomnithread* libtcpwrapGK*s manpages (man/man1) nameclt.1.gz obuildtree.1.gz omake.1.gz omniNames.1.gz opriv.1.gz catior.1.gz omnils.1.gz genior.1.gz oshadow.1.gz miscellaneous docs README.Unix README.Linux README.egcs README.FIRST CREDITS COPYING COPYING.LIB copyright __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From marc@factoriaX.com Wed Jan 24 16:25:43 2001 From: marc@factoriaX.com (Marc Ordinas i Llopis) Date: Wed, 24 Jan 2001 11:25:43 -0500 Subject: [omniORB] Problems compiling omni4_0_develop Message-ID: <3A6F0207.1050105@factoriaX.com> Hi all, I'm sending this message here as I don't know where else I can get help on this. I'm trying to compile omni4_0_develop as I wanted to try the new codeset features, but I get lots of problems. My development system is RedHat 7 with the last compiler (which works compiling omniORB 3.0.2) and python 2.0 on an Athlon. Just out of CVS, after editing config.mk and i586_linux_2.0_glibc2.1.mk, I try make export in src/. It all goes well until it gets to the omniORB2 directory, where it complains it does not have a 'dir.mk' file. I change dir.mk in src/lib to set the subdirs to 'omnithread' and 'omniORB' instead of 'omniORB2', as per the update.log I think omniORB2 is no longer used. Then it complains that omniORB/ does not have a GNUmakefile, so I copy all the GNUmakefiles from the omniORB2/ dir tree. That seems to work just until it tries to generate the stubs for some files, when python fails (this also happened with python 1.5.2, by the way). It says: make[2]: Entering directory `/home/marc/codi/omni/src/lib/omniORB' ../../../bin/i586_linux_2.0_glibc2.1/omniidl -bcxx -Wba -p../../../src/lib/omniORB -Wbdebug -nf -WbF -ComniORB4 ../../../idl/corbaidl.idl omniidl: fatalError occurred, in debug mode. >> An internal exception was caught Stack: ------------------------- File "../../../bin/i586_linux_2.0_glibc2.1/omniidlrun.py", line 97, in ? omniidl.main.main() File "./main.py", line 422, in main File "../../../src/lib/omniORB/omniidl_be/cxx/__init__.py", line 276, in run Make stubs for the Interface Repository appear in the CORBA module""" File "../../../src/lib/omniORB/omniidl_be/cxx/util.py", line 152, in fatalError Exception: ------------------------- Traceback (most recent call last): File "../../../src/lib/omniORB/omniidl_be/cxx/__init__.py", line 248, in run """cdrUnmarshal(TypeCode, string) -> data File "/home/marc/codi/omni/src/lib/omniORB/omniidl_be/cxx/header/__init__.py", line 280, in run defs_fragment(defs_stream, tree) File "/home/marc/codi/omni/src/lib/omniORB/omniidl_be/cxx/header/__init__.py", line 140, in defs_fragment import omniidl_be.cxx.header.defs ImportError: No module named defs make[2]: *** [omniORB4/corbaidl_defs.hh] Error 1 make[2]: Leaving directory `/home/marc/codi/omni/src/lib/omniORB' make[1]: *** [export] Error 1 I've tried anything I've been able to think of to get it to include defs, but even as I can import it in an interactive session, I'm unable to make it work. And by the way, I think there's an error in src/lib/omniORB/dir.mk, some files are not prepended the directory omniORB4. Here's the diff : Index: dir.mk =================================================================== RCS file: /cvsroot/omni/src/lib/omniORB/Attic/dir.mk,v retrieving revision 1.7.2.5 diff -r1.7.2.5 dir.mk 66c66 < omniORB4/corbaidl_defs.hh corbaidl_operators.hh corbaidl_poa.hh: corbaidl.idl --- > omniORB4/corbaidl_defs.hh omniORB4/corbaidl_operators.hh omniORB4/corbaidl_poa.hh: corbaidl.idl Thanks for any help, Marc Ordinas i Llopis, factoriaX From S.Lo@uk.research.att.com Wed Jan 24 10:42:52 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 24 Jan 2001 10:42:52 +0000 Subject: [omniORB] Licensing Issues In-Reply-To: <01012321182800.01109@mithrandir> (Jason Nye's message of "Tue, 23 Jan 2001 21:18:28 +0000") References: <01012321182800.01109@mithrandir> Message-ID: <3oofwx2pub.fsf@neem.uk.research.att.com> Jason, Your interpretation of the licensing terms is correct. If you want an example of how a shrink-wrapped product satifies omniORB's license requirements, have a look at Adobe Messenger's page: http://www.adobe.com/products/acrmessenger/main.html and http://www.adobe.com/support/downloads/6012.htm Thank you for letting us know about your use of omniORB in your product. Although it is not a requirement, it would be helpful if all omniORB users can keep us informed on the product they have used omniORB successfully. The information is useful for us to chart our future development plan. Our management is also keen to know how well omniORB is doing in the open source software world. Some concrete supporting data are very useful. Regards, Sai-Lai >>>>> Jason Nye writes: > Hi all, > I know that there is a question about this in the FAQ, but I am trying to be > as paranoid as possible over this. > Here is a description of the project I am working on (I am the software > architect): > My company provides turnkey solutions for the optics industry -- machines > that process eyeglass lenses. These machines are considered 'black boxes' > -- you turn them on, they run, you turn them off when you're done. > The architecture of the software that controls this system has to be > distributed for proper process management, monitoring etc. I did an > evaluation of many products (including DCOM which is an absolute mess) > and my final decision is omniORB due to its excellent price ;) and its > performance. We weren't looking for umpteen million CORBA services -- in > fact, the plan is that we are not even going to have a naming service! We > were just looking for bare bones features so we did not have to spend our > time coding TCP/IP messages manually and creating proprietary protocols > -- we needed to be able to develop this quickly. > That being said, our customers are not really software users. They care > that these machines have high uptimes and they care about the numbers at > the end of the day. When the machine gets installed at a customer site, > the LGPL will be included with the release notes and any of our > licenses. The customer will know that omniORB is the foundation on which > the machines run and they will know that if they have a programming > staff, they are free to change the source of omniORB at will to provide > further functionality or fix bugs. However, our source code is by NO > MEANS available at any cost. We have physicists working on optical > problems and providing software solutions that cannot be disclosed > because of the amount of $$ invested and for intellectual property > reasons. > Our software will be distributed to customers along with the omniORB > run-time libraries. Is there anything I've missed in my interpretation of > how your omniORB is licensed? My understanding is that our code can > remain closed as long as we tell our customers that we are using omniORB > and that they are free to change the omniORB source and since it is a > dll, the changes will automatically work with our software. I don't want > to open up a bag of licensing issues that force us to open our sourcecode > and give all our secrets away which we absolutely cannot afford. -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From S.Lo@uk.research.att.com Wed Jan 24 11:00:37 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 24 Jan 2001 11:00:37 +0000 Subject: [omniORB] Nested call blocked In-Reply-To: (Peter Nyquist's message of "Wed, 24 Jan 2001 09:16:52 +0100") References: Message-ID: <3od7dd2p0q.fsf@neem.uk.research.att.com> It may be the case that Visibroker is using the same tcp connection to sent the "display()" and the "push()" request. If that is the case, omniORB will not see the push request because there is only 1 thread dispatched to serve one connection. The thread is in the process of waiting for the reply to "request()". Unless you can tell visibroker to have at most 1 outstanding request per connection, I'm afraid we have an interoperability problem here. If you can, I suggest you break the long nested call chain. Either by 1. in display() spawn another thread to do request() and then return immediately. OR 2. in request(), spawn another thread to do push() and then return immediately. In omniORB4 currently under development, we'll address this issue. Sai-Lai >>>>> Peter Nyquist writes: > We have a system with one client/server using omniORB on Linux (A) > and another client/server using Visibroker on Windows 2000 (B). > In A there are two CORBA objects, Gateway and GatewaySession. > In B there are two CORBA objects, ConnectManager and ApplicationSession. > At startup, Gateway receives a reference to ConnectManager from the naming > service. > A client connects to the GatewaySession, which using Gateway's reference > calls newConnection(GatewaySession-ref) in ConnectManager. Connect manager > passes the GatewaySession-ref to ApplicationSession. No calls are now > "hanging". > The following nested calls now occur: > Visibroker side omniORB > side > ApplicationSession -----> display(ApplicationSession-ref) -----> > GatewaySession > ApplicationSession <----- request() <--------------------------< > GatewaySession > ApplicationSession -----> push() ------------------------------> blocked in > omniORB. > The push() call does not reach the GatewaySession code. > It seems that since omniORB is already processing the display() call, it > cannot handle the > nested push() call. Is this a correct analysis of the problem? Is this a > known problem? > Can we set up omniORB to somehow handle this type of nested call? > When we run VisiBroker on both sides, it works just fine. Running JavaORB -> > omniBroker still > shows the same problem. > Thanks -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From r.vd.leek@fokkerspace.nl Wed Jan 24 12:05:12 2001 From: r.vd.leek@fokkerspace.nl (Rob van der Leek) Date: Wed, 24 Jan 2001 13:05:12 +0100 Subject: [omniORB] Nested call blocked References: <3od7dd2p0q.fsf@neem.uk.research.att.com> Message-ID: <3A6EC4F8.D1E5A5B7@fokkerspace.nl> My problem is kind of similar to the one Peter reported. I have already posted a msg to the list about it. In short this is my situation: 1. Client1 -- push(event) --> EventChannel --- push(event) --> Server 2. Server incarnates an object factory, the server's push handler creates a new object and calls some methods on that object. The method invocations take some time to complete. 3. Client2 -- push(event) --> EventChannel --- push(event) --> Server 4. Now Client2 has to wait for the push handler to return (since the ORB controlled thread policy in OmniORB is implemented as thread-per-object, and there's only one server object). Duncan Grisby corrected my assumptions in step 4 and told me OmniORB's thread policy is thread per connection. Duncan also told me that the EventChannel should open a new connection, so the server will use a different thread. This thread model is exactly what I'm looking for since I try to avoid threading as much as possible in my own apps... _but_, my push server still blocks on the method invocation after receiving a push event, other push events are queued untill the server returns from the push handler. What am I missing here? Could it be possible that all push events for a server are send from the EventChannel using the same tcp connection (wild guess)? Please let me know if you need a small test implementation to see how I did things. I'm using OmniORB 3.02 + OmniNotify 1.1b1 on a RH 6 Linux system. TIA, Rob Sai-Lai Lo wrote: > > It may be the case that Visibroker is using the same tcp connection to sent > the "display()" and the "push()" request. If that is the case, omniORB will > not see the push request because there is only 1 thread dispatched to serve > one connection. The thread is in the process of waiting for the reply to > "request()". > > Unless you can tell visibroker to have at most 1 outstanding request per > connection, I'm afraid we have an interoperability problem here. > > If you can, I suggest you break the long nested call chain. Either by > > 1. in display() spawn another thread to do request() and then return > immediately. > > OR > > 2. in request(), spawn another thread to do push() and then return > immediately. > > In omniORB4 currently under development, we'll address this issue. > > Sai-Lai > > >>>>> Peter Nyquist writes: > > > We have a system with one client/server using omniORB on Linux (A) > > and another client/server using Visibroker on Windows 2000 (B). > > > In A there are two CORBA objects, Gateway and GatewaySession. > > In B there are two CORBA objects, ConnectManager and ApplicationSession. > > > At startup, Gateway receives a reference to ConnectManager from the naming > > service. > > > A client connects to the GatewaySession, which using Gateway's reference > > calls newConnection(GatewaySession-ref) in ConnectManager. Connect manager > > passes the GatewaySession-ref to ApplicationSession. No calls are now > > "hanging". > > > The following nested calls now occur: > > > Visibroker side omniORB > > side > > > ApplicationSession -----> display(ApplicationSession-ref) -----> > > GatewaySession > > ApplicationSession <----- request() <--------------------------< > > GatewaySession > > ApplicationSession -----> push() ------------------------------> blocked in > > omniORB. > > > The push() call does not reach the GatewaySession code. > > > It seems that since omniORB is already processing the display() call, it > > cannot handle the > > nested push() call. Is this a correct analysis of the problem? Is this a > > known problem? > > Can we set up omniORB to somehow handle this type of nested call? > > > When we run VisiBroker on both sides, it works just fine. Running JavaORB -> > > omniBroker still > > shows the same problem. > > > Thanks > > -- > Sai-Lai Lo S.Lo@uk.research.att.com > AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com > 24a Trumpington Street Tel: +44 1223 343000 > Cambridge CB2 1QA Fax: +44 1223 313542 > ENGLAND From peter.nyquist@tankebolaget.se Wed Jan 24 12:33:27 2001 From: peter.nyquist@tankebolaget.se (Peter Nyquist) Date: Wed, 24 Jan 2001 13:33:27 +0100 Subject: [omniORB] Nested call blocked Message-ID: VisiBroker is smart and only opens one single connection if possible... So omniORB will block on nested calls. But I'm doing another type of nested call that works: A --> call_x() --> B1 A <-- call_y() <-- B1 A --> call_x() --> B2 A <-- call_y() <-- B2 Even though call_y() from B1 to A is on-going, call_y() from B2 to A works. What is the explanation for this? Is VisiBroker opening a new connection for B2? Is it possible to use this fact to get around the earlier problem? Note: I'm still learning CORBA basics, so most of these issues are new to me. /Peter > > My problem is kind of similar to the one Peter reported. I > have already > posted a msg to the list about it. In short this is my situation: > > 1. Client1 -- push(event) --> EventChannel --- push(event) --> Server > > 2. Server incarnates an object factory, the server's push handler > creates a new object and calls some methods on that object. The method > invocations take some time to complete. > > 3. Client2 -- push(event) --> EventChannel --- push(event) --> Server > > 4. Now Client2 has to wait for the push handler to return > (since the ORB > controlled thread policy in OmniORB is implemented as > thread-per-object, > and there's only one server object). > > Duncan Grisby corrected my assumptions in step 4 and told me OmniORB's > thread policy is thread per connection. Duncan also told me that the > EventChannel should open a new connection, so the server will use a > different thread. This thread model is exactly what I'm looking for > since I try to avoid threading as much as possible in my own apps... > > _but_, my push server still blocks on the method invocation after > receiving a push event, other push events are queued untill the server > returns from the push handler. What am I missing here? Could it be > possible that all push events for a server are send from the > EventChannel using the same tcp connection (wild guess)? > > Please let me know if you need a small test implementation to > see how I > did things. > > I'm using OmniORB 3.02 + OmniNotify 1.1b1 on a RH 6 Linux system. > > TIA, > Rob > > > Sai-Lai Lo wrote: > > > > It may be the case that Visibroker is using the same tcp > connection to sent > > the "display()" and the "push()" request. If that is the > case, omniORB will > > not see the push request because there is only 1 thread > dispatched to serve > > one connection. The thread is in the process of waiting for > the reply to > > "request()". > > > > Unless you can tell visibroker to have at most 1 > outstanding request per > > connection, I'm afraid we have an interoperability problem here. > > > > If you can, I suggest you break the long nested call chain. > Either by > > > > 1. in display() spawn another thread to do request() and then return > > immediately. > > > > OR > > > > 2. in request(), spawn another thread to do push() and then return > > immediately. > > > > In omniORB4 currently under development, we'll address this issue. > > > > Sai-Lai > > > > >>>>> Peter Nyquist writes: > > > > > We have a system with one client/server using omniORB on Linux (A) > > > and another client/server using Visibroker on Windows 2000 (B). > > > > > In A there are two CORBA objects, Gateway and GatewaySession. > > > In B there are two CORBA objects, ConnectManager and > ApplicationSession. > > > > > At startup, Gateway receives a reference to > ConnectManager from the naming > > > service. > > > > > A client connects to the GatewaySession, which using > Gateway's reference > > > calls newConnection(GatewaySession-ref) in > ConnectManager. Connect manager > > > passes the GatewaySession-ref to ApplicationSession. No > calls are now > > > "hanging". > > > > > The following nested calls now occur: > > > > > Visibroker side > omniORB > > > side > > > > > ApplicationSession -----> display(ApplicationSession-ref) -----> > > > GatewaySession > > > ApplicationSession <----- request() <--------------------------< > > > GatewaySession > > > ApplicationSession -----> push() > ------------------------------> blocked in > > > omniORB. > > > > > The push() call does not reach the GatewaySession code. > > > > > It seems that since omniORB is already processing the > display() call, it > > > cannot handle the > > > nested push() call. Is this a correct analysis of the > problem? Is this a > > > known problem? > > > Can we set up omniORB to somehow handle this type of nested call? > > > > > When we run VisiBroker on both sides, it works just fine. > Running JavaORB -> > > > omniBroker still > > > shows the same problem. > > > > > Thanks > > > > -- > > Sai-Lai Lo > S.Lo@uk.research.att.com > > AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com > 24a Trumpington Street Tel: +44 1223 343000 > Cambridge CB2 1QA Fax: +44 1223 313542 > ENGLAND From S.Lo@uk.research.att.com Wed Jan 24 12:51:25 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 24 Jan 2001 12:51:25 +0000 Subject: [omniORB] Nested call blocked In-Reply-To: <3A6EC4F8.D1E5A5B7@fokkerspace.nl> (Rob van der Leek's message of "Wed, 24 Jan 2001 13:05:12 +0100") References: <3od7dd2p0q.fsf@neem.uk.research.att.com> <3A6EC4F8.D1E5A5B7@fokkerspace.nl> Message-ID: <3o1ytt2jw2.fsf@neem.uk.research.att.com> Your scenerio is different. As a client, omniORB do not let more that one call outstanding per connection. If it needs to dispatch 2 calls to the same address space, it opens 2 connection if necessary. In the previous mail, the client is not omniORB, hence the difference. Sai-Lai >>>>> Rob van der Leek writes: > My problem is kind of similar to the one Peter reported. I have already > posted a msg to the list about it. In short this is my situation: > 1. Client1 -- push(event) --> EventChannel --- push(event) --> Server > 2. Server incarnates an object factory, the server's push handler > creates a new object and calls some methods on that object. The method > invocations take some time to complete. > 3. Client2 -- push(event) --> EventChannel --- push(event) --> Server > 4. Now Client2 has to wait for the push handler to return (since the ORB > controlled thread policy in OmniORB is implemented as thread-per-object, > and there's only one server object). > Duncan Grisby corrected my assumptions in step 4 and told me OmniORB's > thread policy is thread per connection. Duncan also told me that the > EventChannel should open a new connection, so the server will use a > different thread. This thread model is exactly what I'm looking for > since I try to avoid threading as much as possible in my own apps... > _but_, my push server still blocks on the method invocation after > receiving a push event, other push events are queued untill the server > returns from the push handler. What am I missing here? Could it be > possible that all push events for a server are send from the > EventChannel using the same tcp connection (wild guess)? > Please let me know if you need a small test implementation to see how I > did things. > I'm using OmniORB 3.02 + OmniNotify 1.1b1 on a RH 6 Linux system. -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From r.vd.leek@fokkerspace.nl Wed Jan 24 15:18:53 2001 From: r.vd.leek@fokkerspace.nl (Rob van der Leek) Date: Wed, 24 Jan 2001 16:18:53 +0100 Subject: [omniORB] Nested call blocked References: <3od7dd2p0q.fsf@neem.uk.research.att.com> <3A6EC4F8.D1E5A5B7@fokkerspace.nl> <3o1ytt2jw2.fsf@neem.uk.research.att.com> Message-ID: <3A6EF25D.F5E5467D@fokkerspace.nl> So, if two push clients trigger each an event for the same server and the push handler takes a few seconds to complete, OmniORB would open 2 connections from the EventChannel to the push server (and thus creates two connection handling threads at the server side)? I'll try to show what I mean with the examples from the Notify package. I suspend the push handler for a few seconds: examples/sample_functions.cc: ... void sample_consume_any_fn (const CORBA::Any& event, const char* obj_name, const CORBA::ULong event_num, CORBA::Boolean verbose ) { CORBA::ULong ul; if (event >>= ul) { if (verbose) cout << obj_name << ": event data = " << ul << ", event count = " << event_num << endl; sleep(5); } else { if (verbose) cout << obj_name << ": event data not known (not a ULong), event count = " << event_num << endl; } } ... I compile the legacy_push_consumer and start it in an xterm: $ ./legacy_push_consumer -d 6 -v Then I simultaniously start two push client in separate xterms: ./legacy_push_supplier -d 3 -m 1000 -v The consumer output is: Waiting for desired # of events legacy_push_consumer: event data = 1, event count = 1 # 5 sec. wait legacy_push_consumer: event data = 1, event count = 2 # 5 sec. wait legacy_push_consumer: event data = 2, event count = 3 # ... legacy_push_consumer: event data = 2, event count = 4 legacy_push_consumer: event data = 3, event count = 5 legacy_push_consumer: event data = 3, event count = 6 The whole run takes 30 seconds to complete, from which I conclude that the events are serialized at the server side. regards, rob Sai-Lai Lo wrote: > > Your scenerio is different. As a client, omniORB do not let more that one > call outstanding per connection. If it needs to dispatch 2 calls to the > same address space, it opens 2 connection if necessary. > > In the previous mail, the client is not omniORB, hence the difference. > > Sai-Lai > > >>>>> Rob van der Leek writes: > > > My problem is kind of similar to the one Peter reported. I have already > > posted a msg to the list about it. In short this is my situation: > > > 1. Client1 -- push(event) --> EventChannel --- push(event) --> Server > > > 2. Server incarnates an object factory, the server's push handler > > creates a new object and calls some methods on that object. The method > > invocations take some time to complete. > > > 3. Client2 -- push(event) --> EventChannel --- push(event) --> Server > > > 4. Now Client2 has to wait for the push handler to return (since the ORB > > controlled thread policy in OmniORB is implemented as thread-per-object, > > and there's only one server object). > > > Duncan Grisby corrected my assumptions in step 4 and told me OmniORB's > > thread policy is thread per connection. Duncan also told me that the > > EventChannel should open a new connection, so the server will use a > > different thread. This thread model is exactly what I'm looking for > > since I try to avoid threading as much as possible in my own apps... > > > _but_, my push server still blocks on the method invocation after > > receiving a push event, other push events are queued untill the server > > returns from the push handler. What am I missing here? Could it be > > possible that all push events for a server are send from the > > EventChannel using the same tcp connection (wild guess)? > > > Please let me know if you need a small test implementation to see how I > > did things. > > > I'm using OmniORB 3.02 + OmniNotify 1.1b1 on a RH 6 Linux system. > > -- > Sai-Lai Lo S.Lo@uk.research.att.com > AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com > 24a Trumpington Street Tel: +44 1223 343000 > Cambridge CB2 1QA Fax: +44 1223 313542 > ENGLAND From S.Lo@uk.research.att.com Wed Jan 24 18:33:18 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 24 Jan 2001 18:33:18 +0000 Subject: [omniORB] compile problems on Win32, NT4 In-Reply-To: <200101232318.AAA11443@googleplex.ibp.de> (Lars Immisch's message of "Wed, 24 Jan 2001 00:18:36 +0100") References: <200101232318.AAA11443@googleplex.ibp.de> Message-ID: <3oofwwztox.fsf@neem.uk.research.att.com> The fix to your previous bug report is now in the repository. I've no idea what is causing the omnicpp problem. We have seem reports about strange behaviours on Windows 98. That seems to do with the use of pipe to send the preprocessor output to omniidl. There is now a -T option to omniidl to tell it to use a temporary file instead of a pipe. You may want to APPEND the following to mk/platforms/x86_nt_4.0.mk: OMNIORB_IDL_ONLY += -T However I should also say that I've never seen this on NT. May be it is time to reboot your box. On the make clean problem. This is a known problem if the gnumake version is older than ~3.77. I've put up a new gun-win32-lite.zip which is based on a later version of cygwin and do come with a later version of gnumake. Mind you, you may have to redo the mount thing again because cygwin uses a different set of registry entry. Regards, Sai-Lai >>>>> Lars Immisch writes: > Dear all, > I updated my cvs repository to the latest omni3_develop branch to see > whether it had the bugfix Sai-Lai mentioned earlier today. > I then tried to compile the latest version, but failed. During the make, > omniidl dumped core (figuratively). Just before it did, the message: > omnicpp: stdout: Bad file descriptor > appeared. The stack backtrace from Dev Studio pointed to yy_get_next_buffer > from idl.ll, but the line numbers seemed to be out of sync > I then tried two things: > - I did a fresh checkout on the omni3_0_2 branch > - I removed my latest cygwin installation and replaced it with the minimal > gnuwin32 environment from > ftp://ftp.uk.research.att.compub/omniORB/gnu-win32-lite.zip. I removed all > cygwin registry entries and files before I installed that version. > Neither worked. omniidl keeps crashing at the same point and I am running > out of ideas. > In the past, I had compiled the omni3_0_2 branch successfully. Since then, > I have updated my cygwin environment to the latest version, but I went back > to an older version to eliminate that discrepancy. > I would appreciate any comments. > On a side note, I have problems with 'make clean' when run from $OMNI_ROOT/src. > make clean does not finish. It complains in src/lib/omniORB2/orbcore/debug: > 'No rule to make target 'clean'. Stop.' > Thanks, > Lars -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From seefeld@sympatico.ca Wed Jan 24 22:19:47 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 24 Jan 2001 17:19:47 -0500 Subject: [omniORB] Synopsis 0.3 released Message-ID: <3A6F5503.5CC0C9B7@sympatico.ca> Synopsis is a source code documentation tool that follows a modular architecture to adapt to different languages, comment styles and output formats. Currently it provides parsers for IDL, C++, and Python, and a number of formatter modules. It has the ability to scale to large projects, and to integrate well with Makefiles to only update documentation for changed files. One of the goals of Synopsis is to integrate the documentation between different languages, for example linking implementations in any language with their CORBA interfaces and vice versa. The main code is written in Python, the C++ parser is a module based on OpenC++, and the IDL parser is a module based on the omniidl tool. Changes: Release 0.3 adds Python support, the ability to cross-reference across language boundaries by means of a flexible linker module, and a formatter for graph generation, based on graphviz. The build process is now autoconf based. Homepage: http://synopsis.sourceforge.net/ Download: http://sourceforge.net/projects/synopsis/ Regards, Stefan From arnault.bonafos@tumbleweed.com Wed Jan 24 23:08:55 2001 From: arnault.bonafos@tumbleweed.com (Arnault Bonafos) Date: Wed, 24 Jan 2001 15:08:55 -0800 Subject: [omniORB] NT & multiple server application with BOAiiop_port sepcified Message-ID: <3A6F6087.7CF07932@tumbleweed.com> --------------1F9AEE06BAC29CDBE6CAB9B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I'm tracing down a problem we discovered when running in parallel two times our sample application. The configuration is NT Server 4.0 + omniORB_2.6.1, and we're specifying the -BOAiiop_port argument to bind on a "well known" port as server. The symptom is that both application do their job but the second one does not quit, it seems that we still have a thread running for the in/out connection scavenger. I've traced down the problem when we ask the BOA to shutdown, CORBA::BOA::impl_shutdown, we end up in tcpSocketIncomingRope::cancelThreads where we want to wake up the rendezvouser thread blocked on an accept call by doing a connect on the socket. Doing so, the thread should exit by itself. The point is that the first program wakes up by this connect call the thread in the second program, but not itself, and then later we're blocked on the call rendezvouser->join(0) in the cancelThread function in the first program. So my questions are: 1. should the connect call (I've tried to loop, only one is sucessfull) wake up all the accept calls 2. is it possible that my wsock32.dll library is buggy ? 3. should the orb kill all the threads somewhere else ? (I've read about a NT dll global destructor function). One solution to my problem is to use a different port for every application, in which case each thread is unblocked seprately. -- Arnault Bonafos Software Engineer Tumbleweed Communications Corp. ph: (650) 216-2027 fx: (650) 216-2003 --------------1F9AEE06BAC29CDBE6CAB9B9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hello,
I'm tracing down a problem we discovered when running in parallel two times our sample application.
The configuration is NT Server 4.0 + omniORB_2.6.1, and we're specifying the -BOAiiop_port argument to bind on a "well known" port as server. The symptom is that both application do their job but the second one does not quit, it seems that we still have a thread running for the in/out connection scavenger.
I've traced down the problem when we ask the BOA to shutdown, CORBA::BOA::impl_shutdown, we end up in tcpSocketIncomingRope::cancelThreads where we want to wake up the rendezvouser thread blocked on an accept call by doing a connect on the socket. Doing so, the thread should exit by itself.

The point is that the first program wakes up by this connect call the thread in the second program, but not itself, and then later we're blocked on the call rendezvouser->join(0) in the cancelThread function in the first program.

So my questions are:
1. should the connect call (I've tried to loop, only one is sucessfull) wake up all the accept calls
2. is it possible that my wsock32.dll library is buggy ?
3. should the orb kill all the threads somewhere else ? (I've read about a NT dll global destructor function).

One solution to my problem is to use a different port for every application, in which case each thread is unblocked seprately.

-- 
Arnault Bonafos     Software Engineer
Tumbleweed    Communications    Corp.
ph: (650) 216-2027  fx: (650) 216-2003

--------------1F9AEE06BAC29CDBE6CAB9B9-- From lars@ibp.de Wed Jan 24 23:41:12 2001 From: lars@ibp.de (Lars Immisch) Date: Thu, 25 Jan 2001 00:41:12 +0100 Subject: [omniORB] compile problems on Win32, NT4 In-Reply-To: <3oofwwztox.fsf@neem.uk.research.att.com> References: <200101232318.AAA11443@googleplex.ibp.de> <3oofwwztox.fsf@neem.uk.research.att.com> Message-ID: <200101242341.AAA12606@googleplex.ibp.de> Hi Sai-Lai, > The fix to your previous bug report is now in the repository. Thanks a lot; I managed to compile omniORB in the meantime and the bug is fixed. > I've no idea what is causing the omnicpp problem. We have seem reports > about strange behaviours on Windows 98. That seems to do with the use of > pipe to send the preprocessor output to omniidl. There is now a -T option > to omniidl to tell it to use a temporary file instead of a pipe. You may > want to APPEND the following to mk/platforms/x86_nt_4.0.mk: > > OMNIORB_IDL_ONLY += -T > > However I should also say that I've never seen this on NT. May be it is > time to reboot your box. By fortunate mistake, I have found out that if I build omniORB *without* the BuildDebugBinary option in mk/config.mk, it works ok. With the BuildDebugBinary option set to 1, omniidl crashes (and this is reproducable). I like having the debug binaries, so I normally enable it by default. Just to let you know, I have experimented with the -T flag and it makes no difference. > On the make clean problem. This is a known problem if the gnumake version > is older than ~3.77. I've put up a new gun-win32-lite.zip which is based on > a later version of cygwin and do come with a later version of gnumake. Thanks. I'll redo the build with my normal cygwin environment now and/or check the latest gnu-win32-lite. - Lars From rodrigc@mediaone.net Thu Jan 25 01:27:43 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Wed, 24 Jan 2001 20:27:43 -0500 Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <3A6F5503.5CC0C9B7@sympatico.ca>; from seefeld@sympatico.ca on Wed, Jan 24, 2001 at 05:19:47PM -0500 References: <3A6F5503.5CC0C9B7@sympatico.ca> Message-ID: <20010124202743.A29575@mediaone.net> Hi, How does this tool compare with doxygen? We have started using doxygen at work, and the output is very nice: http://www.stack.nl/~dimitri/doxygen/ -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From seefeld@sympatico.ca Thu Jan 25 01:50:43 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 24 Jan 2001 20:50:43 -0500 Subject: [omniORB] Synopsis 0.3 released References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> Message-ID: <3A6F8673.8803E4EC@sympatico.ca> Craig Rodrigues wrote: > > Hi, > > How does this tool compare with doxygen? We have started > using doxygen at work, and the output is very nice: > http://www.stack.nl/~dimitri/doxygen/ yeah, I know about doxygen. However, synopsis is written in a different spirit. It's highly modular, in that it lets you plug in new parsers and formatters. I think you are *much* more flexible with this approach. I don't know doxygen's inner workings in detail, I just know that it's all one single tool, i.e. a single parser that needs to know about all the languages, and even document string conventions being used. It wasn't fit for what I wanted it to do, that's why I started synopsis. My main interest is the berlin project, where we have a pretty big base of IDL interfaces and implementations in various languages (notably C++ and python). So I wanted a tool that understands all of them, and can even cross reference between these modules. That's now possible. I don't think that doxygen can do that. In any case, synopsis is still relatively young. A lot of ideas are there and need to be fleshed out. Help is always welcome ! :) A big acknowledgement has to go to Duncan, as his wonderful omniidl implementation provided the basic ideas, I just generalized the AST, and added some plugins around that :) Regards, Stefan From rodrigc@mediaone.net Thu Jan 25 02:26:15 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Wed, 24 Jan 2001 21:26:15 -0500 Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <3A6F8673.8803E4EC@sympatico.ca>; from seefeld@sympatico.ca on Wed, Jan 24, 2001 at 08:50:43PM -0500 References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> <3A6F8673.8803E4EC@sympatico.ca> Message-ID: <20010124212615.A29904@mediaone.net> On Wed, Jan 24, 2001 at 08:50:43PM -0500, Stefan Seefeld wrote: > > In any case, synopsis is still relatively young. A lot of ideas > are there and need to be fleshed out. Help is always welcome ! :) Well, one thing I would suggest is, look at the tags that doxygen supports, and support those in synopsis as well. It is very nice in a software project to standardize on one style of documenting code. For example, the javadoc style is the default style for Java programmers. It is a pain in the neck to change documenting standards to appease the latest documentation generator. :) -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From seefeld@sympatico.ca Thu Jan 25 02:48:40 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 24 Jan 2001 21:48:40 -0500 Subject: [omniORB] Synopsis 0.3 released References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> <3A6F8673.8803E4EC@sympatico.ca> <20010124212615.A29904@mediaone.net> Message-ID: <3A6F9408.70122894@sympatico.ca> Craig Rodrigues wrote: > > On Wed, Jan 24, 2001 at 08:50:43PM -0500, Stefan Seefeld wrote: > > > > In any case, synopsis is still relatively young. A lot of ideas > > are there and need to be fleshed out. Help is always welcome ! :) > > Well, one thing I would suggest is, look at the tags that > doxygen supports, and support those in synopsis as well. > > It is very nice in a software project to standardize on one > style of documenting code. For example, the javadoc style > is the default style for Java programmers. > > It is a pain in the neck to change documenting standards > to appease the latest documentation generator. :) Thanks, you make my point :) Synopsis is modular to the point that you can not only choose between a variety of comment parser/formatters, you can even plugin your own little python script ! (*) And yes, we currently do support javadoc style comments. Among others...:) Indeed, I always found it pretty pervers that people had to adapt to tools. It should be the other way around. Regards, Stefan (*) as an example for the kind of flexibility I'm talking about, I wrote a little python function as an extension to the Linker module. It maps C++ names to their IDL equivalents (POA_Foo maps to Foo, Bar_ptr maps to Bar); I use that to tell the linker how to resolve references, i.e. clicking on 'Bar_ptr' will take you to the definition of the 'Bar' type... From rodrigc@mediaone.net Thu Jan 25 02:58:43 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Wed, 24 Jan 2001 21:58:43 -0500 Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <3A6F9408.70122894@sympatico.ca>; from seefeld@sympatico.ca on Wed, Jan 24, 2001 at 09:48:40PM -0500 References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> <3A6F8673.8803E4EC@sympatico.ca> <20010124212615.A29904@mediaone.net> <3A6F9408.70122894@sympatico.ca> Message-ID: <20010124215843.A29962@mediaone.net> On Wed, Jan 24, 2001 at 09:48:40PM -0500, Stefan Seefeld wrote: > > It is a pain in the neck to change documenting standards > > to appease the latest documentation generator. :) > > Thanks, you make my point :) You're welcome! The other open source ORB I use (TAO) has completely changed over to doxygen style commenting (that's why I know about doxygen). Here is an example of their documentation: http://doc.ece.uci.edu/Doxygen/Beta/html/ And here is an example source file with doxygen comments: http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/ACE.h The TAO project switched from the OSE tools (http://ose.sourceforge.net/) to doxygen, and that required changing all the source code. But doxygen output is pretty nice, so they considered it worth it. Would synopsis be compatible with this format? -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From chalky@null.net Thu Jan 25 03:33:32 2001 From: chalky@null.net (Stephen Davies) Date: Thu, 25 Jan 2001 14:33:32 +1100 (EST) Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <20010124215843.A29962@mediaone.net> Message-ID: Hi Craig, I am the 'other' developer for Synopsis. Version 0.3 includes modular comment parsing and formatting, which has already been used to support the "//." style comments used in Berlin's sources and the "/**" style used by javadoc. On top of this you can also use javadoc-style @tags whatever format you use, although only @see has been implemented so far. Adding further styles is very possible, as is adding other features we do not currently support such as inline inheritance graphs on the Class pages. Indeed, version 0.4 may well support most if not all of doxygen's syntax as another plugin. 0.3 includes a formatter that generates an inheritance diagram as a test of the GraphViz (the same tool used by doxygen) which will probably be extended to include the inheritance/ collaboration diagrams directly in HTML pages by 0.4. I am excited by how modular Synopsis is, compared to other monolithic tools. It has the potential to adapt itself to any situation you may require. The more features we implement the more we refactor common functionality -- the current HTML layout is modelled after Javadoc which I have used before, but it is entirely possible that by 0.4 we will support other layouts such as that used by doxygen. We will ensure that doing so will pave the way for other layouts such that it will be trivial for users to write a small python script to format things as they like! Following similar principles has already led to the possibility of writing your own little python script to format or parse comments and reference it from the command-line (without modifing synopsis itself!). Feedback from potential users such as yourself is extremely valuable to us. Although Synopsis originated as a tool to document Berlin, it has the possibility for much wider use, driven by requests such as this. Both Stefan and I are taking steps such that each extra feature *enhances* the elegance of the design, rather than convoluting it as I have seen elsewhere. I must admit however, that Stefan did a good job of laying out a very elegant base upon which we have been working :) Stay tuned :) //--------=[ Chalky (Stephen Davies) -- Chalky@null.net ]=--------\\ //-------=[ Powered by Linux -- "Escape the Gates of Hell" ]=-------\\ //--=[ Programmer(C/C++/Java) and 4th Year CSE/CS Student at RMIT ]=--\\ From tobias_eriksson@agilent.com Thu Jan 25 10:19:20 2001 From: tobias_eriksson@agilent.com (ERIKSSON,TOBIAS (A-Sweden,ex1)) Date: Thu, 25 Jan 2001 11:19:20 +0100 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() and when? Message-ID: <4B68A8D2B880D311BCB70090278CBF621F7D4E@cordelia> Hi I'm trying to use narrow to tell me if the type of the object beeing narrowed actually is of the type I want, I think that it will throw BAD_PARAM if they are not the same, is this correct and are there any others? Regards Tobias From S.Lo@uk.research.att.com Thu Jan 25 13:59:04 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 25 Jan 2001 13:59:04 +0000 Subject: [omniORB] Problems compiling omni4_0_develop In-Reply-To: <3A6F0207.1050105@factoriaX.com> (Marc Ordinas i Llopis's message of "Wed, 24 Jan 2001 11:25:43 -0500") References: <3A6F0207.1050105@factoriaX.com> Message-ID: <3owvbjwx5j.fsf@neem.uk.research.att.com> The omni4_0_develop branch should now compile. Apart from some missing GNUmakefiles, I have to make some changes to the cxx backend to fix the error you've seen. Its interesting that the backend problem only occurs when omniidl is given a relative path name as the -p option. I suggest you do a fresh cvs checkout. I'm not 100% sure a cvs update will pick up the changes in directory names etc. Sai-Lai >>>>> Marc Ordinas i Llopis writes: > Hi all, > I'm sending this message here as I don't know where else I can get help on > this. I'm trying to compile omni4_0_develop as I wanted to try the new > codeset features, but I get lots of problems. > My development system is RedHat 7 with the last compiler (which works > compiling omniORB 3.0.2) and python 2.0 on an Athlon. > Just out of CVS, after editing config.mk and i586_linux_2.0_glibc2.1.mk, I > try make export in src/. It all goes well until it gets to the omniORB2 > directory, where it complains it does not have a 'dir.mk' file. I change > dir.mk in src/lib to set the subdirs to 'omnithread' and 'omniORB' instead > of 'omniORB2', as per the update.log I think omniORB2 is no longer used. > Then it complains that omniORB/ does not have a GNUmakefile, so I copy all > the GNUmakefiles from the omniORB2/ dir tree. That seems to work just until > it tries to generate the stubs for some files, when python fails (this also > happened with python 1.5.2, by the way). It says: > make[2]: Entering directory `/home/marc/codi/omni/src/lib/omniORB' > ../../../bin/i586_linux_2.0_glibc2.1/omniidl -bcxx -Wba > -p../../../src/lib/omniORB -Wbdebug -nf -WbF -ComniORB4 > ../../../idl/corbaidl.idl > omniidl: fatalError occurred, in debug mode. >>> An internal exception was caught > Stack: > ------------------------- > File "../../../bin/i586_linux_2.0_glibc2.1/omniidlrun.py", line 97, in ? > omniidl.main.main() > File "./main.py", line 422, in main > File "../../../src/lib/omniORB/omniidl_be/cxx/__init__.py", line 276, in > run > Make stubs for the Interface Repository appear in the CORBA module""" > File "../../../src/lib/omniORB/omniidl_be/cxx/util.py", line 152, in > fatalError > Exception: > ------------------------- > Traceback (most recent call last): > File "../../../src/lib/omniORB/omniidl_be/cxx/__init__.py", line 248, in > run > """cdrUnmarshal(TypeCode, string) -> data > File > "/home/marc/codi/omni/src/lib/omniORB/omniidl_be/cxx/header/__init__.py", > line 280, in run > defs_fragment(defs_stream, tree) > File > "/home/marc/codi/omni/src/lib/omniORB/omniidl_be/cxx/header/__init__.py", > line 140, in defs_fragment > import omniidl_be.cxx.header.defs > ImportError: No module named defs > make[2]: *** [omniORB4/corbaidl_defs.hh] Error 1 > make[2]: Leaving directory `/home/marc/codi/omni/src/lib/omniORB' > make[1]: *** [export] Error 1 > I've tried anything I've been able to think of to get it to include defs, > but even as I can import it in an interactive session, I'm unable to make > it work. > And by the way, I think there's an error in src/lib/omniORB/dir.mk, some > files are not prepended the directory omniORB4. Here's the diff : > Index: dir.mk > =================================================================== > RCS file: /cvsroot/omni/src/lib/omniORB/Attic/dir.mk,v > retrieving revision 1.7.2.5 > diff -r1.7.2.5 dir.mk > 66c66 > < omniORB4/corbaidl_defs.hh corbaidl_operators.hh corbaidl_poa.hh: > corbaidl.idl > --- >> omniORB4/corbaidl_defs.hh omniORB4/corbaidl_operators.hh > omniORB4/corbaidl_poa.hh: corbaidl.idl > Thanks for any help, > Marc Ordinas i Llopis, > factoriaX -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From AIlinykh@SECTORBASE.COM Thu Jan 25 16:53:42 2001 From: AIlinykh@SECTORBASE.COM (Ilinykh, Andre) Date: Thu, 25 Jan 2001 08:53:42 -0800 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? Message-ID: <8F4C99C66D04D4118F580090272A7A234F356D@sectorbase1.sectorbase.com> There are others, for example COMM_FAILURE. _narrow() can check the type of real object. I'm not sure when it does this way. At least, every time I create object reference by string_to_object("corbaloc:iiop:/...") it goes to my server. Thanks, Andrey -----Original Message----- From: ERIKSSON,TOBIAS (A-Sweden,ex1) [mailto:tobias_eriksson@agilent.com] Sent: Thursday, January 25, 2001 2:19 AM To: omniorb-list@uk.research.att.com Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() and when? Hi I'm trying to use narrow to tell me if the type of the object beeing narrowed actually is of the type I want, I think that it will throw BAD_PARAM if they are not the same, is this correct and are there any others? Regards Tobias From S.Lo@uk.research.att.com Thu Jan 25 18:11:21 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 25 Jan 2001 18:11:21 +0000 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? In-Reply-To: <8F4C99C66D04D4118F580090272A7A234F356D@sectorbase1.sectorbase.com> ("Ilinykh, Andre"'s message of "Thu, 25 Jan 2001 08:53:42 -0800") References: <8F4C99C66D04D4118F580090272A7A234F356D@sectorbase1.sectorbase.com> Message-ID: <3on1cfwlh2.fsf@neem.uk.research.att.com> _narrow() may or may not have to contact the real object to determine whether the operation should succeed. The chapter on type checking in the omniORB user guide explains this in some detail. Since a remote invocation may be called as part of a _narrow, the full range of system exception may be reported. By the way, omniORB never needs to contact the server to do string_to_object. If you have some code that shows the contrary, please send it to me. Sai-Lai >>>>> Ilinykh, Andre writes: > There are others, for example COMM_FAILURE. _narrow() can check the type of > real object. I'm not sure when it does this way. At least, every time I > create object reference by string_to_object("corbaloc:iiop:/...") it goes to > my server. > Thanks, > Andrey > -----Original Message----- > From: ERIKSSON,TOBIAS (A-Sweden,ex1) > [mailto:tobias_eriksson@agilent.com] > Sent: Thursday, January 25, 2001 2:19 AM > To: omniorb-list@uk.research.att.com > Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() > and when? > Hi > I'm trying to use narrow to tell me if the type of the object beeing > narrowed actually is of the type I want, > I think that it will throw BAD_PARAM if they are not the same, is this > correct and are there any others? > Regards > Tobias -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From AIlinykh@SECTORBASE.COM Thu Jan 25 18:35:57 2001 From: AIlinykh@SECTORBASE.COM (Ilinykh, Andre) Date: Thu, 25 Jan 2001 10:35:57 -0800 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? Message-ID: <8F4C99C66D04D4118F580090272A7A234F356E@sectorbase1.sectorbase.com> We don't use NameService, I create object Factory using IP and port. Every time server is down I get COMM_FAILURE exception. This is my code. Thank you, Andrey bool InitFactory() { char tmp[256]; sprintf(tmp,"corbaloc:iiop:%s:2000/KeyOfMyServer",ssIP); CORBA::Object_var obj = orb->string_to_object(tmp); try { fref= SS::SubscriptionFactory::_narrow(obj); } catch(...){ return false; } if( CORBA::is_nil(fref) ) { //cerr << "Can't narrow reference to type SF (or it was nil)." << endl; return false; } return true; } -----Original Message----- From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com] Sent: Thursday, January 25, 2001 10:11 AM To: omniorb-list@uk.research.att.com Subject: Re: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? _narrow() may or may not have to contact the real object to determine whether the operation should succeed. The chapter on type checking in the omniORB user guide explains this in some detail. Since a remote invocation may be called as part of a _narrow, the full range of system exception may be reported. By the way, omniORB never needs to contact the server to do string_to_object. If you have some code that shows the contrary, please send it to me. Sai-Lai >>>>> Ilinykh, Andre writes: > There are others, for example COMM_FAILURE. _narrow() can check the type of > real object. I'm not sure when it does this way. At least, every time I > create object reference by string_to_object("corbaloc:iiop:/...") it goes to > my server. > Thanks, > Andrey > -----Original Message----- > From: ERIKSSON,TOBIAS (A-Sweden,ex1) > [mailto:tobias_eriksson@agilent.com] > Sent: Thursday, January 25, 2001 2:19 AM > To: omniorb-list@uk.research.att.com > Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() > and when? > Hi > I'm trying to use narrow to tell me if the type of the object beeing > narrowed actually is of the type I want, > I think that it will throw BAD_PARAM if they are not the same, is this > correct and are there any others? > Regards > Tobias -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From S.Lo@uk.research.att.com Thu Jan 25 19:16:09 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 25 Jan 2001 19:16:09 +0000 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? In-Reply-To: <8F4C99C66D04D4118F580090272A7A234F356E@sectorbase1.sectorbase.com> ("Ilinykh, Andre"'s message of "Thu, 25 Jan 2001 10:35:57 -0800") References: <8F4C99C66D04D4118F580090272A7A234F356E@sectorbase1.sectorbase.com> Message-ID: <3og0i7wih2.fsf@neem.uk.research.att.com> Your code just illustrates my point. The ORB does not have to contact the object in string_to_object. It has to in _narrow because there is no type information supplied in corbaloc. >>>>> Ilinykh, Andre writes: > We don't use NameService, I create object Factory using IP and port. > Every time server is down I get COMM_FAILURE exception. > This is my code. > bool InitFactory() > { > char tmp[256]; > sprintf(tmp,"corbaloc:iiop:%s:2000/KeyOfMyServer",ssIP); > CORBA::Object_var obj = orb->string_to_object(tmp); > try { > fref= SS::SubscriptionFactory::_narrow(obj); > } catch(...){ > return false; > } > if( CORBA::is_nil(fref) ) { > //cerr << "Can't narrow reference to type SF (or it was > nil)." << endl; > return false; > } > return true; > } > -----Original Message----- > From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com] > Sent: Thursday, January 25, 2001 10:11 AM > To: omniorb-list@uk.research.att.com > Subject: Re: [omniORB] Which exceptions can be thrown by a call to > _narrow () and when? > _narrow() may or may not have to contact the real object to determine > whether the operation should succeed. The chapter on type checking in the > omniORB user guide explains this in some detail. Since a remote invocation > may be called as part of a _narrow, the full range of system exception may > be reported. > By the way, omniORB never needs to contact the server to do > string_to_object. If you have some code that shows the contrary, please > send it to me. > Sai-Lai >>>>> Ilinykh, Andre writes: >> There are others, for example COMM_FAILURE. _narrow() can check the type > of >> real object. I'm not sure when it does this way. At least, every time I >> create object reference by string_to_object("corbaloc:iiop:/...") it goes > to >> my server. >> Thanks, >> Andrey >> -----Original Message----- >> From: ERIKSSON,TOBIAS (A-Sweden,ex1) >> [mailto:tobias_eriksson@agilent.com] >> Sent: Thursday, January 25, 2001 2:19 AM >> To: omniorb-list@uk.research.att.com >> Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() >> and when? >> Hi >> I'm trying to use narrow to tell me if the type of the object beeing >> narrowed actually is of the type I want, >> I think that it will throw BAD_PARAM if they are not the same, is this >> correct and are there any others? >> Regards >> Tobias > -- > Sai-Lai Lo S.Lo@uk.research.att.com > AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com > 24a Trumpington Street Tel: +44 1223 343000 > Cambridge CB2 1QA Fax: +44 1223 313542 > ENGLAND -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From mberry@mweb.co.za Fri Jan 26 06:21:32 2001 From: mberry@mweb.co.za (Matthew Berry) Date: Fri, 26 Jan 2001 08:21:32 +0200 Subject: [omniORB] FW: Exception problems Message-ID: Sorry, silly me left the new exception off the raises list. Working now. Thanks -----Original Message----- From: Matthew Berry [mailto:mberry@mweb.co.za] Sent: 19 January 2001 02:20 To: omniORB Subject: Exception problems Within my IDL file I have a number of exceptions defined, having added "unexpectedResult" this morning. .... // Exceptions exception dbOutputFailed {}; exception unknownProduct {}; exception undefinedError {}; exception unexpectedResult {}; In my server code, I am throw an exception like: throw CTP::unexpectedResult() but on my client I get a SystemException. I ORB trace from the server looks like: ll_send: 68 bytes 4749 4f50 0100 0101 3800 0000 0000 0000 GIOP....8....... 0200 0000 0200 0000 1e00 0000 4944 4c3a ............IDL: 6f6d 672e 6f72 672f 434f 5242 412f 554e omg.org/CORBA/UN 4b4e 4f57 4e3a 312e 3000 0000 0000 0000 KNOWN:1.0....... 0200 0000 .... If I change the line to throw CTP::undefinedError() Everthing works fine, the tracing being ll_send: 68 bytes 4749 4f50 0100 0101 3800 0000 0000 0000 GIOP....8....... 0200 0000 0100 0000 2800 0000 4944 4c3a ........(...IDL: 6272 6f6e 6572 2e63 6f2e 756b 2f43 5450 broner.co.uk/CTP 2f75 6e64 6566 696e 6564 4572 726f 723a /undefinedError: 312e 3000 1.0. I tried renaming "unexpectedResult" to "badAnswerFromON" and I still get the SystemException. Any ideas on what's/where I am going wrong. Configuration: 2.80 / RH 6.2 / gcc 2.91.66 From dignac@ftw.rsc.raytheon.com Thu Jan 25 21:16:57 2001 From: dignac@ftw.rsc.raytheon.com (Demron Ignace) Date: Thu, 25 Jan 2001 16:16:57 -0500 Subject: [omniORB] Omniorb 3.0.2 and MFC Message-ID: <052569DF.0074E631.00@notesmail.ftw.rsc.raytheon.com> I am having a serious problems with threads created in the CORBA layer executing MFC calls in my implementation class. Does OmniOrb make use of MFC threads? From steve.brenneis@attws.com Fri Jan 26 13:10:45 2001 From: steve.brenneis@attws.com (Brenneis, Steve) Date: Fri, 26 Jan 2001 08:10:45 -0500 Subject: [omniORB] Omniorb 3.0.2 and MFC Message-ID: omniORB uses its own threads library which is based on either POSIX threads (on Unix flavors and VMS) or Win32 threads (on Windows). omniThreads is as close to bullet-proof as I've seen. In most cases you cannot access or execute MFC code or resources from omniThreads. In some instances, you can invoke a macro (used to be AfxManageThreadState, maybe still is) upon entry into a section of MFC thread code and it would survive the close encounter. This doesn't always work and the rules under which it does work seem to be governed by phases of the moon or some other Microsoft arcana. In fact, most MFC threads can't access or execute other MFC threads or their resources. If you need an MFC thread (especially one which has a window)to act upon something going on in an omniThread, it is usally best to use PostMessage or even PostThreadMessage (if that one is still around). Don't use SendMessage since the recipient processing is done within the same thread. All MFC threads have an idle processing loop and the thread will process the message when it gets to it. omnniORB does not use MFC threads. Those of us who have used omniORB on MS-Windows really appreciate that and hope it will never change. Hope this helps. -----Original Message----- From: Demron Ignace [mailto:dignac@ftw.rsc.raytheon.com] Sent: Thursday, January 25, 2001 4:17 PM To: omniorb-list@uk.research.att.com Subject: [omniORB] Omniorb 3.0.2 and MFC I am having a serious problems with threads created in the CORBA layer executing MFC calls in my implementation class. Does OmniOrb make use of MFC threads? From dgrisby@uk.research.att.com Fri Jan 26 15:25:29 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 26 Jan 2001 15:25:29 +0000 Subject: [omniORB] packaging omniorb In-Reply-To: Message from Pinchak Stanley of "Tue, 23 Jan 2001 21:20:39 PST." <20010124052039.39855.qmail@web12211.mail.yahoo.com> Message-ID: <200101261525.PAA19938@pineapple.uk.research.att.com> On Tuesday 23 January, Pinchak Stanley wrote: > Hi my name is Stanley Pinchak and I would like to > create a debian package of omniorb 3.0.2. [...] Great! The best starting point is probably the RPMs which Sander Steffann and Jared Peterson have been working on. If the Debian packages can follow the same basic layout, that will make things nicer for people using more than one Linux distribution. Jared's RPMs are available from http://www.tgflinux.com/omni/ I haven't got around to testing the latest versions yet, so there may be a few problems with them. RedHat users could also give them a go, and let us know if they work. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From count0@building2.co.jp Fri Jan 26 18:18:13 2001 From: count0@building2.co.jp (Huw Rogers) Date: Sat, 27 Jan 2001 03:18:13 +0900 Subject: clean shutdown on signal (was Re: shutdown() SEGVs (was Re: [omniORB] atexit, exit, _exit, and ORB::destroy())) References: <200012041043.KAA07951@pineapple.uk.research.att.com> <3A5FDC3C.4B6BAD5A@building2.co.jp> Message-ID: <3A71BF65.5FD0A655@building2.co.jp> Summary: don't call shutdown() from within a signal handler under Linux. Well this cost me several days, but I figured it out. It's a wierd problem with LinuxThreads and signals. Hope this helps someone else out there. It might be a good idea to note this somewhere in the documentation even though it's totally platform specific. All pthread_* functions are unsafe to be called from within signal handlers under Linux, and can apparently cause memory corruption within the LinuxThreads library if you do so. The only permissible thing to do in a signal handler is sem_post(), and have a thread waiting on the same semaphore (from the LinuxThreads FAQ, doh). So you can't call shutdown() directly from a signal handler under Linux, and neither can you create a thread to call shutdown() in the handler. You have to do that before- hand and have it wait on a semaphore until the time comes. So in main(): sem_init(...) pthread_create(...) // the dedicated finalization thread sigaction(...) // the signal handler orb->run() // woken up by the finalization thread calling shutdown() orb->destroy() _exit(code) in the signal handler for SIGINT/SIGTERM: sem_post(...) // wake up the finalization thread ... and in the finalization thread: sem_wait(...) // wait to die orb->shutdown(!0) return(0) Cue weary sigh... -Huw > From rgruet@intraware.com Fri Jan 26 17:37:32 2001 From: rgruet@intraware.com (Richard Gruet) Date: Fri, 26 Jan 2001 09:37:32 -0800 Subject: [omniORB] Omnipy binaries compatible with Python 2.0 ? Message-ID: <3A71B5DB.203C0E4A@intraware.com> Hi, I'm looking for a release of the Omnipy binaries that would be compatible with Python 2.0. It seems not to exist so far. When will it be available on the Omniorb site ? Cheers -- Richard Gruet -- Sr Application Architect Intraware, Inc. Mailto:rgruet@intraware.com http://www.intraware.com Voice: (001) 925-253-6512 Fax: (001) 925-253-4599 From lesha12@hotmail.com Sat Jan 27 01:12:03 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Sat, 27 Jan 2001 04:12:03 +0300 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 Message-ID: Hello, I've lost hope to compile omniORB_3.0.2 under Solaris2.6 using gcc2.95.2. I get the following message during ompillation: ====================================================================== ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 -ComniORB3 ../../../idl/Naming.idl omniidl: ERROR! omniidl: Could not open IDL compiler module _omniidlmodule.so omniidl: Please make sure it is in directory /usr/local/omni/lib/sun4_sosV_5.6 omniidl: (or set the PYTHONPATH environment variable) omniidl: (The error was `ld.so.1: python: fatal: libstdc++.so.2.10.0: open failed: No such file or directory') ======================================================================== Could someone explain me how I can avoid this problem, PLEASE. Thank you in advance. Regards, Aleksey. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From marc@factoriaX.com Sat Jan 27 16:44:58 2001 From: marc@factoriaX.com (Marc Ordinas i Llopis) Date: Sat, 27 Jan 2001 11:44:58 -0500 Subject: [omniORB] Problems compiling omni4_0_develop References: <3A6F0207.1050105@factoriaX.com> <3owvbjwx5j.fsf@neem.uk.research.att.com> Message-ID: <3A72FB0A.2090108@factoriaX.com> Sai-Lai Lo wrote: > The omni4_0_develop branch should now compile. Apart from some missing > GNUmakefiles, I have to make some changes to the cxx backend to fix the > error you've seen. Its interesting that the backend problem only occurs > when omniidl is given a relative path name as the -p option. > > I suggest you do a fresh cvs checkout. I'm not 100% sure a cvs update will > pick up the changes in directory names etc. Thanks, I got it to start compiling. Unfortunately, it dies like this: /usr/bin/g++ -c -O2 -Wall -Wno-unused -I.. -D_REENTRANT -DUSE_omniORB_logStream -D_OMNIORB_LIBRARY -DCONFIG_DEFAULT_LOCATION='"/etc/omniORB.cfg"' -DUnixArchitecture -I. -I../../../../include -D__x86__ -D__linux__ -D__OSVERSION__=2 -o static/bootstrapstub.o bootstrapstub.cc In file included from bootstrapstub.cc:31: ../omniORB4/bootstrapSK.cc: In method `void _0RL_cd_96f078e2247ab9da_20000000::marshalReturnedValues (cdrStream &)': ../omniORB4/bootstrapSK.cc:164: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. But I'm pretty sure this is just the compiler in RH7, known for its helpful error messages... I'll keep trying and tell you if I get any further, although I'm afraid I'll have to wait until the next gcc release. By the way, may I ask which development environment do you develop omniORB 4 on? Thanks again, Marc Ordinas i Llopis factoriaX From rodrigc@mediaone.net Sat Jan 27 15:17:29 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Sat, 27 Jan 2001 10:17:29 -0500 Subject: [omniORB] Problems compiling omni4_0_develop In-Reply-To: <3A72FB0A.2090108@factoriaX.com>; from marc@factoriaX.com on Sat, Jan 27, 2001 at 11:44:58AM -0500 References: <3A6F0207.1050105@factoriaX.com> <3owvbjwx5j.fsf@neem.uk.research.att.com> <3A72FB0A.2090108@factoriaX.com> Message-ID: <20010127101729.A13220@mediaone.net> On Sat, Jan 27, 2001 at 11:44:58AM -0500, Marc Ordinas i Llopis wrote: > _0RL_cd_96f078e2247ab9da_20000000::marshalReturnedValues (cdrStream &)': > ../omniORB4/bootstrapSK.cc:164: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > > But I'm pretty sure this is just the compiler in RH7, known for its Yikes, RH 7. I've been trying to avoid that version since Redhat threw in beta release of gcc in that distribution. You should do: rpm -q gcc gcc-c++ cpp libstdc++ libstdc++-devel and then go to ftp://rawhide.redhat.com/pub/rawhide/i386/RedHat/ and see if there are newer versions of those rpm's that fix your compiler bug. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From dek_ml@konerding.com Sat Jan 27 17:56:19 2001 From: dek_ml@konerding.com (dek_ml@konerding.com) Date: Sat, 27 Jan 2001 09:56:19 -0800 Subject: [omniORB] Problems compiling omni4_0_develop In-Reply-To: Your message of "Sat, 27 Jan 2001 10:17:29 EST." <20010127101729.A13220@mediaone.net> Message-ID: <200101271756.JAA09936@konerding.com> Craig Rodrigues writes: >On Sat, Jan 27, 2001 at 11:44:58AM -0500, Marc Ordinas i Llopis wrote: >> _0RL_cd_96f078e2247ab9da_20000000::marshalReturnedValues (cdrStream &)': >> ../omniORB4/bootstrapSK.cc:164: Internal error: Segmentation fault. >> Please submit a full bug report. >> See for instructions. >> >> But I'm pretty sure this is just the compiler in RH7, known for its > >Yikes, RH 7. I've been trying to avoid that version since Redhat threw in >beta release of gcc in that distribution. You should do: >rpm -q gcc gcc-c++ cpp libstdc++ libstdc++-devel Yes. Don't attempt to develop on RH7. Instead, use Red Hat 6.2, with gcc/g++ 2.95.2, and if you really need a standard C++, use STLport-4.0. Wait until Red Hat gets their act together in 7.1 or 7.2 before switching over. Dave From tororoland@freemail.hu Sun Jan 28 16:27:05 2001 From: tororoland@freemail.hu (T|r� Roland) Date: Sun, 28 Jan 2001 17:27:05 +0100 (CET) Subject: [omniORB] Corba-COM bridge Message-ID: hi i use windows nt4 with visual c++6 i made a com dll that is called by a corba client and the server is a vb application that is calling my dll with the COM interface the problem is if i call a service form my corba client the dll gets the control and the corba service is running but in the function witch is called my corba client is a Fire_ event /because i have to reach the vb side/ and at this point the corba core is crasing it is crashing in the giopServer.cc at line 728 catch(...) { if( omniORB::traceLevel > 1 ) { omniORB::logger l; l << "WARNING -- method \'" << operation() << "\' raised an unexpected\n" " exception (not a CORBA exception).\n"; } CORBA::UNKNOWN ex(0, CORBA::COMPLETED_MAYBE); CHECK_AND_MAYBE_MARSHALL_SYSTEM_EXCEPTION (UNKNOWN,ex); } anyone has an idea what can be the solutoin? From davidh@cavendish.co.uk Mon Jan 29 08:29:32 2001 From: davidh@cavendish.co.uk (David Hyde) Date: Mon, 29 Jan 2001 08:29:32 -0000 Subject: [omniORB] Corba-COM bridge Message-ID: <31C9EC5EF9CAD111981300805F06666028B229@phantom.cavendish.co.uk> If I understand you correctly what you are saying is that you are = having problems when a callback comes into your COM control from CORBA and you = have to pass it back to the front end as an event. The problem is that apartment threaded objects have to fire events off = their main threads only and the CORBA call is entering your control on a = seperate thread. You have to marshall the object's reference using CoMarshalInterThreadInterfaceInStream and then unmarshall it with CoGetInterfaceAndReleaseStream when the event comes in. You then use = the unmarshalled pointer to fire the events. MSDN and VC++ newsgroups have examples of doing this. Regards David -----Original Message----- From: T|r=F5" Roland [mailto:tororoland@freemail.hu] Sent: Sunday, January 28, 2001 4:27 PM To: omniorb-list@uk.research.att.com Subject: [omniORB] Corba-COM bridge hi=20 i use windows nt4 with visual c++6=20 i made a com dll that is called by a corba client and the=20 server is a vb application that is calling my dll with the=20 COM interface the problem is if i call a service form my corba client the=20 dll gets the control and the corba service is running but=20 in the function witch is called my corba client is a Fire_ event /because i have to reach the vb side/ and at this=20 point the corba core is crasing=20 it is crashing in the giopServer.cc=20 at line 728 catch(...) { if( omniORB::traceLevel > 1 ) { omniORB::logger l; l << "WARNING -- method \'" << operation() << "\'=20 raised an unexpected\n" " exception (not a CORBA exception).\n"; } CORBA::UNKNOWN ex(0, CORBA::COMPLETED_MAYBE); CHECK_AND_MAYBE_MARSHALL_SYSTEM_EXCEPTION (UNKNOWN,ex); } anyone has an idea what can be the solutoin? From Sandro Tolaini" Can someone clarify what are the standard actions took by omniORB when multiple profiles are specified in an IOR? I'd like to use a corbaloc URI with multiple profiles in order to connect to the first available server, but it seems that omniORB only tries the first profile. Also, is there a way to reconnect to another profile if the initial server goes down? Cheers, Sandro Tolaini From dgrisby@uk.research.att.com Mon Jan 29 11:35:19 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 11:35:19 +0000 Subject: [omniORB] problem with insPOA and Factory object In-Reply-To: Message from =?iso-8859-1?Q?Juan_Carlos_Coru=F1a?= of "Tue, 23 Jan 2001 09:45:00 +0100." Message-ID: <200101291135.LAA08687@pineapple.uk.research.att.com> On Tuesday 23 January, =?iso-8859-1?Q?Juan_Carlos_Coru=F1a?= wrote: > I try to implement a Factory object to create instances of another > object, but without success. [...] > class MQ_Factory_i(MQ_module__POA.MQ_Factory): > def create_MQ(self): > print 'creating MQ' > mq = MQ_class_i() > return mq._this() [...] > The problem appears here in the last line ("session = > mq_jcoruna.Login('jcoruna')"). The system doesn't return any value and > waits until timeout. The system works correctly without the Factory. The problem is that your MQ_class object has been activated in the Root POA, because of the implicit activation on the call to _this(). You haven't activated the Root POA, so requests to the MQ_class object are blocked. That is why implicit activation is evil. It is better to explicitly activate your objects in the POA you want them in, and avoid the use of _this(). Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 29 11:39:01 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 11:39:01 +0000 Subject: [omniORB] Omnipy binaries compatible with Python 2.0 ? In-Reply-To: Message from "Richard Gruet" of "Fri, 26 Jan 2001 09:37:32 PST." <3A71B5DB.203C0E4A@intraware.com> Message-ID: <200101291139.LAA08742@pineapple.uk.research.att.com> On Friday 26 January, "Richard Gruet" wrote: > I'm looking for a release of the Omnipy binaries that would be > compatible with Python 2.0. > It seems not to exist so far. When will it be available on the Omniorb > site ? In the next release, which should be soon, there will be binaries for 2.0 as well as 1.5.2. I can't be more specific than that, I'm afraid. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 29 11:40:25 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 11:40:25 +0000 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 In-Reply-To: Message from "Aleksey Varzhel" of "Sat, 27 Jan 2001 04:12:03 +0300." Message-ID: <200101291140.LAA08760@pineapple.uk.research.att.com> On Saturday 27 January, "Aleksey Varzhel" wrote: > I've lost hope to compile omniORB_3.0.2 under Solaris2.6 using gcc2.95.2. > I get the following message during ompillation: [...] > omniidl: (The error was `ld.so.1: python: fatal: libstdc++.so.2.10.0: open > failed: No such file or directory') You need to set LD_LIBRARY_PATH to point to the lib directory of wherever you installed gcc, so it can find libstdc++. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From steve.brenneis@attws.com Mon Jan 29 13:10:06 2001 From: steve.brenneis@attws.com (Brenneis, Steve) Date: Mon, 29 Jan 2001 08:10:06 -0500 Subject: [omniORB] JDC Bug 4385162, fixed! Message-ID: Apparently all the pleading and begging worked. Has anyone tried the fix? Does it work? Steve Brenneis Developer-II AT&T Wireless Desk: (336) 286-1783 Cell: (336) 456-3290 Fax: (336) 286-1880 Steve.Brenneis@attws.com "You can tune a piano, but you can't tuna fish" -- Groucho Marx From dgrisby@uk.research.att.com Mon Jan 29 14:04:05 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 14:04:05 +0000 Subject: [omniORB] JDC Bug 4385162, fixed! In-Reply-To: Message from "Brenneis, Steve" of "Mon, 29 Jan 2001 08:10:06 EST." Message-ID: <200101291404.OAA09428@pineapple.uk.research.att.com> On Monday 29 January, "Brenneis, Steve" wrote: > Apparently all the pleading and begging worked. Has anyone tried the fix? > Does it work? I'm afraid to say that that isn't actually the bug affecting use of omniNames. It has to do with code set negotiation, which omniORB 3 doesn't support. The bug would have affected interoperability with omniORB 4, though. The object key length bug is still closed, marked "not a bug". Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From bglenden@cv3.cv.nrao.edu Mon Jan 29 15:27:47 2001 From: bglenden@cv3.cv.nrao.edu (Brian Glendenning) Date: Mon, 29 Jan 2001 08:27:47 -0700 Subject: [omniORB] omniORBpy and Python 2.0 References: <200101291404.OAA09428@pineapple.uk.research.att.com> Message-ID: <003201c08a08$0f3cace0$e8015892@aoc.nrao.edu> I hope this question isn't in some FAQ I couldn't find! Does the current release work with Python 2.0? Also, is this list available in digest form? Regards, Brian Glendenning From djs@uk.research.att.com Mon Jan 29 15:32:07 2001 From: djs@uk.research.att.com (David Scott) Date: Mon, 29 Jan 2001 15:32:07 +0000 (GMT) Subject: [omniORB] Internal Exception while compiling IDL file In-Reply-To: <20001220021243.A29325@mips.biochem.mpg.de> Message-ID: On Wed, 20 Dec 2000, Gnana wrote: > I am trying to compile a huge IDL file with omniidl > and this is what i get. > > [internal exception in omniIDL's C++ backend] > Hi, Sorry for the delay fixing this problem. It turned out that there was a nasty bug in the C++ backend's scoped name handling code which would only surface when you write IDL like: interface I{}; module M{ interface I: ::I{}; interface I2: I{}; }; I've committed a bugfix to the omni3_develop branch-- it should be available on the external CVS server tomorrow. Let me know if there are any problems with it. HTH! -- Dave Scott From dgrisby@uk.research.att.com Mon Jan 29 15:46:34 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 15:46:34 +0000 Subject: [omniORB] omniORBpy and Python 2.0 In-Reply-To: Message from "Brian Glendenning" of "Mon, 29 Jan 2001 08:27:47 MST." <003201c08a08$0f3cace0$e8015892@aoc.nrao.edu> Message-ID: <200101291546.PAA10200@pineapple.uk.research.att.com> On Monday 29 January, "Brian Glendenning" wrote: > Does the current release work with Python 2.0? Yes, but the binaries we distribute do not work with anything but 1.5.2. If you recompile for Python 2.0, it works fine. > Also, is this list available in digest form? Yes. Send mail to majordomo@uk.research.att.com with a body of subscribe omniorb-list-digest For some reason, this information isn't on our in-touch page. I'll add it... Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From jnye@micro-optics.com Mon Jan 29 14:53:53 2001 From: jnye@micro-optics.com (jnye@micro-optics.com) Date: Mon, 29 Jan 2001 10:53:53 -0400 Subject: [omniORB] Persistent Objects Question Message-ID: <388331E016F0D411A9F000A0C9DB1BC511BD0B@GATEWAY> Hi All, I'm not sure if this is an omni-specific question, or if this is just a misunderstading I have with persistent references. To start off, here is my understanding of how persistent references work: Persistent references outlive the process in which the objects they refer to live. This means that theoretically, I should be able to create a persistent object reference, write it to disk in some registry at software installation time and it should never have to be updated (unless the server code changes somehow and even then, I'm not sure if it should change if the interface did not change). My Goal: I'm kind of adopting COM's installation method where If I want CORBA objects to reside in Dlls, their Dlls will get registered in the system with an exported DllRegisterServer and servers in executables will use a command line switch of /regserver to install themselves -> this will result in a persistent IOR being written to some globally accessible registration database or file. When the server executables are run with the /regserver command line option, they register themselves then simply exit. My Problem: The infrastructure is all set up, the only problem that I am having now is setting up a persistent reference. I run my test server exe as myobject.exe /regserver It indeed registers an IOR in a registration database, but when clients attempt to use the IOR, they get a COMM_FAILURE exception. If I change the myobject code to register the IOR each time it is started (which is undesirable), clients can access the server with no problem. In other words, the server's IOR is not persistent for some reason. My Code: I've included the main program for the server which creates a child POA with the persistent and user id assignment policies, then calls create_reference_with_id on that child POA with an id that I created using string_to_ObjectId. I would expect for that reference to be the same each time since it is persistent. Not so -- clients can't use it across server restarts, either. Can someone review my code and tell me what I am doing wrong? TIA, Jason //////// Code //////////////////////////////////////////////////////////////// int main(int argc, char * argv) { try { namespace PS = PortableServer; // Easier to read!! // Initialize the orb CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Get reference to Root POA CORBA::Object_var obj = orb->resolve_initial_references("RootPOA"); PS::POA_var poa = PS::POA::_narrow(obj); // Activate POA manager PS::POAManager_var mgr = poa->the_POAManager(); PS::LifespanPolicy_var lifespan = poa->create_lifespan_policy(PS::PERSISTENT); PS::IdAssignmentPolicy_var assign = poa->create_id_assignment_policy(PS::USER_ID); CORBA::PolicyList poaPolicyList; poaPolicyList.length(2); poaPolicyList[0] = PS::LifespanPolicy::_duplicate(lifespan); poaPolicyList[1] = PS::IdAssignmentPolicy::_duplicate(assign); PS::POA_var childPOA = poa->create_POA("MyObjectPOA", mgr, poaPolicyList); lifespan->destroy(); assign->destroy(); MyObjectImpl servant; PS::ObjectId_var oid = PS::string_to_ObjectId("MyObject"); // Just register and exit. if (findCmdLineArg(argc, argv, "/RegServer")) { // Object registration/unregistration. try { CORBA::Object_var ref = childPOA->create_reference_with_id(oid, "IDL:MyObject:1.0"); CORBA::String_var ior = orb->object_to_string(ref); // Simply writes a reference to a globally accessable registration file in the form: // // MyObject=IOR:..... // ObjectRegistrar::registerIOR("MyObject", (const char *)ior); } catch (...) { ::MessageBox(0, "Failed to register IOR", "MyObject", 0); return -1; } } else { // Normal execution of server. mgr->activate(); // Activate object. childPOA->activate_object_with_id(oid, &servant); orb->run(); } } catch(const CORBA::Exception &e ) { int size; cout << e._NP_repoId(&size) << endl; return -1; } return 0; } From lesha12@hotmail.com Mon Jan 29 17:20:24 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Mon, 29 Jan 2001 20:20:24 +0300 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 Message-ID: Hello, Thanks for help. That error has gone. However now I have an another failure at the same place. I tried to recompile python but it did not help. ====================================================================== ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 -ComniORB3 ../../../idl/Naming.idl omniidl: ERROR! omniidl: Could not open IDL compiler module _omniidlmodule.so omniidl: Please make sure it is in directory /usr/local/omni/lib/sun4_sosV_5.6 omniidl: (or set the PYTHONPATH environment variable) omniidl: (The error was `ld.so.1: python: fatal: relocation error: file /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol _Py_NoneStruct: referenced symbol not found') gmake[2]: *** [omniORB3/Naming.hh] Error 1 gmake[2]: Leaving directory `/usr/local/omni/src/lib/omniORB2' gmake[1]: *** [export] Error 2 gmake[1]: Leaving directory `/usr/local/omni/src/lib' gmake: *** [export] Error 2 ====================================================================== I would be very grateful if could help me with this issue. Thank you. Best regards, Aleksey. >From: Duncan Grisby >To: "Aleksey Varzhel" >CC: omniorb-list@uk.research.att.com >Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 >Date: Mon, 29 Jan 2001 11:40:25 +0000 > >On Saturday 27 January, "Aleksey Varzhel" wrote: > > > I've lost hope to compile omniORB_3.0.2 under Solaris2.6 using >gcc2.95.2. > > I get the following message during ompillation: > >[...] > > omniidl: (The error was `ld.so.1: python: fatal: libstdc++.so.2.10.0: >open > > failed: No such file or directory') > >You need to set LD_LIBRARY_PATH to point to the lib directory of >wherever you installed gcc, so it can find libstdc++. > >Cheers, > >Duncan. > >-- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From jnye@micro-optics.com Mon Jan 29 17:49:29 2001 From: jnye@micro-optics.com (jnye@micro-optics.com) Date: Mon, 29 Jan 2001 13:49:29 -0400 Subject: [omniORB] Persistent Objects Question Message-ID: <388331E016F0D411A9F000A0C9DB1BC511BD0C@GATEWAY> Hi David, Nope, that was just a typo -- my program actually has a WinMain and I just threw in main for the purposes of the email. Thanks anyway, Jason. -----Original Message----- From: David Byron [mailto:dbyron@coactive.com] Sent: Monday, January 29, 2001 1:40 PM To: 'jnye@micro-optics.com' Subject: RE: [omniORB] Persistent Objects Question I doubt this is it, and I haven't looked closely at your code, but argv is usually declarded as (char **argv) or (char *argv[]). Maybe it will have some effect. -DB > int main(int argc, char * argv) > { > try > { > namespace PS = PortableServer; // Easier to read!! > > // Initialize the orb > CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); > > // Get reference to Root POA > CORBA::Object_var obj = > orb->resolve_initial_references("RootPOA"); > PS::POA_var poa = PS::POA::_narrow(obj); > > // Activate POA manager > PS::POAManager_var mgr = poa->the_POAManager(); > > PS::LifespanPolicy_var lifespan = > poa->create_lifespan_policy(PS::PERSISTENT); > PS::IdAssignmentPolicy_var assign = > poa->create_id_assignment_policy(PS::USER_ID); > > CORBA::PolicyList poaPolicyList; > poaPolicyList.length(2); > poaPolicyList[0] = PS::LifespanPolicy::_duplicate(lifespan); > poaPolicyList[1] = PS::IdAssignmentPolicy::_duplicate(assign); > > PS::POA_var childPOA = poa->create_POA("MyObjectPOA", mgr, > poaPolicyList); > lifespan->destroy(); > assign->destroy(); > > MyObjectImpl servant; > PS::ObjectId_var oid = PS::string_to_ObjectId("MyObject"); > > // Just register and exit. > if (findCmdLineArg(argc, argv, "/RegServer")) > { > // Object registration/unregistration. > try > { > CORBA::Object_var ref = > childPOA->create_reference_with_id(oid, "IDL:MyObject:1.0"); > CORBA::String_var ior = orb->object_to_string(ref); > > // Simply writes a reference to a globally accessable > registration file in the form: > // > // MyObject=IOR:..... > // > ObjectRegistrar::registerIOR("MyObject", > (const char *)ior); > } > catch (...) > { > ::MessageBox(0, "Failed to register IOR", > "MyObject", 0); > return -1; > } > } > else > { > // Normal execution of server. > mgr->activate(); > > // Activate object. > childPOA->activate_object_with_id(oid, &servant); > orb->run(); > } > } > catch(const CORBA::Exception &e ) > { > int size; > cout << e._NP_repoId(&size) << endl; > return -1; > } > > return 0; > } From dgrisby@uk.research.att.com Mon Jan 29 17:56:33 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 17:56:33 +0000 Subject: [omniORB] Persistent Objects Question In-Reply-To: Message from jnye@micro-optics.com of "Mon, 29 Jan 2001 10:53:53 -0400." <388331E016F0D411A9F000A0C9DB1BC511BD0B@GATEWAY> Message-ID: <200101291756.RAA14014@pineapple.uk.research.att.com> On Monday 29 January, jnye@micro-optics.com wrote: [...] > It indeed registers an IOR in a registration database, but when clients > attempt to use the IOR, they get a COMM_FAILURE exception. If I change the > myobject code to register the IOR each time it is started (which is > undesirable), clients can access the server with no problem. In other words, > the server's IOR is not persistent for some reason. It looks like your code is doing all the right things, with one important omission. You have to make sure that the server listens on the same TCP port every time it starts up. To do that, use the -ORBpoa_iiop_port command line argument. Your program can insert the argument so it doesn't actually have to be on the command line. See the omniNames or omniMapper source for how to do that. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 29 17:59:32 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 17:59:32 +0000 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 In-Reply-To: Message from "Aleksey Varzhel" of "Mon, 29 Jan 2001 20:20:24 +0300." Message-ID: <200101291759.RAA14038@pineapple.uk.research.att.com> On Monday 29 January, "Aleksey Varzhel" wrote: > omniidl: (The error was `ld.so.1: python: fatal: relocation error: file > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol _Py_NoneStruct: > referenced symbol not found') That normally happens when you try to use the _omniidl library with a different version of Python to the one it was compiled against. Make sure that the "python" on your path is the same version of Python as the one specified in the mk/platforms/sun4_sosV_5.6.mk file. Alternatively, have you stripped your python executable? If so, the symbols in it won't be available to the omniidl extension. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From lesha12@hotmail.com Mon Jan 29 18:27:03 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Mon, 29 Jan 2001 10:27:03 -0800 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 References: <200101291759.RAA14038@pineapple.uk.research.att.com> Message-ID: I have compiled Python 1.5.2 and the file mk/platforms/sun4_sosV_5.6.mk contains a link to /usr/local/bin/python. Regarding "stripping" my python executable I am not sure what it is. I'm not familiar with Python and I've installed it to support omniORB only. Could you advise how I can check if it was stripped ? Thank you. ----- Original Message ----- From: "Duncan Grisby" To: "Aleksey Varzhel" Cc: Sent: Monday, January 29, 2001 9:59 AM Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 > On Monday 29 January, "Aleksey Varzhel" wrote: > > > omniidl: (The error was `ld.so.1: python: fatal: relocation error: file > > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol _Py_NoneStruct: > > referenced symbol not found') > > That normally happens when you try to use the _omniidl library with a > different version of Python to the one it was compiled against. Make > sure that the "python" on your path is the same version of Python as > the one specified in the mk/platforms/sun4_sosV_5.6.mk file. > > Alternatively, have you stripped your python executable? If so, the > symbols in it won't be available to the omniidl extension. > > Cheers, > > Duncan. > > -- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- > > From ghickey@northplains.com Mon Jan 29 20:17:33 2001 From: ghickey@northplains.com (Grant Hickey) Date: Mon, 29 Jan 2001 15:17:33 -0500 Subject: [omniORB] Character Encoding Message-ID: Our company is using Omniorb on multiple platforms (Sun, Windows NT, Mac). We are having some character encoding problems. -Does Corba provide any character encoding across platforms? -Are there any hooks into omniorb which would allow us to encode everything sent across the wire into unicode? Grant Hickey North Plains Systems From MKeay@SeeBeyond.com Mon Jan 29 21:17:33 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Mon, 29 Jan 2001 13:17:33 -0800 Subject: [omniORB] argv processing Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC78@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08A38.E50F4A00 Content-Type: text/plain; charset="iso-8859-1" Can someone explain why argv processing for -ORB parameters when calling ORB_init starts at argv[1] when there seems no reason for it to start at argv[0]? ------_=_NextPart_001_01C08A38.E50F4A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable argv processing

Can someone explain why argv = processing for -ORB parameters when calling ORB_init starts at argv[1] = when there seems no reason for it to start at argv[0]?

------_=_NextPart_001_01C08A38.E50F4A00-- From tvedt@noao.edu Mon Jan 29 21:33:42 2001 From: tvedt@noao.edu (Janet Tvedt) Date: Mon, 29 Jan 2001 14:33:42 -0700 (MST) Subject: [omniORB] compiling template with I::_ptr_type * Message-ID: <200101292133.OAA16368@pertelote.tuc.noao.edu> A few months ago I posted a message (details below). However, I cannot get the following template function to compile: template int getCosNamingObjectRef(Type::_ptr_type *a, ... I am using omniORB3.0.2 and gcc version 2.95.2 under Solaris 2.8. Am I missing an include file or a compiler option? -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Internet: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 > There is no work-around for non-compliant code which uses Echo*. I'm > afraid you will have to change all uses of Echo* to Echo_ptr. > > > I ask because I am porting lots of code that uses the * version > > and a general name resolution template function that has a > > parameter Type ** as shown below: > > template > > int getCosNamingObjectRef(Type **a, ... > > For this sort of thing, it's not as bad as it might be, because the > C++ mapping helps out. You can use: > > template > int getCosNamingObjectRef(Type::_ptr_type *a, ... > > Since the C++ mapping says that for interface I, I::_ptr_type is a > typedef to I_ptr. You won't have to change all calls to the template > function, just the declarations of the object reference variables you > pass to it. > > Cheers, > > Duncan. > > -- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- > > From cnewbold@laurelnetworks.com Mon Jan 29 21:35:29 2001 From: cnewbold@laurelnetworks.com (Chris Newbold) Date: Mon, 29 Jan 2001 16:35:29 -0500 Subject: [omniORB] Proxy factory support? Message-ID: <3A75E221.9060400@laurelnetworks.com> I was just starting to investigate creating "smart" proxies for some of our heavily-used objects to cache the values of read-only attributes on the client-side. At one point, there was a documented mechanism for creating and installing proxy factories in omniORB. However, in 3.0.2 there is only passing mention of proxy factories in section 7.2 Basic Interface Type Checking; there is no discussion of how to implement proxy factories. Further, upon examining the generated code for object references (_objref_Foo) I note that none of the methods corresponding to the interface operations are declared virtual. This would seem to preclude deriving my own "smart" proxy implementation from the generated one. Are user-written proxy factories still supported? If so, is there any documentation? -Chris Newbold Laurel Networks, Inc. From MKeay@SeeBeyond.com Mon Jan 29 23:15:09 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Mon, 29 Jan 2001 23:15:09 +0000 Subject: [omniORB] Date: Mon, 29 Jan 2001 15:13:57 -0800 Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC82@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08A49.282457D0 Content-Type: text/plain; charset="iso-8859-1" I have been having a lot of trouble recently with OmniOrb on NT. The project I was working was trying to use the DLL version of the libraries. When ever I invoked a method on an object I received a COMM_FAILURE exception. After 2 weeks of looking into this, the guys who produced this thrid party object said there is an issue with the DLL versions and that I should use a static libraries. What is the issue here first of all. Now to the issue I currently have. I am now using the static libraries and everytime on ORB_init, I get a windows system exception, Access Violation. Has anyone else experienced this issue, and what is the solution, if theire is a solution to this problem? ------_=_NextPart_001_01C08A49.282457D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have been having a lot of trouble = recently with OmniOrb on NT. The project I was working was trying to = use the DLL version of the libraries. When ever I invoked a method on = an object I received a COMM_FAILURE exception. After 2 weeks of looking = into this, the guys who produced this thrid party object said there is = an issue with the DLL versions and that I should use a static = libraries. What is the issue here first of all.

Now to the issue I currently have. I = am now using the static libraries and everytime on ORB_init, I get a = windows system exception, Access Violation. Has anyone else experienced = this issue, and what is the solution, if theire is a solution to this = problem?

------_=_NextPart_001_01C08A49.282457D0-- From MKeay@SeeBeyond.com Tue Jan 30 00:47:35 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Mon, 29 Jan 2001 16:47:35 -0800 Subject: [omniORB] Date: Mon, 29 Jan 2001 15:13:57 -0800 Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC88@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08A56.3C800FA0 Content-Type: text/plain; charset="iso-8859-1" Further to this problem, it looks like the static libraries are not Thread Safe. As part of the argv list I was passing to ORB_init, I was setting the -ORBtraceLevel option on. When I removed this I had no further problem. Is anyone aware of this problem/issue? -----Original Message----- From: Michael Keay [mailto:MKeay@SeeBeyond.com] Sent: Monday, January 29, 2001 3:15 PM To: Omniorb-List@Uk. Research. Att. Com (E-mail) Subject: [omniORB] Date: Mon, 29 Jan 2001 15:13:57 -0800 I have been having a lot of trouble recently with OmniOrb on NT. The project I was working was trying to use the DLL version of the libraries. When ever I invoked a method on an object I received a COMM_FAILURE exception. After 2 weeks of looking into this, the guys who produced this thrid party object said there is an issue with the DLL versions and that I should use a static libraries. What is the issue here first of all. Now to the issue I currently have. I am now using the static libraries and everytime on ORB_init, I get a windows system exception, Access Violation. Has anyone else experienced this issue, and what is the solution, if theire is a solution to this problem? ------_=_NextPart_001_01C08A56.3C800FA0 Content-Type: text/html; charset="iso-8859-1"

Further to this problem, it looks like the static libraries are not Thread Safe. As part of the argv list I was passing to ORB_init, I was setting the -ORBtraceLevel option on. When I removed this I had no further problem. Is anyone aware of this problem/issue?

-----Original Message-----
From: Michael Keay [mailto:MKeay@SeeBeyond.com]
Sent: Monday, January 29, 2001 3:15 PM
To: Omniorb-List@Uk. Research. Att. Com (E-mail)
Subject: [omniORB] Date: Mon, 29 Jan 2001 15:13:57 -0800

I have been having a lot of trouble recently with OmniOrb on NT. The project I was working was trying to use the DLL version of the libraries. When ever I invoked a method on an object I received a COMM_FAILURE exception. After 2 weeks of looking into this, the guys who produced this thrid party object said there is an issue with the DLL versions and that I should use a static libraries. What is the issue here first of all.

Now to the issue I currently have. I am now using the static libraries and everytime on ORB_init, I get a windows system exception, Access Violation. Has anyone else experienced this issue, and what is the solution, if theire is a solution to this problem?

------_=_NextPart_001_01C08A56.3C800FA0-- From harri.pasanen@trema.com Tue Jan 30 08:47:30 2001 From: harri.pasanen@trema.com (Harri Pasanen) Date: Tue, 30 Jan 2001 09:47:30 +0100 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 References: <200101291759.RAA14038@pineapple.uk.research.att.com> Message-ID: <3A767FA2.2D643CD7@trema.com> You can do nm /usr/local/bin/python | grep NoneS You should see something like: 000000000017d514 D _Py_NoneStruct Maybe you didn't compile python with gcc 2.95.2? -Harri Aleksey Varzhel wrote: > > I have compiled Python 1.5.2 and the file mk/platforms/sun4_sosV_5.6.mk > contains a link to /usr/local/bin/python. > > Regarding "stripping" my python executable I am not sure what it is. I'm not > familiar with Python and I've installed it to support omniORB only. > Could you advise how I can check if it was stripped ? > > Thank you. > > ----- Original Message ----- > From: "Duncan Grisby" > To: "Aleksey Varzhel" > Cc: > Sent: Monday, January 29, 2001 9:59 AM > Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 > > > On Monday 29 January, "Aleksey Varzhel" wrote: > > > > > omniidl: (The error was `ld.so.1: python: fatal: relocation error: file > > > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol > _Py_NoneStruct: > > > referenced symbol not found') > > > > That normally happens when you try to use the _omniidl library with a > > different version of Python to the one it was compiled against. Make > > sure that the "python" on your path is the same version of Python as > > the one specified in the mk/platforms/sun4_sosV_5.6.mk file. > > > > Alternatively, have you stripped your python executable? If so, the > > symbols in it won't be available to the omniidl extension. > > > > Cheers, > > > > Duncan. > > > > -- > > -- Duncan Grisby \ Research Engineer -- > > -- AT&T Laboratories Cambridge -- > > -- http://www.uk.research.att.com/~dpg1 -- > > > > From timd@macquarie.com.au Tue Jan 30 10:13:02 2001 From: timd@macquarie.com.au (Timothy Docker) Date: Tue, 30 Jan 2001 21:13:02 +1100 (EST) Subject: [omniORB] marshal exceptions in omniORBpy Message-ID: <14966.37544.192783.868352@tcc2> I have been confused by the fact that omniORB py throws exceptions like omniORB.CORBA.MARSHAL: Minor: 0, Completed: COMPLETED_NO. when unmarshalling values from the wire that it doesn't understand (in this case an incorrectly initialised enum sent from the wrong server). I was looking for problems with my input parameters to the call, not the responses because I thought that COMPLETED_NO meant that the servant operation hadn't been invoked. Given that I know the remote operation has completed, shouldn't the status be COMPLETED_YES or perhaps COMPLETED_MAYBE? Thanks, Tim From S.Lo@uk.research.att.com Tue Jan 30 11:04:26 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 30 Jan 2001 11:04:26 +0000 Subject: [omniORB] Proxy factory support? In-Reply-To: <3A75E221.9060400@laurelnetworks.com> (Chris Newbold's message of "Mon, 29 Jan 2001 16:35:29 -0500") References: <3A75E221.9060400@laurelnetworks.com> Message-ID: <3opuh55mit.fsf@neem.uk.research.att.com> Indeed in pre-3.0 omniORB, there is a way for an application to control or change the creation of proxy objects. This is somehow drop, including the documentation, in the 3.0.0 release. The function has been reinstated in 3.0.2 but the documentation is still missing. Let me just fill in the blanks here: 1. As you have noted, to create "smart" proxy, firstly you have to generate _objref_Foo classes with virtual methods. There is now an option to the compiler backend: -Wbvirtual_objref to accomplish this. Unfortunately, we haven't updated the usage output to document this feature. 2. Write your own proxy object to inherit from _objref_Foo. You also have to write your own proxy object factory to inherit from _pof_Foo. 3. Instantiate a single instance of your proxy object factory. The ORB will then call your pof whenever it needs a proxy object of interface Foo. The 2.8 manual has a more detail explanation. The class methods may be different slightly. Sai-Lai >>>>> Chris Newbold writes: > I was just starting to investigate creating "smart" proxies > for some of our heavily-used objects to cache the values of > read-only attributes on the client-side. > At one point, there was a documented mechanism for creating > and installing proxy factories in omniORB. However, in 3.0.2 > there is only passing mention of proxy factories in section > 7.2 Basic Interface Type Checking; there is no discussion of > how to implement proxy factories. > Further, upon examining the generated code for object references > (_objref_Foo) I note that none of the methods corresponding to > the interface operations are declared virtual. This would seem > to preclude deriving my own "smart" proxy implementation from the > generated one. > Are user-written proxy factories still supported? If so, is there > any documentation? -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From dgrisby@uk.research.att.com Tue Jan 30 16:46:39 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 30 Jan 2001 16:46:39 +0000 Subject: [omniORB] Character Encoding In-Reply-To: Message from Grant Hickey of "Mon, 29 Jan 2001 15:17:33 EST." Message-ID: <200101301646.QAA25177@pineapple.uk.research.att.com> On Monday 29 January, Grant Hickey wrote: > -Does Corba provide any character encoding across platforms? > -Are there any hooks into omniorb which would allow us to encode everything > sent across the wire into unicode? The CORBA standard does have code set negotiation, but omniORB 3 does not support it yet. omniORB 4 will support it. If all you want to do is transmit Unicode, your best bet is to send the data as a sequence. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Tue Jan 30 16:51:05 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 30 Jan 2001 16:51:05 +0000 Subject: [omniORB] compiling template with I::_ptr_type * In-Reply-To: Message from tvedt@noao.edu (Janet Tvedt) of "Mon, 29 Jan 2001 14:33:42 MST." <200101292133.OAA16368@pertelote.tuc.noao.edu> Message-ID: <200101301651.QAA25248@pineapple.uk.research.att.com> On Monday 29 January, Janet Tvedt wrote: > A few months ago I posted a message (details below). However, > I cannot get the following template function to compile: > > template > int getCosNamingObjectRef(Type::_ptr_type *a, ... Depending on what you are trying to do, you quite probably want to be using template int getCosNamingObjectRef(Type::_ptr_type a, ... without the *. Other than that, precisely what error message are you getting? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Tue Jan 30 16:48:15 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 30 Jan 2001 16:48:15 +0000 Subject: [omniORB] argv processing In-Reply-To: Message from Michael Keay of "Mon, 29 Jan 2001 13:17:33 PST." <9B85913BDA568742B72DAF6DF54ECBC60159CC78@mail01.stc.com> Message-ID: <200101301648.QAA25193@pineapple.uk.research.att.com> On Monday 29 January, Michael Keay wrote: > Can someone explain why argv processing for -ORB parameters when calling > ORB_init starts at argv[1] when there seems no reason for it to start at > argv[0]? argv[0] is traditionally the name of the program, so omniORB ignores it. There's no particular reason why it couldn't look at argv[0] too, but it isn't really a problem to put a dummy name in there if you are creating your own argv list. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From lesha12@hotmail.com Tue Jan 30 16:58:33 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Tue, 30 Jan 2001 08:58:33 -0800 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 References: <200101291759.RAA14038@pineapple.uk.research.att.com> <3A767FA2.2D643CD7@trema.com> Message-ID: Well, here is what I got: 0009ad24 D _Py_NoneStruct I guess, this is Ok. I deleted omniORB and Python and compiled them from the very beginning using gcc2.95.2 What can I check else ? Thank you for your help. Aleksey. ----- Original Message ----- From: "Harri Pasanen" To: "Aleksey Varzhel" Cc: "Duncan Grisby" ; Sent: Tuesday, January 30, 2001 12:47 AM Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 > You can do > > nm /usr/local/bin/python | grep NoneS > > You should see something like: > > 000000000017d514 D _Py_NoneStruct > > Maybe you didn't compile python with gcc 2.95.2? > > -Harri > > > Aleksey Varzhel wrote: > > > > I have compiled Python 1.5.2 and the file mk/platforms/sun4_sosV_5.6.mk > > contains a link to /usr/local/bin/python. > > > > Regarding "stripping" my python executable I am not sure what it is. I'm not > > familiar with Python and I've installed it to support omniORB only. > > Could you advise how I can check if it was stripped ? > > > > Thank you. > > > > ----- Original Message ----- > > From: "Duncan Grisby" > > To: "Aleksey Varzhel" > > Cc: > > Sent: Monday, January 29, 2001 9:59 AM > > Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 > > > > > On Monday 29 January, "Aleksey Varzhel" wrote: > > > > > > > omniidl: (The error was `ld.so.1: python: fatal: relocation error: file > > > > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol > > _Py_NoneStruct: > > > > referenced symbol not found') > > > > > > That normally happens when you try to use the _omniidl library with a > > > different version of Python to the one it was compiled against. Make > > > sure that the "python" on your path is the same version of Python as > > > the one specified in the mk/platforms/sun4_sosV_5.6.mk file. > > > > > > Alternatively, have you stripped your python executable? If so, the > > > symbols in it won't be available to the omniidl extension. > > > > > > Cheers, > > > > > > Duncan. > > > > > > -- > > > -- Duncan Grisby \ Research Engineer -- > > > -- AT&T Laboratories Cambridge -- > > > -- http://www.uk.research.att.com/~dpg1 -- > > > > > > > > From dgrisby@uk.research.att.com Tue Jan 30 17:11:36 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 30 Jan 2001 17:11:36 +0000 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 In-Reply-To: Message from "Aleksey Varzhel" of "Tue, 30 Jan 2001 08:58:33 PST." Message-ID: <200101301711.RAA31642@pineapple.uk.research.att.com> On Tuesday 30 January, "Aleksey Varzhel" wrote: > Well, here is what I got: > 0009ad24 D _Py_NoneStruct > I guess, this is Ok. > > I deleted omniORB and Python and compiled them from the very beginning using > gcc2.95.2 How odd. Try setting the PYTHONPATH environment variable to include the path to the _omniidlmodule.so library (i.e. TOP/omni/lib/sun.../) then run "python". At the ">>>" prompt, type "import _omniidl". Does that complain in any way? One thought -- did you install the omnipython binary? If so, maybe that is broken in some way. Try removing TOP/omni/bin/sun.../omnipython, and see it that helps. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From rodrigc@mediaone.net Tue Jan 30 17:25:50 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Tue, 30 Jan 2001 12:25:50 -0500 Subject: [omniORB] omniORB 4.0 features? Message-ID: <20010130122550.A16902@mediaone.net> Hi, Is there a document or e-mail outlining the proposed features of omniORB 4.0? -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From harri.pasanen@trema.com Tue Jan 30 18:41:05 2001 From: harri.pasanen@trema.com (Harri Pasanen) Date: Tue, 30 Jan 2001 19:41:05 +0100 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 References: <200101291759.RAA14038@pineapple.uk.research.att.com> <3A767FA2.2D643CD7@trema.com> Message-ID: <3A770AC1.607CD9F6@trema.com> At one time I remember that Python link command did not pass the parameter that exported the symbols from the Python executable to be used by shared libraries. But I can't remember which version of Python that was, I just remember fixing it and even submitting the fix to the Python maintainers. I can only say that on Solaris 2.7, gcc 2.95.2, Python 2.0 everything works out of the box. -Harri Aleksey Varzhel wrote: > > Well, here is what I got: > 0009ad24 D _Py_NoneStruct > I guess, this is Ok. > > I deleted omniORB and Python and compiled them from the very beginning using > gcc2.95.2 > > What can I check else ? > > Thank you for your help. > > Aleksey. > > ----- Original Message ----- > From: "Harri Pasanen" > To: "Aleksey Varzhel" > Cc: "Duncan Grisby" ; > > Sent: Tuesday, January 30, 2001 12:47 AM > Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 > > > You can do > > > > nm /usr/local/bin/python | grep NoneS > > > > You should see something like: > > > > 000000000017d514 D _Py_NoneStruct > > > > Maybe you didn't compile python with gcc 2.95.2? > > > > -Harri > > > > > > Aleksey Varzhel wrote: > > > > > > I have compiled Python 1.5.2 and the file mk/platforms/sun4_sosV_5.6.mk > > > contains a link to /usr/local/bin/python. > > > > > > Regarding "stripping" my python executable I am not sure what it is. I'm > not > > > familiar with Python and I've installed it to support omniORB only. > > > Could you advise how I can check if it was stripped ? > > > > > > Thank you. > > > > > > ----- Original Message ----- > > > From: "Duncan Grisby" > > > To: "Aleksey Varzhel" > > > Cc: > > > Sent: Monday, January 29, 2001 9:59 AM > > > Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 > Solaris2.6 > > > > > > > On Monday 29 January, "Aleksey Varzhel" wrote: > > > > > > > > > omniidl: (The error was `ld.so.1: python: fatal: relocation error: > file > > > > > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol > > > _Py_NoneStruct: > > > > > referenced symbol not found') > > > > > > > > That normally happens when you try to use the _omniidl library with a > > > > different version of Python to the one it was compiled against. Make > > > > sure that the "python" on your path is the same version of Python as > > > > the one specified in the mk/platforms/sun4_sosV_5.6.mk file. > > > > > > > > Alternatively, have you stripped your python executable? If so, the > > > > symbols in it won't be available to the omniidl extension. > > > > > > > > Cheers, > > > > > > > > Duncan. > > > > > > > > -- > > > > -- Duncan Grisby \ Research Engineer -- > > > > -- AT&T Laboratories Cambridge -- > > > > -- http://www.uk.research.att.com/~dpg1 -- > > > > > > > > > > > > -- harri.pasanen@trema.com From seefeld@sympatico.ca Tue Jan 30 20:56:04 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Tue, 30 Jan 2001 15:56:04 -0500 Subject: [omniORB] debugging proxy problem Message-ID: <3A772A64.59803794@sympatico.ca> Hello, I'm trying to debug some code of mine, and since it appears the problem is related to proxy request forwarding, I'd like to ask for your feedback. The situation is this: class TransformImpl : public virtual POA_Warsaw::Transform, public virtual ServantBase { public: virtual void store_matrix(Warsaw::Transform::Matrix); Warsaw::Transform_ptr _this() { if (!_this_valid) { __this = POA_Warsaw::Transform::_this (); _this_valid = true; } return Warsaw::Transform::_duplicate (__this); } //... private: Warsaw::Transform_var __this; }; The above is part of the TransformImpl class, which implements the Warsaw::Transform interface. Since we need to access its '_this()' pointer quite a lot, we cache the proxy inside after the first request. >From within another class, I'm calling the 'store_matrix' method, which writes 'this' to cerr, as a way to identify the servant on which the method is being called. Here is some more code: Lease_var cumulative(Provider::provide()); //... Transform_var t_ptr = cumulative->_this(); Transform::Matrix newmat1; t_ptr->store_matrix(newmat1); Transform::Matrix newmat2; cumulative->store_matrix(newmat2); (Lease/Provider are helper templates that implement a smart allocator. Provider allocates Ts, and Lease_var takes care of returning it to the provider, just a smart pointer. Provider takes care for activation...) In the code snippet I call store_matrix twice, once over the proxy, once directly. However, it appears that a) the 'this' output generated by the store_matrix() method differs, i.e. the calls aren't done on the same servant b) as a result of a), the actual matrices differ I'm totally lost with this. Does anybody see a problem with the code ? Using -ORBtraceLevel 10 I can see that the proxy is generated upon the first call to cumulative->_this(), just what I would expect. However, the 't_ptr' in the example above seems to point always to the same servant, no matter what 'cumulative' is. In other words, from the two 'this' pointers that are written to cerr, the one from 't_ptr->store_matrix(newmat1);' stays the same over the whole run, as if it was a static variable. Any help would be highly appreciated ! Best regards, Stefan From seefeld@sympatico.ca Tue Jan 30 21:23:00 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Tue, 30 Jan 2001 16:23:00 -0500 Subject: [omniORB] debugging proxy problem References: <3A772A64.59803794@sympatico.ca> Message-ID: <3A7730B4.9E4615E7@sympatico.ca> I'm sorry, I found the problem myself. The TransformImpl class doesn't define 'operator =', meaning that even the cached proxy would be copied. I'm ashamed on this stupid error... (as often, just asking a question in public helps for the answer to drop out) Sorry for the noise. Stefan From MKeay@SeeBeyond.com Tue Jan 30 21:05:41 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Tue, 30 Jan 2001 13:05:41 -0800 Subject: [omniORB] argv processing Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC8F@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08B00.6723E380 Content-Type: text/plain; charset="iso-8859-1" Thanks Duncan, Yes that was my impression. We are creating our own argv list and hence no reason for using asrgv[0] for -ORB arguments. Ah well. -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: Tuesday, January 30, 2001 8:48 AM To: Michael Keay Cc: Omniorb-List@Uk. Research. Att. Com (E-mail) Subject: Re: [omniORB] argv processing On Monday 29 January, Michael Keay wrote: > Can someone explain why argv processing for -ORB parameters when calling > ORB_init starts at argv[1] when there seems no reason for it to start at > argv[0]? argv[0] is traditionally the name of the program, so omniORB ignores it. There's no particular reason why it couldn't look at argv[0] too, but it isn't really a problem to put a dummy name in there if you are creating your own argv list. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- ------_=_NextPart_001_01C08B00.6723E380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [omniORB] argv processing

Thanks Duncan,

Yes that was my impression. We are creating our own = argv list and hence no reason
for using asrgv[0] for -ORB arguments. Ah = well.

-----Original Message-----
From: Duncan Grisby [mailto:dgrisby@uk.research.a= tt.com]
Sent: Tuesday, January 30, 2001 8:48 AM
To: Michael Keay
Cc: Omniorb-List@Uk. Research. Att. Com = (E-mail)
Subject: Re: [omniORB] argv processing

On Monday 29 January, Michael Keay wrote:

> Can someone explain why argv processing for -ORB = parameters when calling
> ORB_init starts at argv[1] when there seems no = reason for it to start at
> argv[0]?

argv[0] is traditionally the name of the program, so = omniORB ignores
it. There's no particular reason why it couldn't = look at argv[0] too,
but it isn't really a problem to put a dummy name in = there if you are
creating your own argv list.

Cheers,

Duncan.

--
-- Duncan Grisby \ Research = Engineer --
-- AT&T Laboratories = Cambridge = --
-- http://www.uk.research.att.com/~dpg1 --

------_=_NextPart_001_01C08B00.6723E380-- From rgruet@intraware.com Tue Jan 30 23:35:26 2001 From: rgruet@intraware.com (Richard Gruet) Date: Tue, 30 Jan 2001 15:35:26 -0800 Subject: [omniORB] OmniORBpy binaries compatible with Python 2.0 Message-ID: <3A774FBD.3C94C5DF@intraware.com> Hi, Currently it's difficult for me to compile OmniORBpy so to get a version compatible with Python 2.0. If someone has already done that (primarily on NT but I'm also interested in Solaris and Linux versions), I suggest that we findd a way to advertise it on the omniORB site (since Duncan seems too busy to do the job), maybe by sending him the binaries ? If it's not possible, I'd be still very happy to receive the NT binaries by e-mail !! Thank you, -- Richard Gruet -- Sr Application Architect Intraware, Inc. Mailto:rgruet@intraware.com http://www.intraware.com Voice: (001) 925-253-6512 Fax: (001) 925-253-4599 From christoph.weigl@fee.de Wed Jan 31 08:24:14 2001 From: christoph.weigl@fee.de (Weigl Christoph) Date: Wed, 31 Jan 2001 09:24:14 +0100 Subject: [omniORB] freeing out-parameters Message-ID: <2B4C26C0BC7@fee.de> Hi, I'm sure this question has been asked before, but I can't find the postings and the following problem is very important for us: We have a server which uses sequences as out-params to pass results to clients. void CPze::getProjectList(const char* von, const char* bis, CORBA::Boolean sortById, ObjList_out projects) { (...) projects = new ObjList; projects->length (size); // CORBA-size eintragen... while (....) { ObjDescr *x = new ObjDescr; // get a pointer to a p object from a database... CString s; s.Format ("%d", p->ID); x->Id = CORBA::string_dup (s); x->Bezeichnung = CORBA::string_dup (p->Bezeichnung); (*projects)[index++] = *x; (...) // delete the p-pointer } ObjList and ObjDescr are defined in the .idl-file: struct ObjDescr { string Id; string Bezeichnung; }; typedef sequence ObjList; Now, my problem is that the server seems to eat the "out-param" memory. In my opinion, the orb sould be able to delete all allocated memory after passing the out-param to the client (am I wrong here?). What must i do to get this memory freed? Thanks for reading, Chris Mfg. Christoph Weigl Tel. 09672 506-178 Mail: Christoph.Weigl@FEE.De From vonWedel@lfpt.rwth-aachen.de Wed Jan 31 08:56:48 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Wed, 31 Jan 2001 09:56:48 +0100 Subject: [omniORB] freeing out-parameters Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0030D553C12569E5_= Content-Type: text/plain; charset="us-ascii" Hello, To solve the problem you describe, the CORBA language mapping for C++ specifies that out and return parameters are freed after the ORB has marshalled them. Whereas you had to create and return a copy manually according earlier versions of the standard, you can now use the _retn() method to do the job. I suppose something like the following should be working (and also circumvents using the operator* on the sequence object): void CPze::getProjectList(const char* von, const char* bis, CORBA::Boolean sortById, ObjList_out projects) { // ... ObjList_var p_list = new ObjList; projects->length (size); // CORBA-size eintragen... // ... projects = p_list._retn() } This will use a _var object for a sequence so you can directly access it using p_list[index] and returns a copy of it which is freed by the CORBA runtime system. The local contents are freed when the _var variable goes out of scope. MfG Lars von Wedel "Weigl Christoph" Sent by: owner-omniorb-list@uk.research.att.com 31/01/01 09:24 To: omniorb-list@uk.research.att.com cc: Subject: [omniORB] freeing out-parameters Hi, I'm sure this question has been asked before, but I can't find the postings and the following problem is very important for us: We have a server which uses sequences as out-params to pass results to clients. void CPze::getProjectList(const char* von, const char* bis, CORBA::Boolean sortById, ObjList_out projects) { (...) projects = new ObjList; projects->length (size); // CORBA-size eintragen... while (....) { ObjDescr *x = new ObjDescr; // get a pointer to a p object from a database... CString s; s.Format ("%d", p->ID); x->Id = CORBA::string_dup (s); x->Bezeichnung = CORBA::string_dup (p->Bezeichnung); (*projects)[index++] = *x; (...) // delete the p-pointer } ObjList and ObjDescr are defined in the .idl-file: struct ObjDescr { string Id; string Bezeichnung; }; typedef sequence ObjList; Now, my problem is that the server seems to eat the "out-param" memory. In my opinion, the orb sould be able to delete all allocated memory after passing the out-param to the client (am I wrong here?). What must i do to get this memory freed? Thanks for reading, Chris Mfg. Christoph Weigl Tel. 09672 506-178 Mail: Christoph.Weigl@FEE.De --=_alternative 0030D553C12569E5_= Content-Type: text/html; charset="us-ascii"
Hello,

To solve the problem you describe, the CORBA language mapping for C++ specifies
that out and return parameters are freed after the ORB has marshalled them. Whereas
you had to create and return a copy manually according earlier versions of the standard,
you can now use the _retn() method to do the job. I suppose something like the following
should be working (and also circumvents using the operator* on the sequence object):

void CPze::getProjectList(const char* von, const char* bis,
CORBA::Boolean sortById, ObjList_out projects)
{
// ...
ObjList_var p_list = new ObjList;
projects->length (size); // CORBA-size eintragen...

// ...

projects = p_list._retn()
}

This will use a _var object for a sequence so you can directly access it
using p_list[index] and returns a copy of it which is freed by the CORBA
runtime system. The local contents are freed when the _var variable goes
out of scope.

MfG
Lars von Wedel

"Weigl Christoph" <christoph.weigl@fee.de>
Sent by: owner-omniorb-list@uk.research.att.com

31/01/01 09:24

To: omniorb-list@uk.research.att.com
cc:
Subject: [omniORB] freeing out-parameters

Hi,
I'm sure this question has been asked before, but I can't find the
postings and the following problem is very important for us:
We have a server which uses sequences as out-params to pass
results to clients.

void CPze::getProjectList(const char* von, const char* bis,
CORBA::Boolean sortById, ObjList_out projects)
{
(...)
projects = new ObjList;
projects->length (size); // CORBA-size eintragen...

while (....)
{
ObjDescr *x = new ObjDescr;
// get a pointer to a p object from a database...

CString s;
s.Format ("%d", p->ID);
x->Id = CORBA::string_dup (s);
x->Bezeichnung = CORBA::string_dup (p->Bezeichnung);
(*projects)[index++] = *x;
(...)
// delete the p-pointer
}

ObjList and ObjDescr are defined in the .idl-file:

struct ObjDescr
{
string Id;
string Bezeichnung;
};
typedef sequence <ObjDescr> ObjList;

Now, my problem is that the server seems to eat the "out-param"
memory. In my opinion, the orb sould be able to delete all allocated
memory after passing the out-param to the client (am I wrong
here?).
What must i do to get this memory freed?

Thanks for reading,
Chris

Mfg.

Christoph Weigl
Tel. 09672 506-178
Mail: Christoph.Weigl@FEE.De

--=_alternative 0030D553C12569E5_=-- From gerhard.nospam@bigfoot.de Wed Jan 31 03:37:36 2001 From: gerhard.nospam@bigfoot.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 31 Jan 2001 04:37:36 +0100 Subject: [omniORB] OmniORBpy binaries compatible with Python 2.0 References: <3A774FBD.3C94C5DF@intraware.com> Message-ID: <3A778880.C6EADE4D@bigfoot.de> I have made OmniORB and OmniORBpy RPMs for SuSE 7.0. These work quite well. For my CORBA learning needs at least. I don't currently have much webspace. So I'll try to upload the RPMs to ftp://ftp.uk.research.att.com/pub/incoming/ tomorrow. If nothing else, somebody more experienced can use the .SPEC files, once the ftpmaster has stepped into action. And I can have my RPMs debugged ;-) Gerhard PS: I have NT/Python 2.0 binaries, but haven't used them long, so perhaps somebody else can help here? PPS: Building it wasn't difficult at all for me. No particular problems. Except compiling with GNU C++ takes ages, even on my dual 500 x86. Richard Gruet wrote: > > Hi, > > Currently it's difficult for me to compile OmniORBpy so to get a version > compatible with Python 2.0. > If someone has already done that (primarily on NT but I'm also > interested in Solaris and Linux versions), I suggest that we findd a way > to advertise it on the omniORB site (since Duncan seems too busy to do > the job), maybe by sending him the binaries ? > If it's not possible, I'd be still very happy to receive the NT > binaries by e-mail !! -- Sorry for the fake email, please use the real one below to reply. contact: g e r h a r d @ b i g f o o t . d e web: http://highqualdev.com From bernd.varga@hartter.com Wed Jan 31 10:05:10 2001 From: bernd.varga@hartter.com (Bernd Varga) Date: Wed, 31 Jan 2001 11:05:10 +0100 Subject: [omniORB] PingPong - Callback - Problem Message-ID: <3192D317C236D411A08A0050DA36BA1006F073@mailgw> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08B6D.4D160B10 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08B6D.4D160B10" ------_=_NextPart_001_01C08B6D.4D160B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hiho! I'm new in CORBA-developing. For tests I want realise a Ping-Pong - program in C++ which is running in JAVA. But in C++ I have a problem. I start the Ping (Server) with the max-pings-amount of twelve. Then I start the Pong and get following output: Ping: C++ ping: 1 / 12 C++ ping; weiterer Aufruf: 1 C++ ping: 3 / 12 C++ ping; weiterer Aufruf: 3 C++ ping: 5 / 12 C++ ping; weiterer Aufruf: 5 C++ ping: 7 / 12 C++ ping; weiterer Aufruf: 7 C++ ping: 9 / 12 C++ ping; weiterer Aufruf: 9 Pong: C++ pong: 2 C++ pong: 4 C++ pong: 6 C++ pong: 8 C++ pong: 10 Why does the program stop after the "C++ pong: 10"? Is any thing wrong in the source - code? Or has CORBA a maximum sum of callback - functions? If the max-pings-amount is lower then nine, the program will be executed correctly! I have no idea! Thanks for your help! Bernd ----------------------------------------------------------------- Bernd VARGA Tel.: +43-3352-33440-363 SOFTWAREHAUS HARTTER Fax.: +43-3352-33440-111 A-7400 Oberwart, Raimundg. 25 Email: bernd.varga@hartter.com Unser Zeichen: 0000.18 Web: www.hartter.com ----------------------------------------------------------------- Unm=F6gliches wird sofort erledigt, ...=20 ... Wunder brauchen ein bisschen!=20 ------_=_NextPart_001_01C08B6D.4D160B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PingPong - Callback - Problem

Hiho!

I'm new in CORBA-developing. For tests I want realise = a Ping-Pong -
program in C++ which is running in JAVA. But in C++ = I have a problem.
I start the Ping (Server) with the max-pings-amount = of twelve.
Then I start the Pong and get following = output:
Ping:
C++ ping: 1 / 12
C++ ping; weiterer Aufruf: 1
C++ ping: 3 / 12
C++ ping; weiterer Aufruf: 3
C++ ping: 5 / 12
C++ ping; weiterer Aufruf: 5
C++ ping: 7 / 12
C++ ping; weiterer Aufruf: 7
C++ ping: 9 / 12
C++ ping; weiterer Aufruf: 9

Pong:
C++ pong: 2
C++ pong: 4
C++ pong: 6
C++ pong: 8
C++ pong: 10

Why does the program stop after the "C++ pong: = 10"? Is any thing
wrong in the source - code? Or has CORBA a maximum = sum of
callback - functions?

If the max-pings-amount is lower then nine, the = program will be
executed correctly!

I have no idea!

Thanks for your help!

Bernd

---------------------------------------------------------------= --
Bernd = VARGA           &= nbsp;        Tel.: = +43-3352-33440-363
SOFTWAREHAUS = HARTTER           = Fax.: +43-3352-33440-111
A-7400 Oberwart, Raimundg. 25 Email: = bernd.varga@hartter.com
Unser Zeichen: = 0000.18         = Web:   www.hartter.com
---------------------------------------------------------------= --

Unm=F6gliches wird sofort erledigt, ... =
... Wunder brauchen ein bisschen! =

------_=_NextPart_001_01C08B6D.4D160B10-- ------_=_NextPart_000_01C08B6D.4D160B10 Content-Type: application/octet-stream; name="ping_i.cpp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ping_i.cpp" // // Example code for implementing IDL interfaces in file pingpong.idl // #include #include "pingpong.h" CORBA::Object_ptr getObjectReference(CosNaming::NamingContext_var = rootContext); CosNaming::NamingContext_var getObjectNameService(CORBA::ORB_ptr orb); CORBA::Boolean bindObjectToName(CosNaming::NamingContext_var = rootContext,=20 const char *,=20 CORBA::Object_ptr); // // Example class implementing IDL interface PPModule::PingObject // class PPModule_PingObject_i: public POA_PPModule::PingObject, public PortableServer::RefCountServantBase=20 { private: // Make sure all instances are built on the heap by making the // destructor non-public //virtual ~PPModule_PingObject_i(); protected: int _maxPings; public: // standard constructor PPModule_PingObject_i(); virtual ~PPModule_PingObject_i(); // methods corresponding to defined IDL attributes and operations void maxPings(CORBA::Long); CORBA::Long maxPings(); CORBA::Long ping(PPModule::PongObject_ptr po, CORBA::Long count); =20 }; // // Example implementational code for IDL interface PPModule::PingObject // PPModule_PingObject_i::PPModule_PingObject_i() { // add extra constructor code here _maxPings =3D 1; } PPModule_PingObject_i::~PPModule_PingObject_i() { // add extra destructor code here } // Methods corresponding to IDL attributes and operations void PPModule_PingObject_i::maxPings(CORBA::Long maxPings) { // insert code here and remove the warning //#warning "Code missing in function " _maxPings =3D maxPings; } CORBA::Long PPModule_PingObject_i::maxPings() { // insert code here and remove the warning //#warning "Code missing in function " return _maxPings; } CORBA::Long PPModule_PingObject_i::ping(PPModule::PongObject_ptr po,=20 CORBA::Long count) { // insert code here and remove the warning //#warning "Code missing in function " int hilf =3D count; cout << "C++ ping: " << hilf << " / " << maxPings() << endl; if(count < maxPings()) { cout << "C++ ping; weiterer Aufruf: " << hilf << endl; count =3D po->pong(_this(), count + 1); } else { cout << "C++ ping; kein Aufruf: " << hilf << endl; } =09 cout << "C++ ping nach Aufruf: " << hilf << endl; return count; } // End of example implementational code int main(int argc, char** argv) { try=20 { // Initialise the ORB. CORBA::ORB_var orb =3D CORBA::ORB_init(argc, argv, "omniORB3"); // Obtain a reference to the root POA. CORBA::Object_var obj =3D orb->resolve_initial_references("RootPOA"); PortableServer::POA_var poa =3D PortableServer::POA::_narrow(obj); // We allocate the objects on the heap. Since these are reference // counted objects, they will be deleted by the POA when they are no // longer needed. PPModule_PingObject_i* myPPModule_PingObject_i =3D new = PPModule_PingObject_i(); =20 // Activate the objects. This tells the POA that the objects are // ready to accept requests. PortableServer::ObjectId_var myPPModule_PingObject_iid =3D = poa->activate_object(myPPModule_PingObject_i); =20 // Obtain a reference to each object and output the stringified // IOR to stdout // IDL interface: PPModule::PingObject CORBA::Object_var ref =3D myPPModule_PingObject_i->_this(); CORBA::String_var sior(orb->object_to_string(ref)); cout << "IDL object PPModule::PingObject IOR =3D '" << (char*)sior << = "'" << endl; myPPModule_PingObject_i->maxPings(12); CosNaming::NamingContext_var rootContext =3D = getObjectNameService(orb); if (!bindObjectToName(rootContext, "Ping", ref)) return 1; =09 // Obtain a POAManager, and tell the POA to start accepting // requests on its objects. PortableServer::POAManager_var pman =3D poa->the_POAManager(); pman->activate(); =09 orb->run(); orb->destroy(); } catch(CORBA::SystemException&)=20 { cerr << "Caught CORBA::SystemException." << endl; } catch(CORBA::Exception&)=20 { cerr << "Caught CORBA::Exception." << endl; } catch(omniORB::fatalException& fe)=20 { cerr << "Caught omniORB::fatalException:" << endl; cerr << " file: " << fe.file() << endl; cerr << " line: " << fe.line() << endl; cerr << " mesg: " << fe.errmsg() << endl; } catch(...)=20 { cerr << "Caught unknown exception." << endl; } return 0; } CosNaming::NamingContext_var getObjectNameService(CORBA::ORB_ptr orb) { CosNaming::NamingContext_var rootContext; try { // Eine Referenz auf den Stammkontext des Namesdienstes holen: CORBA::Object_var obj; obj =3D orb->resolve_initial_references("NameService"); // Narrow the reference returned rootContext =3D CosNaming::NamingContext::_narrow(obj); if (CORBA::is_nil(rootContext)) { cerr << "Failed to narrow the root naming context." << endl; return 0; } } catch (CORBA::ORB::InvalidName&) { // This should not happen! cerr << "Service required is invalid [does not exist]." << endl; return 0;//CORBA::Object::_nil(); } return rootContext; } CORBA::Object_ptr getObjectReference(CosNaming::NamingContext_var = rootContext) { CosNaming::Name contextName; contextName.length(1);//2); contextName[0].id =3D "Pong"; contextName[0].kind =3D ""; // Note on kind: The kind field is used to indicate the type of the // object. This is to avoid conventions such as that used by files // (name.type -- e.g. test.ps =3D postscript etc.) try { // Resolve the name to an object reference return rootContext->resolve(contextName); } catch (CosNaming::NamingContext::NotFound&) { // This exception is thrown if any of the components of the // path [contexts or the object] aren't found: cerr << "Context not found." << endl; } catch (CORBA::COMM_FAILURE&) { cerr << "Caught system exception COMM_FAILURE -- unable to" << "contact the naming service." << endl; } catch (CORBA::SystemException&) { cerr << "Caught a CORBA::SystemException while using the " << "naming service." << endl; } return CORBA::Object::_nil(); } CORBA::Boolean bindObjectToName(CosNaming::NamingContext_var = rootContext,=20 const char name[], CORBA::Object_ptr objref) { try { cout << "Einen Kontext names corejava an den Stammkontext binden" << = endl; // Einen Kontext names "corejava" an den Stammkontext binden: CosNaming::Name contextName; contextName.length(1); contextName[0].id =3D (const char*)name; contextName[0].kind =3D (const char*)""; CosNaming::NamingContext_var corejavaContext; =09 try { cout << "Kontext an Stamm binden um ihm testContext zuweisen:" << = endl; // Kontext an Stamm binden um ihm testContext zuweisen: rootContext->rebind(contextName, = objref);//bind_new_context(contextName); cout << "Kontext an Stamm binden um ihm testContext zuweisen -Ende" = << endl; } catch (CosNaming::NamingContext::AlreadyBound&) { // Wenn Kontext bereits vorhanden, wird diese Ausnahme ausgel=F6st. // In diesem Fall einfach den Namen aufl=F6sen und testContext // an das zur=FCckgegebene Objekt zuweisen: CORBA::Object_var contextObj =3D rootContext->resolve(contextName); corejavaContext =3D CosNaming::NamingContext::_narrow(contextObj); if (CORBA::is_nil(corejavaContext)) { cerr << "Kann Kontext corejava nicht einengen." << endl; return 0; } } =09 } catch (CORBA::COMM_FAILURE&) { cerr << "Caught system exception COMM_FAILURE -- unable to contact = the naming service." << endl; return 0; } return 1; } ------_=_NextPart_000_01C08B6D.4D160B10 Content-Type: application/octet-stream; name="pingpong.cpp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pingpong.cpp" // This file is generated by omniidl (C++ backend)- omniORB_3_0. Do not = edit. #include "pingpong.h" #include static const char* _0RL_library_version =3D omniORB_3_0; PPModule::PingObject_ptr PPModule::PingObject_Helper::_nil() { return PPModule::PingObject::_nil(); } CORBA::Boolean = PPModule::PingObject_Helper::is_nil(PPModule::PingObject_ptr p) { return CORBA::is_nil(p); } void PPModule::PingObject_Helper::release(PPModule::PingObject_ptr p) { CORBA::release(p); } void PPModule::PingObject_Helper::duplicate(PPModule::PingObject_ptr p) = { if( p && !p->_NP_is_nil() ) omni::duplicateObjRef(p); } size_t = PPModule::PingObject_Helper::NP_alignedSize(PPModule::PingObject_ptr = obj, size_t offset) { return PPModule::PingObject::_alignedSize(obj, offset); } void = PPModule::PingObject_Helper::marshalObjRef(PPModule::PingObject_ptr = obj, NetBufferedStream& s) { PPModule::PingObject::_marshalObjRef(obj, s); } PPModule::PingObject_ptr = PPModule::PingObject_Helper::unmarshalObjRef(NetBufferedStream& s) { return PPModule::PingObject::_unmarshalObjRef(s); } void = PPModule::PingObject_Helper::marshalObjRef(PPModule::PingObject_ptr = obj, MemBufferedStream& s) { PPModule::PingObject::_marshalObjRef(obj, s); } PPModule::PingObject_ptr = PPModule::PingObject_Helper::unmarshalObjRef(MemBufferedStream& s) { return PPModule::PingObject::_unmarshalObjRef(s); } PPModule::PingObject_ptr PPModule::PingObject::_duplicate(PPModule::PingObject_ptr obj) { if( obj && !obj->_NP_is_nil() ) omni::duplicateObjRef(obj); return obj; } PPModule::PingObject_ptr PPModule::PingObject::_narrow(CORBA::Object_ptr obj) { if( !obj || obj->_NP_is_nil() || obj->_NP_is_pseudo() ) return = _nil(); _ptr_type e =3D (_ptr_type) = obj->_PR_getobj()->_realNarrow(_PD_repoId); return e ? e : _nil(); } PPModule::PingObject_ptr PPModule::PingObject::_nil() { static _objref_PingObject* _the_nil_ptr =3D 0; if( !_the_nil_ptr ) { omni::nilRefLock().lock(); if( !_the_nil_ptr ) _the_nil_ptr =3D new _objref_PingObject; omni::nilRefLock().unlock(); } return _the_nil_ptr; } const char* PPModule::PingObject::_PD_repoId =3D = "IDL:PPModule/PingObject:1.0"; PPModule::_objref_PingObject::~_objref_PingObject() {} PPModule::_objref_PingObject::_objref_PingObject(const char* mdri, IOP::TaggedProfileList* p, omniIdentity* id, omniLocalIdentity* lid) = : =20 omniObjRef(PPModule::PingObject::_PD_repoId, mdri, p, id, lid) { _PR_setobj(this); } void* PPModule::_objref_PingObject::_ptrToObjRef(const char* id) { if( !strcmp(id, CORBA::Object::_PD_repoId) ) return (CORBA::Object_ptr) this; if( !strcmp(id, PPModule::PingObject::_PD_repoId) ) return (PPModule::PingObject_ptr) this; =20 return 0; } // Proxy call descriptor class. Mangled signature: // _clong_i_cPPModule_mPongObject_i_clong class _0RL_cd_2c3220a0b42d4471_00000000 : public omniCallDescriptor { public: inline _0RL_cd_2c3220a0b42d4471_00000000(LocalCallFn lcfn, const = char* op, size_t oplen, _CORBA_Boolean oneway, PPModule::PongObject_ptr = a_0, CORBA::Long a_1): omniCallDescriptor(lcfn, op, oplen, oneway), arg_0(a_0), arg_1(a_1) {} virtual CORBA::ULong alignedSize(CORBA::ULong size_in); virtual void marshalArguments(GIOP_C&); =20 virtual void unmarshalReturnedValues(GIOP_C&); =20 inline CORBA::Long result() { return pd_result; } PPModule::PongObject_ptr arg_0; CORBA::Long arg_1; CORBA::Long pd_result; }; CORBA::ULong = _0RL_cd_2c3220a0b42d4471_00000000::alignedSize(CORBA::ULong msgsize) { msgsize =3D PPModule::PongObject_Helper::NP_alignedSize(arg_0, = msgsize); =20 msgsize =3D omni::align_to(msgsize, omni::ALIGN_4) + 4; =20 return msgsize; } void _0RL_cd_2c3220a0b42d4471_00000000::marshalArguments(GIOP_C& = giop_client) { PPModule::PongObject_Helper::marshalObjRef(arg_0,giop_client); arg_1 >>=3D giop_client; =20 } void _0RL_cd_2c3220a0b42d4471_00000000::unmarshalReturnedValues(GIOP_C& = giop_client) { =20 pd_result <<=3D giop_client; =20 } // Local call call-back function. static void _0RL_lcfn_2c3220a0b42d4471_10000000(omniCallDescriptor* cd, = omniServant* svnt) { _0RL_cd_2c3220a0b42d4471_00000000* tcd =3D = (_0RL_cd_2c3220a0b42d4471_00000000*) cd; PPModule::_impl_PingObject* impl =3D (PPModule::_impl_PingObject*) = svnt->_ptrToInterface(PPModule::PingObject::_PD_repoId); tcd->pd_result =3D impl->ping(tcd->arg_0, tcd->arg_1); } CORBA::Long PPModule::_objref_PingObject::ping(PongObject_ptr po, = CORBA::Long count) { _0RL_cd_2c3220a0b42d4471_00000000 = _call_desc(_0RL_lcfn_2c3220a0b42d4471_10000000, "ping", 5, 0, po, = count); =20 _invoke(_call_desc); return _call_desc.result(); } // Proxy call descriptor class. Mangled signature: // _clong class _0RL_cd_2c3220a0b42d4471_20000000 : public omniCallDescriptor { public: inline _0RL_cd_2c3220a0b42d4471_20000000(LocalCallFn lcfn, const = char* op, size_t oplen, _CORBA_Boolean oneway): omniCallDescriptor(lcfn, op, oplen, oneway) {} virtual void unmarshalReturnedValues(GIOP_C&); =20 inline CORBA::Long result() { return pd_result; } =20 CORBA::Long pd_result; =20 }; void _0RL_cd_2c3220a0b42d4471_20000000::unmarshalReturnedValues(GIOP_C& = giop_client) { =20 pd_result <<=3D giop_client; =20 } // Proxy call descriptor class. Mangled signature: // void_i_clong class _0RL_cd_2c3220a0b42d4471_30000000 : public omniCallDescriptor { public: inline _0RL_cd_2c3220a0b42d4471_30000000(LocalCallFn lcfn, const = char* op, size_t oplen, _CORBA_Boolean oneway, CORBA::Long a_0): omniCallDescriptor(lcfn, op, oplen, oneway), arg_0(a_0) {} virtual CORBA::ULong alignedSize(CORBA::ULong); virtual void marshalArguments(GIOP_C&); =20 CORBA::Long arg_0; =20 }; CORBA::ULong = _0RL_cd_2c3220a0b42d4471_30000000::alignedSize(CORBA::ULong msgsize) { msgsize =3D omni::align_to(msgsize, omni::ALIGN_4) + 4; =20 return msgsize; } void _0RL_cd_2c3220a0b42d4471_30000000::marshalArguments(GIOP_C& = giop_client) { arg_0 >>=3D giop_client; =20 } // Local call call-back function. static void _0RL_lcfn_2c3220a0b42d4471_40000000(omniCallDescriptor* cd, = omniServant* svnt) { _0RL_cd_2c3220a0b42d4471_20000000* tcd =3D = (_0RL_cd_2c3220a0b42d4471_20000000*) cd; PPModule::_impl_PingObject* impl =3D (PPModule::_impl_PingObject*) = svnt->_ptrToInterface(PPModule::PingObject::_PD_repoId); tcd->pd_result =3D impl->maxPings(); } CORBA::Long PPModule::_objref_PingObject::maxPings() { _0RL_cd_2c3220a0b42d4471_20000000 = _call_desc(_0RL_lcfn_2c3220a0b42d4471_40000000, "_get_maxPings", 14, = 0); =20 _invoke(_call_desc); return _call_desc.result(); } // Local call call-back function. static void _0RL_lcfn_2c3220a0b42d4471_50000000(omniCallDescriptor* cd, = omniServant* svnt) { _0RL_cd_2c3220a0b42d4471_30000000* tcd =3D = (_0RL_cd_2c3220a0b42d4471_30000000*) cd; PPModule::_impl_PingObject* impl =3D (PPModule::_impl_PingObject*) = svnt->_ptrToInterface(PPModule::PingObject::_PD_repoId); impl->maxPings(tcd->arg_0); } void PPModule::_objref_PingObject::maxPings(CORBA::Long arg_0) { _0RL_cd_2c3220a0b42d4471_30000000 = _call_desc(_0RL_lcfn_2c3220a0b42d4471_50000000, "_set_maxPings", 14, 0, = arg_0); =20 _invoke(_call_desc); =20 } PPModule::_pof_PingObject::~_pof_PingObject() {} omniObjRef* PPModule::_pof_PingObject::newObjRef(const char* mdri, = IOP::TaggedProfileList* p, omniIdentity* id, omniLocalIdentity* lid) { return new PPModule::_objref_PingObject(mdri, p, id, lid); } CORBA::Boolean PPModule::_pof_PingObject::is_a(const char* id) const { if( !strcmp(id, PPModule::PingObject::_PD_repoId) ) return 1; =20 return 0; } const PPModule::_pof_PingObject _the_pof_PPModule_mPingObject; PPModule::_impl_PingObject::~_impl_PingObject() {} CORBA::Boolean PPModule::_impl_PingObject::_dispatch(GIOP_S& giop_s) { if( !strcmp(giop_s.operation(), "_get_maxPings") ) { =20 giop_s.RequestReceived(); CORBA::Long result =3D this->maxPings(); if( giop_s.response_expected() ) { size_t msgsize =3D (size_t) GIOP_S::ReplyHeaderSize(); msgsize =3D omni::align_to(msgsize, omni::ALIGN_4) + 4; =20 giop_s.InitialiseReply(GIOP::NO_EXCEPTION, (CORBA::ULong) = msgsize); result >>=3D giop_s; =20 } giop_s.ReplyCompleted(); return 1; } if( !strcmp(giop_s.operation(), "_set_maxPings") ) { CORBA::Long value; value <<=3D giop_s; =20 giop_s.RequestReceived(); this->maxPings(value); if( giop_s.response_expected() ) { size_t msgsize =3D (size_t) GIOP_S::ReplyHeaderSize(); giop_s.InitialiseReply(GIOP::NO_EXCEPTION, (CORBA::ULong) = msgsize); } giop_s.ReplyCompleted(); return 1; } if( !strcmp(giop_s.operation(), "ping") ) { =20 PongObject_var arg_po; =20 arg_po =3D PongObject_Helper::unmarshalObjRef(giop_s); CORBA::Long arg_count; =20 arg_count <<=3D giop_s; =20 giop_s.RequestReceived(); CORBA::Long result; =20 result =3D this->ping(arg_po.in(), arg_count); =20 if( giop_s.response_expected() ) { size_t msgsize =3D (size_t) GIOP_S::ReplyHeaderSize(); msgsize =3D omni::align_to(msgsize, omni::ALIGN_4) + 4; =20 giop_s.InitialiseReply(GIOP::NO_EXCEPTION, (CORBA::ULong) = msgsize); result >>=3D giop_s; =20 } giop_s.ReplyCompleted(); return 1; } return 0; } void* PPModule::_impl_PingObject::_ptrToInterface(const char* id) { if( !strcmp(id, CORBA::Object::_PD_repoId) ) return (void*) 1; if( !strcmp(id, PPModule::PingObject::_PD_repoId) ) return (_impl_PingObject*) this; =20 return 0; } const char* PPModule::_impl_PingObject::_mostDerivedRepoId() { return PPModule::PingObject::_PD_repoId; } PPModule::PongObject_ptr PPModule::PongObject_Helper::_nil() { return PPModule::PongObject::_nil(); } CORBA::Boolean = PPModule::PongObject_Helper::is_nil(PPModule::PongObject_ptr p) { return CORBA::is_nil(p); } void PPModule::PongObject_Helper::release(PPModule::PongObject_ptr p) { CORBA::release(p); } void PPModule::PongObject_Helper::duplicate(PPModule::PongObject_ptr p) = { if( p && !p->_NP_is_nil() ) omni::duplicateObjRef(p); } size_t = PPModule::PongObject_Helper::NP_alignedSize(PPModule::PongObject_ptr = obj, size_t offset) { return PPModule::PongObject::_alignedSize(obj, offset); } void = PPModule::PongObject_Helper::marshalObjRef(PPModule::PongObject_ptr = obj, NetBufferedStream& s) { PPModule::PongObject::_marshalObjRef(obj, s); } PPModule::PongObject_ptr = PPModule::PongObject_Helper::unmarshalObjRef(NetBufferedStream& s) { return PPModule::PongObject::_unmarshalObjRef(s); } void = PPModule::PongObject_Helper::marshalObjRef(PPModule::PongObject_ptr = obj, MemBufferedStream& s) { PPModule::PongObject::_marshalObjRef(obj, s); } PPModule::PongObject_ptr = PPModule::PongObject_Helper::unmarshalObjRef(MemBufferedStream& s) { return PPModule::PongObject::_unmarshalObjRef(s); } PPModule::PongObject_ptr PPModule::PongObject::_duplicate(PPModule::PongObject_ptr obj) { if( obj && !obj->_NP_is_nil() ) omni::duplicateObjRef(obj); return obj; } PPModule::PongObject_ptr PPModule::PongObject::_narrow(CORBA::Object_ptr obj) { if( !obj || obj->_NP_is_nil() || obj->_NP_is_pseudo() ) return = _nil(); _ptr_type e =3D (_ptr_type) = obj->_PR_getobj()->_realNarrow(_PD_repoId); return e ? e : _nil(); } PPModule::PongObject_ptr PPModule::PongObject::_nil() { static _objref_PongObject* _the_nil_ptr =3D 0; if( !_the_nil_ptr ) { omni::nilRefLock().lock(); if( !_the_nil_ptr ) _the_nil_ptr =3D new _objref_PongObject; omni::nilRefLock().unlock(); } return _the_nil_ptr; } const char* PPModule::PongObject::_PD_repoId =3D = "IDL:PPModule/PongObject:1.0"; PPModule::_objref_PongObject::~_objref_PongObject() {} PPModule::_objref_PongObject::_objref_PongObject(const char* mdri, IOP::TaggedProfileList* p, omniIdentity* id, omniLocalIdentity* lid) = : =20 omniObjRef(PPModule::PongObject::_PD_repoId, mdri, p, id, lid) { _PR_setobj(this); } void* PPModule::_objref_PongObject::_ptrToObjRef(const char* id) { if( !strcmp(id, CORBA::Object::_PD_repoId) ) return (CORBA::Object_ptr) this; if( !strcmp(id, PPModule::PongObject::_PD_repoId) ) return (PPModule::PongObject_ptr) this; =20 return 0; } // Proxy call descriptor class. Mangled signature: // _clong_i_cPPModule_mPingObject_i_clong class _0RL_cd_2c3220a0b42d4471_60000000 : public omniCallDescriptor { public: inline _0RL_cd_2c3220a0b42d4471_60000000(LocalCallFn lcfn, const = char* op, size_t oplen, _CORBA_Boolean oneway, PPModule::PingObject_ptr = a_0, CORBA::Long a_1): omniCallDescriptor(lcfn, op, oplen, oneway), arg_0(a_0), arg_1(a_1) {} virtual CORBA::ULong alignedSize(CORBA::ULong size_in); virtual void marshalArguments(GIOP_C&); =20 virtual void unmarshalReturnedValues(GIOP_C&); =20 inline CORBA::Long result() { return pd_result; } PPModule::PingObject_ptr arg_0; CORBA::Long arg_1; CORBA::Long pd_result; }; CORBA::ULong = _0RL_cd_2c3220a0b42d4471_60000000::alignedSize(CORBA::ULong msgsize) { msgsize =3D PPModule::PingObject_Helper::NP_alignedSize(arg_0, = msgsize); =20 msgsize =3D omni::align_to(msgsize, omni::ALIGN_4) + 4; =20 return msgsize; } void _0RL_cd_2c3220a0b42d4471_60000000::marshalArguments(GIOP_C& = giop_client) { PPModule::PingObject_Helper::marshalObjRef(arg_0,giop_client); arg_1 >>=3D giop_client; =20 } void _0RL_cd_2c3220a0b42d4471_60000000::unmarshalReturnedValues(GIOP_C& = giop_client) { =20 pd_result <<=3D giop_client; =20 } // Local call call-back function. static void _0RL_lcfn_2c3220a0b42d4471_70000000(omniCallDescriptor* cd, = omniServant* svnt) { _0RL_cd_2c3220a0b42d4471_60000000* tcd =3D = (_0RL_cd_2c3220a0b42d4471_60000000*) cd; PPModule::_impl_PongObject* impl =3D (PPModule::_impl_PongObject*) = svnt->_ptrToInterface(PPModule::PongObject::_PD_repoId); tcd->pd_result =3D impl->pong(tcd->arg_0, tcd->arg_1); } CORBA::Long PPModule::_objref_PongObject::pong(PingObject_ptr po, = CORBA::Long count) { _0RL_cd_2c3220a0b42d4471_60000000 = _call_desc(_0RL_lcfn_2c3220a0b42d4471_70000000, "pong", 5, 0, po, = count); =20 _invoke(_call_desc); return _call_desc.result(); } PPModule::_pof_PongObject::~_pof_PongObject() {} omniObjRef* PPModule::_pof_PongObject::newObjRef(const char* mdri, = IOP::TaggedProfileList* p, omniIdentity* id, omniLocalIdentity* lid) { return new PPModule::_objref_PongObject(mdri, p, id, lid); } CORBA::Boolean PPModule::_pof_PongObject::is_a(const char* id) const { if( !strcmp(id, PPModule::PongObject::_PD_repoId) ) return 1; =20 return 0; } const PPModule::_pof_PongObject _the_pof_PPModule_mPongObject; PPModule::_impl_PongObject::~_impl_PongObject() {} CORBA::Boolean PPModule::_impl_PongObject::_dispatch(GIOP_S& giop_s) { if( !strcmp(giop_s.operation(), "pong") ) { =20 PingObject_var arg_po; =20 arg_po =3D PingObject_Helper::unmarshalObjRef(giop_s); CORBA::Long arg_count; =20 arg_count <<=3D giop_s; =20 giop_s.RequestReceived(); CORBA::Long result; =20 result =3D this->pong(arg_po.in(), arg_count); =20 if( giop_s.response_expected() ) { size_t msgsize =3D (size_t) GIOP_S::ReplyHeaderSize(); msgsize =3D omni::align_to(msgsize, omni::ALIGN_4) + 4; =20 giop_s.InitialiseReply(GIOP::NO_EXCEPTION, (CORBA::ULong) = msgsize); result >>=3D giop_s; =20 } giop_s.ReplyCompleted(); return 1; } return 0; } void* PPModule::_impl_PongObject::_ptrToInterface(const char* id) { if( !strcmp(id, CORBA::Object::_PD_repoId) ) return (void*) 1; if( !strcmp(id, PPModule::PongObject::_PD_repoId) ) return (_impl_PongObject*) this; =20 return 0; } const char* PPModule::_impl_PongObject::_mostDerivedRepoId() { return PPModule::PongObject::_PD_repoId; } POA_PPModule::PingObject::~PingObject() {} POA_PPModule::PongObject::~PongObject() {} ------_=_NextPart_000_01C08B6D.4D160B10 Content-Type: application/octet-stream; name="pingpong.h" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pingpong.h" // This file is generated by omniidl (C++ backend)- omniORB_3_0. Do not = edit. #ifndef __pingpong_hh__ #define __pingpong_hh__ #ifndef USE_omniORB_logStream #define USE_omniORB_logStream #endif #ifndef __CORBA_H_EXTERNAL_GUARD__ #include #endif #ifndef USE_core_stub_in_nt_dll # define USE_core_stub_in_nt_dll_NOT_DEFINED_pingpong #endif #ifndef USE_dyn_stub_in_nt_dll # define USE_dyn_stub_in_nt_dll_NOT_DEFINED_pingpong #endif #ifdef USE_stub_in_nt_dll #ifndef USE_core_stub_in_nt_dll #define USE_core_stub_in_nt_dll #endif #ifndef USE_dyn_stub_in_nt_dll #define USE_dyn_stub_in_nt_dll #endif #endif #ifdef _core_attr # error "A local CPP macro _core_attr has already been defined." #else # ifdef USE_core_stub_in_nt_dll # define _core_attr _OMNIORB_NTDLL_IMPORT # else # define _core_attr # endif #endif #ifdef _dyn_attr # error "A local CPP macro _dyn_attr has already been defined." #else # ifdef USE_dyn_stub_in_nt_dll # define _dyn_attr _OMNIORB_NTDLL_IMPORT # else # define _dyn_attr # endif #endif _CORBA_MODULE PPModule _CORBA_MODULE_BEG #ifndef __PPModule_mPongObject__ #define __PPModule_mPongObject__ class PongObject; class _objref_PongObject; class _impl_PongObject; =20 typedef _objref_PongObject* PongObject_ptr; typedef PongObject_ptr PongObjectRef; class PongObject_Helper { public: typedef PongObject_ptr _ptr_type; static _ptr_type _nil(); static _CORBA_Boolean is_nil(_ptr_type); static void release(_ptr_type); static void duplicate(_ptr_type); static size_t NP_alignedSize(_ptr_type, size_t); static void marshalObjRef(_ptr_type, NetBufferedStream&); static _ptr_type unmarshalObjRef(NetBufferedStream&); static void marshalObjRef(_ptr_type, MemBufferedStream&); static _ptr_type unmarshalObjRef(MemBufferedStream&); }; typedef _CORBA_ObjRef_Var<_objref_PongObject, PongObject_Helper> = PongObject_var; typedef _CORBA_ObjRef_OUT_arg<_objref_PongObject,PongObject_Helper > = PongObject_out; #endif #ifndef __PPModule_mPingObject__ #define __PPModule_mPingObject__ class PingObject; class _objref_PingObject; class _impl_PingObject; =20 typedef _objref_PingObject* PingObject_ptr; typedef PingObject_ptr PingObjectRef; class PingObject_Helper { public: typedef PingObject_ptr _ptr_type; static _ptr_type _nil(); static _CORBA_Boolean is_nil(_ptr_type); static void release(_ptr_type); static void duplicate(_ptr_type); static size_t NP_alignedSize(_ptr_type, size_t); static void marshalObjRef(_ptr_type, NetBufferedStream&); static _ptr_type unmarshalObjRef(NetBufferedStream&); static void marshalObjRef(_ptr_type, MemBufferedStream&); static _ptr_type unmarshalObjRef(MemBufferedStream&); }; typedef _CORBA_ObjRef_Var<_objref_PingObject, PingObject_Helper> = PingObject_var; typedef _CORBA_ObjRef_OUT_arg<_objref_PingObject,PingObject_Helper > = PingObject_out; #endif class PingObject { public: // Declarations for this interface type. typedef PingObject_ptr _ptr_type; typedef PingObject_var _var_type; static _ptr_type _duplicate(_ptr_type); static _ptr_type _narrow(CORBA::Object_ptr); static _ptr_type _nil(); static inline size_t _alignedSize(_ptr_type, size_t); static inline void _marshalObjRef(_ptr_type, NetBufferedStream&); static inline void _marshalObjRef(_ptr_type, MemBufferedStream&); static inline _ptr_type _unmarshalObjRef(NetBufferedStream& s) { CORBA::Object_ptr obj =3D CORBA::UnMarshalObjRef(_PD_repoId, s); _ptr_type result =3D _narrow(obj); CORBA::release(obj); return result; } static inline _ptr_type _unmarshalObjRef(MemBufferedStream& s) { CORBA::Object_ptr obj =3D CORBA::UnMarshalObjRef(_PD_repoId, s); _ptr_type result =3D _narrow(obj); CORBA::release(obj); return result; } static _core_attr const char* _PD_repoId; // Other IDL defined within this scope. =20 }; class _objref_PingObject : public virtual CORBA::Object, public virtual omniObjRef { public: CORBA::Long ping(PongObject_ptr po, CORBA::Long count); =20 CORBA::Long maxPings(); void maxPings(CORBA::Long); =20 inline _objref_PingObject() { _PR_setobj(0); } // nil _objref_PingObject(const char*, IOP::TaggedProfileList*, = omniIdentity*, omniLocalIdentity*); protected: virtual ~_objref_PingObject(); private: virtual void* _ptrToObjRef(const char*); _objref_PingObject(const _objref_PingObject&); _objref_PingObject& operator =3D (const _objref_PingObject&); // not implemented }; class _pof_PingObject : public proxyObjectFactory { public: inline _pof_PingObject() : = proxyObjectFactory(PingObject::_PD_repoId) {} virtual ~_pof_PingObject(); virtual omniObjRef* newObjRef(const char*, IOP::TaggedProfileList*, omniIdentity*, omniLocalIdentity*); virtual _CORBA_Boolean is_a(const char*) const; }; class _impl_PingObject : public virtual omniServant { public: virtual ~_impl_PingObject(); virtual CORBA::Long ping(PongObject_ptr po, CORBA::Long count) =3D = 0; =20 virtual CORBA::Long maxPings() =3D 0; virtual void maxPings(CORBA::Long) =3D 0; =20 public: // Really protected, workaround for xlC virtual _CORBA_Boolean _dispatch(GIOP_S&); private: virtual void* _ptrToInterface(const char*); virtual const char* _mostDerivedRepoId(); }; #ifndef __PPModule_mPongObject__ #define __PPModule_mPongObject__ class PongObject; class _objref_PongObject; class _impl_PongObject; =20 typedef _objref_PongObject* PongObject_ptr; typedef PongObject_ptr PongObjectRef; class PongObject_Helper { public: typedef PongObject_ptr _ptr_type; static _ptr_type _nil(); static _CORBA_Boolean is_nil(_ptr_type); static void release(_ptr_type); static void duplicate(_ptr_type); static size_t NP_alignedSize(_ptr_type, size_t); static void marshalObjRef(_ptr_type, NetBufferedStream&); static _ptr_type unmarshalObjRef(NetBufferedStream&); static void marshalObjRef(_ptr_type, MemBufferedStream&); static _ptr_type unmarshalObjRef(MemBufferedStream&); }; typedef _CORBA_ObjRef_Var<_objref_PongObject, PongObject_Helper> = PongObject_var; typedef _CORBA_ObjRef_OUT_arg<_objref_PongObject,PongObject_Helper > = PongObject_out; #endif class PongObject { public: // Declarations for this interface type. typedef PongObject_ptr _ptr_type; typedef PongObject_var _var_type; static _ptr_type _duplicate(_ptr_type); static _ptr_type _narrow(CORBA::Object_ptr); static _ptr_type _nil(); static inline size_t _alignedSize(_ptr_type, size_t); static inline void _marshalObjRef(_ptr_type, NetBufferedStream&); static inline void _marshalObjRef(_ptr_type, MemBufferedStream&); static inline _ptr_type _unmarshalObjRef(NetBufferedStream& s) { CORBA::Object_ptr obj =3D CORBA::UnMarshalObjRef(_PD_repoId, s); _ptr_type result =3D _narrow(obj); CORBA::release(obj); return result; } static inline _ptr_type _unmarshalObjRef(MemBufferedStream& s) { CORBA::Object_ptr obj =3D CORBA::UnMarshalObjRef(_PD_repoId, s); _ptr_type result =3D _narrow(obj); CORBA::release(obj); return result; } static _core_attr const char* _PD_repoId; // Other IDL defined within this scope. =20 }; class _objref_PongObject : public virtual CORBA::Object, public virtual omniObjRef { public: CORBA::Long pong(PingObject_ptr po, CORBA::Long count); =20 inline _objref_PongObject() { _PR_setobj(0); } // nil _objref_PongObject(const char*, IOP::TaggedProfileList*, = omniIdentity*, omniLocalIdentity*); protected: virtual ~_objref_PongObject(); private: virtual void* _ptrToObjRef(const char*); _objref_PongObject(const _objref_PongObject&); _objref_PongObject& operator =3D (const _objref_PongObject&); // not implemented }; class _pof_PongObject : public proxyObjectFactory { public: inline _pof_PongObject() : = proxyObjectFactory(PongObject::_PD_repoId) {} virtual ~_pof_PongObject(); virtual omniObjRef* newObjRef(const char*, IOP::TaggedProfileList*, omniIdentity*, omniLocalIdentity*); virtual _CORBA_Boolean is_a(const char*) const; }; class _impl_PongObject : public virtual omniServant { public: virtual ~_impl_PongObject(); virtual CORBA::Long pong(PingObject_ptr po, CORBA::Long count) =3D = 0; =20 public: // Really protected, workaround for xlC virtual _CORBA_Boolean _dispatch(GIOP_S&); private: virtual void* _ptrToInterface(const char*); virtual const char* _mostDerivedRepoId(); }; _CORBA_MODULE_END _CORBA_MODULE POA_PPModule _CORBA_MODULE_BEG class PingObject : public virtual PPModule::_impl_PingObject, public virtual PortableServer::ServantBase { public: virtual ~PingObject(); inline PPModule::PingObject_ptr _this() { return (PPModule::PingObject_ptr) = _do_this(PPModule::PingObject::_PD_repoId); } }; template class PingObject_tie : public virtual PingObject { public: PingObject_tie(_omniT& t) : pd_obj(&t), pd_poa(0), pd_rel(0) {} PingObject_tie(_omniT& t, PortableServer::POA_ptr p) : pd_obj(&t), pd_poa(p), pd_rel(0) {} PingObject_tie(_omniT* t, CORBA::Boolean r=3D1) : pd_obj(t), pd_poa(0), pd_rel(r) {} PingObject_tie(_omniT* t, PortableServer::POA_ptr p,CORBA::Boolean = r=3D1) : pd_obj(t), pd_poa(p), pd_rel(r) {} ~PingObject_tie() { if( pd_poa ) CORBA::release(pd_poa); if( pd_rel ) delete pd_obj; } _omniT* _tied_object() { return pd_obj; } void _tied_object(_omniT& t) { if( pd_rel ) delete pd_obj; pd_obj =3D &t; pd_rel =3D 0; } void _tied_object(_omniT* t, CORBA::Boolean r=3D1) { if( pd_rel ) delete pd_obj; pd_obj =3D t; pd_rel =3D r; } CORBA::Boolean _is_owner() { return pd_rel; } void _is_owner(CORBA::Boolean io) { pd_rel =3D io; } PortableServer::POA_ptr _default_POA() { if( !pd_poa ) return PortableServer::POA::_the_root_poa(); else return PortableServer::POA::_duplicate(pd_poa); } CORBA::Long ping(PPModule::PongObject_ptr po, CORBA::Long count) { = return pd_obj->ping(po, count); } CORBA::Long maxPings() { return pd_obj->maxPings(); } void maxPings(CORBA::Long _value) { pd_obj->maxPings(_value); } =20 private: _omniT* pd_obj; PortableServer::POA_ptr pd_poa; CORBA::Boolean pd_rel; }; class PongObject : public virtual PPModule::_impl_PongObject, public virtual PortableServer::ServantBase { public: virtual ~PongObject(); inline PPModule::PongObject_ptr _this() { return (PPModule::PongObject_ptr) = _do_this(PPModule::PongObject::_PD_repoId); } }; template class PongObject_tie : public virtual PongObject { public: PongObject_tie(_omniT& t) : pd_obj(&t), pd_poa(0), pd_rel(0) {} PongObject_tie(_omniT& t, PortableServer::POA_ptr p) : pd_obj(&t), pd_poa(p), pd_rel(0) {} PongObject_tie(_omniT* t, CORBA::Boolean r=3D1) : pd_obj(t), pd_poa(0), pd_rel(r) {} PongObject_tie(_omniT* t, PortableServer::POA_ptr p,CORBA::Boolean = r=3D1) : pd_obj(t), pd_poa(p), pd_rel(r) {} ~PongObject_tie() { if( pd_poa ) CORBA::release(pd_poa); if( pd_rel ) delete pd_obj; } _omniT* _tied_object() { return pd_obj; } void _tied_object(_omniT& t) { if( pd_rel ) delete pd_obj; pd_obj =3D &t; pd_rel =3D 0; } void _tied_object(_omniT* t, CORBA::Boolean r=3D1) { if( pd_rel ) delete pd_obj; pd_obj =3D t; pd_rel =3D r; } CORBA::Boolean _is_owner() { return pd_rel; } void _is_owner(CORBA::Boolean io) { pd_rel =3D io; } PortableServer::POA_ptr _default_POA() { if( !pd_poa ) return PortableServer::POA::_the_root_poa(); else return PortableServer::POA::_duplicate(pd_poa); } CORBA::Long pong(PPModule::PingObject_ptr po, CORBA::Long count) { = return pd_obj->pong(po, count); } =20 private: _omniT* pd_obj; PortableServer::POA_ptr pd_poa; CORBA::Boolean pd_rel; }; _CORBA_MODULE_END #undef _core_attr #undef _dyn_attr inline size_t PPModule::PingObject::_alignedSize(PPModule::PingObject_ptr obj, size_t = offset) { return CORBA::AlignedObjRef(obj, _PD_repoId, 28, offset); } inline void PPModule::PingObject::_marshalObjRef(PPModule::PingObject_ptr obj, = NetBufferedStream& s) { CORBA::MarshalObjRef(obj, _PD_repoId, 28, s); } inline void PPModule::PingObject::_marshalObjRef(PPModule::PingObject_ptr obj, = MemBufferedStream& s) { CORBA::MarshalObjRef(obj, _PD_repoId, 28, s); } inline size_t PPModule::PongObject::_alignedSize(PPModule::PongObject_ptr obj, size_t = offset) { return CORBA::AlignedObjRef(obj, _PD_repoId, 28, offset); } inline void PPModule::PongObject::_marshalObjRef(PPModule::PongObject_ptr obj, = NetBufferedStream& s) { CORBA::MarshalObjRef(obj, _PD_repoId, 28, s); } inline void PPModule::PongObject::_marshalObjRef(PPModule::PongObject_ptr obj, = MemBufferedStream& s) { CORBA::MarshalObjRef(obj, _PD_repoId, 28, s); } #ifdef USE_core_stub_in_nt_dll_NOT_DEFINED_pingpong # undef USE_core_stub_in_nt_dll # undef USE_core_stub_in_nt_dll_NOT_DEFINED_pingpong #endif #ifdef USE_dyn_stub_in_nt_dll_NOT_DEFINED_pingpong # undef USE_dyn_stub_in_nt_dll # undef USE_dyn_stub_in_nt_dll_NOT_DEFINED_pingpong #endif #endif // __pingpong_hh__ ------_=_NextPart_000_01C08B6D.4D160B10 Content-Type: application/octet-stream; name="pingpong.idl" Content-Disposition: attachment; filename="pingpong.idl" module PPModule { interface PongObject; interface PingObject { attribute long maxPings; long ping(in PongObject po, in long count); }; interface PongObject { long pong(in PingObject po, in long count); }; }; ------_=_NextPart_000_01C08B6D.4D160B10 Content-Type: application/octet-stream; name="pong_i.cpp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pong_i.cpp" // // Example code for implementing IDL interfaces in file pingpong.idl // #include #include "pingpong.h" CORBA::Object_ptr getObjectReference(CosNaming::NamingContext_var = rootContext, const char *); CosNaming::NamingContext_var getObjectNameService(CORBA::ORB_ptr orb); CORBA::Boolean bindObjectToName(CosNaming::NamingContext_var = rootContext,=20 const char *,=20 CORBA::Object_ptr); // // Example class implementing IDL interface PPModule::PongObject // class PPModule_PongObject_i: public POA_PPModule::PongObject, public PortableServer::RefCountServantBase=20 { private: // Make sure all instances are built on the heap by making the // destructor non-public //virtual ~PPModule_PongObject_i(); public: // standard constructor PPModule_PongObject_i(); virtual ~PPModule_PongObject_i(); // methods corresponding to defined IDL attributes and operations CORBA::Long pong(PPModule::PingObject_ptr po, CORBA::Long count); }; // // Example implementational code for IDL interface = PPModule::PongObject // PPModule_PongObject_i::PPModule_PongObject_i() { // add extra constructor code here } PPModule_PongObject_i::~PPModule_PongObject_i() { // add extra destructor code here } // Methods corresponding to IDL attributes and operations CORBA::Long PPModule_PongObject_i::pong(PPModule::PingObject_ptr po,=20 CORBA::Long count) { int hilf =3D count; // insert code here and remove the warning cout << endl << "C++ pong: " << hilf << endl; count =3D po->ping(_this(), count + 1); cout << endl << "C++ pong - Ende: " << hilf << endl; return count; } // End of example implementational code int main(int argc, char** argv) { try=20 { // Initialise the ORB. CORBA::ORB_var orb =3D CORBA::ORB_init(argc, argv, "omniORB3"); // Obtain a reference to the root POA. CORBA::Object_var obj =3D orb->resolve_initial_references("RootPOA"); PortableServer::POA_var poa =3D PortableServer::POA::_narrow(obj); // We allocate the objects on the heap. Since these are reference // counted objects, they will be deleted by the POA when they are no // longer needed. PPModule_PongObject_i* myPPModule_PongObject_i =3D new = PPModule_PongObject_i(); =20 // Activate the objects. This tells the POA that the objects are // ready to accept requests. PortableServer::ObjectId_var myPPModule_PongObject_iid =3D = poa->activate_object(myPPModule_PongObject_i); =20 =09 CosNaming::NamingContext_var rootContext =3D = getObjectNameService(orb); CORBA::Object_var pingobj =3D getObjectReference(rootContext, = "Ping"); PPModule::PingObject_var pingref =3D = PPModule::PingObject::_narrow(pingobj); =20 CORBA::Object_var ref =3D myPPModule_PongObject_i->_this(); CORBA::String_var sior(orb->object_to_string(ref)); cout << "IDL object PPModule::PongObject IOR =3D '" << (char*)sior << = "'" << endl; if (!bindObjectToName(rootContext, "Pong", ref)) return 1; =09 // Obtain a POAManager, and tell the POA to start accepting // requests on its objects. PortableServer::POAManager_var pman =3D poa->the_POAManager(); pman->activate(); PPModule::PongObject_var pong =3D myPPModule_PongObject_i->_this(); myPPModule_PongObject_i->_remove_ref(); cout << "C++ vor Ping: orb->run"; pingref->ping(pong, 1); cout << "C++ vor Run: orb->run"; //orb->run(); cout << "C++ vor Beenden: orb->destroy"; orb->destroy(); } catch(CORBA::SystemException&)=20 { cerr << "Caught CORBA::SystemException." << endl; } catch(CORBA::Exception&)=20 { cerr << "Caught CORBA::Exception." << endl; } catch(omniORB::fatalException& fe)=20 { cerr << "Caught omniORB::fatalException:" << endl; cerr << " file: " << fe.file() << endl; cerr << " line: " << fe.line() << endl; cerr << " mesg: " << fe.errmsg() << endl; } catch(...)=20 { cerr << "Caught unknown exception." << endl; } return 0; } CosNaming::NamingContext_var getObjectNameService(CORBA::ORB_ptr orb) { CosNaming::NamingContext_var rootContext; try { // Eine Referenz auf den Stammkontext des Namesdienstes holen: CORBA::Object_var obj; obj =3D orb->resolve_initial_references("NameService"); // Narrow the reference returned rootContext =3D CosNaming::NamingContext::_narrow(obj); if (CORBA::is_nil(rootContext)) { cerr << "Failed to narrow the root naming context." << endl; return 0; } } catch (CORBA::ORB::InvalidName&) { // This should not happen! cerr << "Service required is invalid [does not exist]." << endl; return 0; } return rootContext; } CORBA::Object_ptr getObjectReference(CosNaming::NamingContext_var = rootContext, const char * name) { =09 CosNaming::Name contextName; contextName.length(1); contextName[0].id =3D name; contextName[0].kind =3D ""; // Note on kind: The kind field is used to indicate the type of the // object. This is to avoid conventions such as that used by files // (name.type -- e.g. test.ps =3D postscript etc.) try { // Resolve the name to an object reference return rootContext->resolve(contextName); } catch (CosNaming::NamingContext::NotFound&) { // This exception is thrown if any of the components of the // path [contexts or the object] aren't found: cerr << "Context not found." << endl; } catch (CORBA::COMM_FAILURE&) { cerr << "Caught system exception COMM_FAILURE -- unable to" << "contact the naming service." << endl; } catch (CORBA::SystemException&) { cerr << "Caught a CORBA::SystemException while using the " << "naming service." << endl; } return CORBA::Object::_nil(); } CORBA::Boolean bindObjectToName(CosNaming::NamingContext_var = rootContext,=20 const char name[], CORBA::Object_ptr objref) { try { cout << "Einen Kontext names corejava an den Stammkontext binden" << = endl; // Einen Kontext names "corejava" an den Stammkontext binden: CosNaming::Name contextName; contextName.length(1); contextName[0].id =3D (const char*)name; contextName[0].kind =3D (const char*)""; CosNaming::NamingContext_var corejavaContext; =09 try { cout << "Kontext an Stamm binden um ihm testContext zuweisen:" << = endl; // Kontext an Stamm binden um ihm testContext zuweisen: //corejavaContext =3D=20 rootContext->rebind(contextName, = objref);//bind_new_context(contextName); cout << "Kontext an Stamm binden um ihm testContext zuweisen -Ende" = << endl; } catch (CosNaming::NamingContext::AlreadyBound&) { // Wenn Kontext bereits vorhanden, wird diese Ausnahme ausgel=F6st. // In diesem Fall einfach den Namen aufl=F6sen und testContext // an das zur=FCckgegebene Objekt zuweisen: CORBA::Object_var contextObj =3D rootContext->resolve(contextName); corejavaContext =3D CosNaming::NamingContext::_narrow(contextObj); if (CORBA::is_nil(corejavaContext)) { cerr << "Kann Kontext corejava nicht einengen." << endl; return 0; } } =09 } catch (CORBA::COMM_FAILURE&) { cerr << "Caught system exception COMM_FAILURE -- unable to contact = the naming service." << endl; return 0; } return 1; } ------_=_NextPart_000_01C08B6D.4D160B10-- From dgrisby@uk.research.att.com Wed Jan 31 11:20:29 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 31 Jan 2001 11:20:29 +0000 Subject: [omniORB] More on any's... In-Reply-To: Message from vonWedel@lfpt.rwth-aachen.de of "Mon, 22 Jan 2001 15:46:21 +0100." Message-ID: <200101311120.LAA10751@pineapple.uk.research.att.com> On Monday 22 January, vonWedel@lfpt.rwth-aachen.de wrote: > The patch from last week (bug #7) worked fine, now it seems > that there is a problem in coercing an any into a certain type > using the proprietary omniORB way, giving a type code > as an argument to the value function of the any. However, > it returns None when I call it the first time and returns an > object reference (in this case) only when calling it a second > time... How strange. I don't know why that would happen, since the coercion shouldn't affect the Any at all. If it failed the first time, it should fail again. What are the types of the thing in the Any, and the thing you are trying to coerce to? Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From hupfer@ivi.iitb.fhg.de Wed Jan 31 15:20:46 2001 From: hupfer@ivi.iitb.fhg.de (Ralf Hupfer) Date: Wed, 31 Jan 2001 16:20:46 +0100 Subject: [omniORB] Books about omniORB? Message-ID: <3A783B5E.25152.7B9200@localhost> Hi Everybody, Does anybody know whether there are books available covering programming issues of CORBA in general and omniORB 3 specifically? The documentation provided is rather poor :-(( Thanks Ralf From dgrisby@uk.research.att.com Wed Jan 31 15:30:47 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 31 Jan 2001 15:30:47 +0000 Subject: [omniORB] marshal exceptions in omniORBpy In-Reply-To: Message from Timothy Docker of "Tue, 30 Jan 2001 21:13:02 +1100." <14966.37544.192783.868352@tcc2> Message-ID: <200101311530.PAA13245@pineapple.uk.research.att.com> On Tuesday 30 January, Timothy Docker wrote: > Given that I know the remote operation has completed, shouldn't the > status be COMPLETED_YES or perhaps COMPLETED_MAYBE? Yes, you're right. The exception should have status COMPLETED_YES. Unfortunately, it's not a trivial thing to fix, but the next major release of omniORBpy will get it right. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From seefeld@sympatico.ca Wed Jan 31 16:46:30 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 31 Jan 2001 11:46:30 -0500 Subject: [omniORB] marshal exceptions in omniORBpy References: <200101311530.PAA13245@pineapple.uk.research.att.com> Message-ID: <3A784166.BC69FDD7@sympatico.ca> Duncan Grisby wrote: > > On Tuesday 30 January, Timothy Docker wrote: > > > Given that I know the remote operation has completed, shouldn't the > > status be COMPLETED_YES or perhaps COMPLETED_MAYBE? > > Yes, you're right. The exception should have status COMPLETED_YES. > Unfortunately, it's not a trivial thing to fix, but the next major > release of omniORBpy will get it right. ...which brings me to another question: are there plans to support the new Messaging QoS framework ? From jdeng@kcco.com Wed Jan 31 16:27:21 2001 From: jdeng@kcco.com (Jian Deng) Date: Wed, 31 Jan 2001 10:27:21 -0600 Subject: [omniORB] Books about omniORB? References: <3A783B5E.25152.7B9200@localhost> Message-ID: <3A783CE9.1E453B4@kcco.com> Ralf Hupfer wrote: > > Does anybody know whether there are books available covering > programming issues of CORBA in general and omniORB 3 > specifically? The documentation provided is rather poor :-(( > more less on that line: is there a road map covering the upgrade from 2.8.0 to 3.0.2? i just found out that 3.0.2's idl does not generate _sk_XXX classes, which was part of 2.8.0's. am i missing something? thanks, - jd From seefeld@sympatico.ca Wed Jan 31 17:53:25 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 31 Jan 2001 12:53:25 -0500 Subject: [omniORB] Books about omniORB? References: <3A783B5E.25152.7B9200@localhost> <3A783CE9.1E453B4@kcco.com> Message-ID: <3A785115.41A7A054@sympatico.ca> Jian Deng wrote: > > Ralf Hupfer wrote: > > > > > Does anybody know whether there are books available covering > > programming issues of CORBA in general and omniORB 3 > > specifically? The documentation provided is rather poor :-(( > > > > more less on that line: is there a road map covering the upgrade from > 2.8.0 to 3.0.2? i just found out that 3.0.2's idl does not generate > _sk_XXX classes, which was part of 2.8.0's. am i missing something? yes. One of the major changes from 2.8 to 3.0 was the introduction of POA support. you can tell omniidl to create skeletons for the POA, or for the BOA. While the old _sk_XXX skeletons are BOA specific (and therefor non- portable), the new skeletons are called POA_XXX, which is part of the CORBA specs. I.e. using the POA you can write portable software that compiles with any ORB. Of course, there are lots of other points about POA vs. BOA. Read about them in "Advanced CORBA programming with C++" by Henning and Vinoski. To generate the old skeletons, you have to use omniidl -bcxx -WbBOA Regards, Stefan From laurent.pointal@lure.u-psud.fr Wed Jan 31 17:21:16 2001 From: laurent.pointal@lure.u-psud.fr (Laurent Pointal) Date: Wed, 31 Jan 2001 18:21:16 +0100 Subject: [omniORB] Books about omniORB? In-Reply-To: <3A783CE9.1E453B4@kcco.com> References: <3A783B5E.25152.7B9200@localhost> Message-ID: <4.2.0.58.20010131182026.00a11820@webmail.lure.u-psud.fr> At 10:27 31/01/2001 -0600, Jian Deng wrote: >Ralf Hupfer wrote: > > > > > Does anybody know whether there are books available covering > > programming issues of CORBA in general and omniORB 3 > > specifically? The documentation provided is rather poor :-(( > > > >more less on that line: is there a road map covering the upgrade from >2.8.0 to 3.0.2? i just found out that 3.0.2's idl does not generate >_sk_XXX classes, which was part of 2.8.0's. am i missing something? Here is the omniidl arguments I use to switch from OmniORB 2.7.1 to 3.0.2: omniidl -bcxx -v -WbBOA -Wbs=SK.cpp myidlfile.idl A+ Laurent. --- Laurent POINTAL - CNRS/LURE - Service Informatique Experiences Tel/fax: 01 64 46 82 80 / 01 64 46 41 48 email : laurent.pointal@lure.u-psud.fr ou lpointal@planete.net ou laurent.pointal@laposte.net From rsimkin@htc.com Wed Jan 31 16:33:48 2001 From: rsimkin@htc.com (Simkin, Rick) Date: Wed, 31 Jan 2001 10:33:48 -0600 Subject: [omniORB] Books about omniORB? Message-ID: <5322DB90D4F5D411B693009027B0A75C0BC5E7@hlch01e.htc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08BA3.97EFE998 Content-Type: text/plain; charset="iso-8859-1" Ralf Hupfer wrote: > Does anybody know whether there are books available covering > programming issues of CORBA in general When I asked this question, the consensus opinion was Advanced CORBA Programming with C++ by Michi Henning and Steve Vinoski [1999. Reading, MA, USA] Addison-Wesley ISBN 0-201-37927-9 I'm sure this question comes up frequently, but I haven't found this answer in any FAQ that I've seen. ================ I speak for myself, not my employer ================= Rick Simkin rick.simkin@htc.com +1 (312) 697-2949 Goldman Sachs/Hull Group * 311 S. Wacker #1400 * Chicago IL 60606-6623 ------_=_NextPart_001_01C08BA3.97EFE998 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [omniORB] Books about omniORB?

Ralf Hupfer wrote:
> Does anybody know whether there are books = available covering
> programming issues of CORBA in general

When I asked this question, the consensus opinion = was

    Advanced CORBA Programming with = C++
    by Michi Henning and Steve = Vinoski
    [1999. Reading, MA, USA] = Addison-Wesley
    ISBN 0-201-37927-9

I'm sure this question comes up frequently, but I = haven't found
this answer in any FAQ that I've seen.

------_=_NextPart_001_01C08BA3.97EFE998-- From Mark Borges Wed Jan 31 19:29:21 2001 From: Mark Borges (Mark Borges) Date: 31 Jan 2001 11:29:21 -0800 Subject: [omniORB] OrbixNames-1.1c and omniORB (again) Message-ID: --=-=-= I realize that the issue of omniORB using the OrbixNames CosNaming implementation has been raised on this list long, long ago. However, I am somewhat puzzled by the fact that the omniORB utility, nameclt, gets different results than an omniORBpy script, "get_orbix_ior.py" that I wrote (see attached). Using the same /etc/omniORB.cfg file of the form, ORBInitRef NameService=IOR: the nameclt utility returns the IOR[1] for a resolve request, IOR:000000000000002249444c3a74726f75626c655265706f72745f526571576f4d676d7449663a312e30000000000000010000000000000066000100000000001874737477666d732e6e776573742e61747477732e636f6d00062200000000003e3a5c74737477666d732e6e776573742e61747477732e636f6d3a616d733a303a3a49523a74726f75626c655265706f72745f526571576f4d676d74496600 whereas a resolve request on the _narrow()'d object in the python script gives, ---------- omniORB: The object with the IR repository ID: IDL:omg.org/CosNaming/NamingContext:1.0 returns FALSE to the query _is_a("IDL:omg.org/CosNaming/NamingContext:1.0"). A CORBA::INV_OBJREF is raised. ---------- The puzzling thing (to me at least) is that if I don't _narrow() in "get_orbix_ior.py", I get the same IOR as nameclt returns. Obviously, I'm misunderstanding something, but it appears to me that both nameclt and the python script should attempt to narrow the object returned by the initial resolve_initial_references("NameService") call. I'm also attaching output obtained with "-ORBtraceLevel 20" for both nameclt and get_orbix_ior.py in case it helps diagnose the problem and/or misunderstanding. Another minor observation. Using "nameclt list", I get ObjectGroups/ ams.ams pwan.pwan/ srms.srms list: Unexpected error encountered. Not sure what that last "unexpected error encountered" refers to, but I did capture a trace for it as well. These results were obtained using the latest CVS snapshot of omniORB/omniORBpy (01/31/01, "omni3_develop" tag) under Solaris-2.6 and built with gcc-2.95.2. For reference, the specific version of Orbix and OrbixNames I'm attempting to interact with[2] are, ---------- $ orbixd -v OrbixSSL Java enabled daemon v2.3c02-26 s1193-2.3c02-26: Orbix Version v2.3c02-26 for SunPro SPARCompiler C++ 4.1 on Solaris 2.x $ ns -v [ s1224: OrbixNames (Release 1.1) ] [ s1369: OrbixOTM package (Release 1.0) ] ---------- Thanks for any help, insight, or pointers you can share. -- -mb- Footnotes: [1] I realize this returned IOR has the bogus underscore problem, but that's another issue. [2] I know, I should throw up the white flag and surrender with this attempt :-) --=-=-= Content-Disposition: attachment; filename=get_orbix_ior.py Content-Description: get_orbix_ior.py #!/usr/bin/env python import sys, os # extend the PYTHONPATH sys.path.extend(['/opt/omniORB/lib','/opt/omniORB/lib/python']) # Import the CORBA module from omniORB import CORBA # ----------------------------------------------------------------------- #def getObjectFromName(orb,nam): def getObjectFromName(orb,name,path=None): """Retrieve an object reference using CORBAService's name service (CosNaming). PATH is an array of (name,kind) tuples, leading to the object reference bound to NAME, itself a (name,kind) tuple.""" import sys, CosNaming # build up to the end of the naming contexts my_name = [] if path is not None: for (n,k) in path: my_name = my_name + [CosNaming.NameComponent(n,k)] # add in the object name itself my_name = my_name + [CosNaming.NameComponent(name[0],name[1])] obj = None # Obtain a reference to the root context of the Name service: testObj = orb.resolve_initial_references("NameService") # This _narrow() implicitly calls _is_a(), which fails for Orbix-2.3c; # it returns FALSE(?!) so we cannot use it: # ---------- # omniORB: The object with the IR repository ID: IDL:omg.org/CosNaming/NamingContext:1.0 # returns FALSE to the query _is_a("IDL:omg.org/CosNaming/NamingContext:1.0"). # A CORBA::INV_OBJREF is raised. # omniORB: throw INV_OBJREF from omniObjRef.cc:213 # ---------- rootContext = testObj._narrow(CosNaming.NamingContext) if rootContext is None: sys.stderr.write("Failed to narrow root naming context.\n") return CORBA.Object._nil() is_a_got = rootContext._is_a("IDL:omg.org/CosNaming/NamingContext:1.0") print "is_a() returns =",is_a_got obj = testObj.resolve(my_name) # Make sure that the object is not a 'nil object reference' # (represented in Python by the value 'None'). if obj is None: raise 'Nil object reference!' # Make sure that the object implements the expected interface! # Convert the IOR to an object reference string_ior = orb.object_to_string(obj) print "string IOR using testObj is:\n",string_ior try: obj = rootContext.resolve(my_name) # Make sure that the object is not a 'nil object reference' # (represented in Python by the value 'None'). if obj is None: raise 'Nil object reference!' # Make sure that the object implements the expected interface! # Convert the IOR to an object reference string_ior = orb.object_to_string(obj) except CosNaming.NamingContext.NotFound, e: sys.stderr.write("Unable to resolve: " + `my_name` + "-- not found:" + `e` + "\n") except CosNaming.NamingContext.InvalidName, e: sys.stderr.write("Requested name:" + `my_name` + "-- is invalid:" + `e` + "\n") # return obj # ----------------------------------------------------------------------- # Initialise the ORB orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) # get the object in the NameService wfms = getObjectFromName(orb,('ams','ams')) if wfms is not None: # Print out the IOR print orb.object_to_string(wfms) else: print "Nil object reference!" --=-=-= Content-Disposition: attachment; filename=nameclt_resolve.trace Content-Description: nameclt_resolve.trace omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6 omniORB: The omniDynamic library is not linked. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:omg.org/CosNaming/NamingContext:1.0 omniORB: Initial reference `NameService' resolved from configuration file. omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> omniORB: strand Ripper: start. omniORB: scavenger : start. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: :\:NS:::IR:CosNaming_NamingContext omniORB: GIOP::LOCATION_FORWARD -- retry request. omniORB: strand Rope::incrRefCount: old value = 1 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(:\:NS:::IR:CosNaming_NamingContext) -- deleted. omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> omniORB: strand Rope_iterator: delete unused Rope. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a616d733a303a3a49523a74726f75626c655265706f72745f526571576f4d676d74496600> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:troubleReport_ReqWoMgmtIf:1.0 IOR:000000000000002249444c3a74726f75626c655265706f72745f526571576f4d676d7449663a312e30000000000000010000000000000066000100000000001874737477666d732e6e776573742e61747477732e636f6d00062200000000003e3a5c74737477666d732e6e776573742e61747477732e636f6d3a616d733a303a3a49523a74726f75626c655265706f72745f526571576f4d676d74496600 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:troubleReport_ReqWoMgmtIf:1.0) -- deleted. omniORB: Preparing to shutdown ORB. omniORB: scavenger : woken by poke() omniORB: scavenger : exit. omniORB: strand Ripper: exit. omniORB: ORB shutdown is complete. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContext:1.0) -- deleted. --=-=-= Content-Disposition: attachment; filename=get_ior.trace Content-Description: get_orbix_ior.trace omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6 omniORB: The omniDynamic library is not linked. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:omg.org/CosNaming/NamingContext:1.0 omniORB: Initial reference `NameService' resolved from configuration file. omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating Python ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:omg.org/CosNaming/NamingContext:1.0 omniORB: strand Rope::incrRefCount: old value = 2 omniORB: Creating Python ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CosNaming/NamingContext:1.0 most derived id: IDL:omg.org/CosNaming/NamingContext:1.0 omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> omniORB: strand Ripper: start. omniORB: scavenger : start. omniORB: Python thread state scavenger start. omniORB: scavenger : scanning connections omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: :\:NS:::IR:CosNaming_NamingContext omniORB: GIOP::LOCATION_FORWARD -- retry request. omniORB: strand Rope::incrRefCount: old value = 1 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 3 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(:\:NS:::IR:CosNaming_NamingContext) -- deleted. omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> omniORB: strand Rope::incrRefCount: old value = 2 omniORB: Creating Python ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a616d733a303a3a49523a74726f75626c655265706f72745f526571576f4d676d74496600> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:troubleReport_ReqWoMgmtIf:1.0 omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:CosNaming_NamingContext:1.0 omniORB: GIOP::LOCATION_FORWARD -- retry request. omniORB: strand Rope::incrRefCount: old value = 2 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 3 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 3 omniORB: ObjRef(IDL:CosNaming_NamingContext:1.0) -- deleted. omniORB: The object with the IR repository ID: IDL:omg.org/CosNaming/NamingContext:1.0 returns FALSE to the query _is_a("IDL:omg.org/CosNaming/NamingContext:1.0"). A CORBA::INV_OBJREF is raised. omniORB: throw INV_OBJREF from omniObjRef.cc:213 is_a() returns = 1 string IOR using testObj is: IOR:000000000000002249444c3a74726f75626c655265706f72745f526571576f4d676d7449663a312e30000000000000010000000000000066000100000000001874737477666d732e6e776573742e61747477732e636f6d00062200000000003e3a5c74737477666d732e6e776573742e61747477732e636f6d3a616d733a303a3a49523a74726f75626c655265706f72745f526571576f4d676d74496600 Traceback (innermost last): File "./get_orbix_ior.py", line 92, in ? wfms = getObjectFromName(orb,('ams','ams')) File "./get_orbix_ior.py", line 66, in getObjectFromName obj = rootContext.resolve(my_name) File "/opt/omniORB/lib/python/Naming_idl.py", line 209, in resolve return _omnipy.invoke(self, "resolve", _0_CosNaming.NamingContext._d_resolve, args) omniORB.CORBA.INV_OBJREF: Minor: 0, Completed: COMPLETED_NO. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(IDL:troubleReport_ReqWoMgmtIf:1.0) -- deleted. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContext:1.0) -- deleted. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContext:1.0) -- deleted. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContext:1.0) -- deleted. --=-=-= Content-Disposition: attachment; filename=nameclt_list.trace Content-Description: nameclt_list.trace omniORB: gateKeeper is tcpwrapGK 1.0 - based on tcp_wrappers_7.6 omniORB: The omniDynamic library is not linked. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: IDL:omg.org/CosNaming/NamingContext:1.0 omniORB: Initial reference `NameService' resolved from configuration file. omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> omniORB: strand Ripper: start. omniORB: scavenger : start. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: :\:NS:::IR:CosNaming_NamingContext omniORB: GIOP::LOCATION_FORWARD -- retry request. omniORB: strand Rope::incrRefCount: old value = 1 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(:\:NS:::IR:CosNaming_NamingContext) -- deleted. omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a726f6f743a3a49523a436f734e616d696e675f4e616d696e67436f6e7465787400> omniORB: strand Rope_iterator: delete unused Rope. omniORB: strand Rope::incrRefCount: old value = 0 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a383a3a49523a436f734e616d696e675f42696e64696e674974657261746f7200> target id : IDL:omg.org/CosNaming/BindingIterator:1.0 most derived id: IDL:omg.org/CosNaming/BindingIterator:1.0 omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a383a3a49523a436f734e616d696e675f42696e64696e674974657261746f7200> omniORB: strand Rope::incrRefCount: old value = 1 omniORB: Creating ref to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a383a3a49523a436f734e616d696e675f42696e64696e674974657261746f7200> target id : IDL:omg.org/CORBA/Object:1.0 most derived id: :\:NS:::IR:CosNaming_BindingIterator omniORB: GIOP::LOCATION_FORWARD -- retry request. omniORB: strand Rope::incrRefCount: old value = 2 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 3 omniORB: ObjRef(:\:NS:::IR:CosNaming_BindingIterator) -- deleted. omniORB: LocateRequest to remote: key<0x3a5c74737477666d732e6e776573742e61747477732e636f6d3a4e533a383a3a49523a436f734e616d696e675f42696e64696e674974657261746f7200> ObjectGroups/ ams.ams pwan.pwan/ srms.srms omniORB: throw MARSHAL from exception.cc:422 omniORB: tcpSocketStrand::~Strand() close socket no. 5 omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 2 omniORB: ObjRef(IDL:omg.org/CosNaming/BindingIterator:1.0) -- deleted. list: Unexpected error encountered. omniORB: Preparing to shutdown ORB. omniORB: scavenger : woken by poke() omniORB: scavenger : exit. omniORB: strand Ripper: exit. omniORB: ORB shutdown is complete. omniORB: omniRemoteIdentity deleted. omniORB: strand Rope::decrRefCount: old value = 1 omniORB: ObjRef(IDL:omg.org/CosNaming/NamingContext:1.0) -- deleted. --=-=-=-- From martin.f.geil@lmco.com Wed Jan 31 20:54:59 2001 From: martin.f.geil@lmco.com (Geil, Martin F) Date: Wed, 31 Jan 2001 12:54:59 -0800 Subject: [omniORB] porting from IONA Orbix2.3c on HP-UX Message-ID: > Hi, > > I am researching the options for porting a large software project > written in C/C++ from IONA Orbix2.3c to MICO/TAO/OmniORB/???. The goals > are to move to an opensource CORBA implementation that is complete and > interoperable with existing Orbix2.3c servers. Our development/deployment > platform is exclusively HP-UX, currently 10.20/native cfront C++ but > moving to 11i/aCC as part of this port. Our current implementation uses > BOA, and I'm not sure how hard it is to move to POA or how interoperable > we will be with old Orbix servers afterwards. Any thoughts and > suggestions would be welcome. > > > Martin Geil > Lockheed Martin Technical Operations > From timd@macquarie.com.au Wed Jan 31 22:02:41 2001 From: timd@macquarie.com.au (Timothy Docker) Date: Thu, 1 Feb 2001 09:02:41 +1100 (EST) Subject: [omniORB] marshal exceptions in omniORBpy In-Reply-To: <200101311530.PAA13245@pineapple.uk.research.att.com> References: <14966.37544.192783.868352@tcc2> <200101311530.PAA13245@pineapple.uk.research.att.com> Message-ID: <14968.35589.9039.671255@tcc2> > > Given that I know the remote operation has completed, shouldn't the > > status be COMPLETED_YES or perhaps COMPLETED_MAYBE? > > Yes, you're right. The exception should have status COMPLETED_YES. > Unfortunately, it's not a trivial thing to fix, but the next major > release of omniORBpy will get it right. Thanks. I'm not relying on it in my code, it just had me debugging code that was actually working. Tim From tvedt@noao.edu Wed Jan 31 23:33:19 2001 From: tvedt@noao.edu (Janet Tvedt) Date: Wed, 31 Jan 2001 16:33:19 -0700 (MST) Subject: [omniORB] compiling template with I::_ptr_type * Message-ID: <200101312333.QAA19839@pertelote.tuc.noao.edu> My original code which worked under Visibroker C++ for Tornado and omniORB2 used the template function: template int getObjectReference(Type **a, const char *name, CosNaming::NamingContext_var nc, int maxRetries) { ... } The call to the function looked like the following (for an interface OCS::IAttributeDB) OCS::IAttributeDB *obj; getObjectReference( &obj, ... ); I get the compilation error "parse error before `,'" with either of the following changes: getObjectReference(Type::_ptr_type a, ... getObjectReference(Type::_ptr_type *a, ... If I add typename (similar to a function Ch. 18 of Advanced CORBA Programming with C++, Henning & Vinoski) the following template compiles: template int getObjectReference(typename Type::_ptr_type a, ... but I get the compilation error no matching function for call to `getObjectReference (OCS::_objref_IAttributeDB *&, const char *, CosNaming::NamingContext_var, int) when I try to call the function like so: OCS::IAttributeDB_ptr obj; getObjectReference( obj, ... ); I am not experienced with using templates so maybe I was just lucky that what I had done previously worked. Any advice would be greatly appreciated. -------------------------------------------------------------------------- Janet Tvedt, National Solar Observatory/SOLIS Internet: tvedt@noao.edu P.O. Box 26732, Tucson, AZ 85732-6732 Phone: (520) 318-8388 950 N. Cherry Ave., Tucson, AZ 85719 FAX: (520) 318-8278 > On Monday 29 January, Janet Tvedt wrote: > > > A few months ago I posted a message (details below). However, > > I cannot get the following template function to compile: > > > > template > > int getCosNamingObjectRef(Type::_ptr_type *a, ... > > Depending on what you are trying to do, you quite probably want to be > using > > template > int getCosNamingObjectRef(Type::_ptr_type a, ... > > without the *. Other than that, precisely what error message are you > getting? > > Cheers, > > Duncan. > > -- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- > > From jack_44@usa.net Tue Jan 2 10:36:52 2001 From: jack_44@usa.net (Jack P) Date: 2 Jan 01 03:36:52 MST Subject: [omniORB] Naming service. Message-ID: <20010102103652.12905.qmail@nwcst330.netaddress.usa.net> Hi, HAPPY NEW YEAR TO U ALL. Is it possible to have two(or >2) entries in omniORB.cfg file? (The host/port combinations) The Naming service is running on two different machines(1&2). I mean if the machine1 is crashed then client(on machine3) can still get = the work done by contacting the Naming service on machine2. Should we have to specify multiple arguments to resolve_initial_references()function.If possible how thats done? Thanks Jack = ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 1 From dgrisby@uk.research.att.com Tue Jan 2 15:21:21 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Tue, 02 Jan 2001 15:21:21 +0000 Subject: [omniORB] question about possible deadlock In-Reply-To: Message from "Andy Faibishenko" of "Wed, 20 Dec 2000 16:10:19 CST." Message-ID: <200101021521.PAA02222@pineapple.uk.research.att.com> On Wednesday 20 December, "Andy Faibishenko" wrote: > I have a scenario where the client (client method C1) passes an object > reference to a server method S1. Server method S1 immediately calls back > a method (client method C2) on that object reference. Is this a valid > scenario? I am using omniorb 3.0.1 BOA on NT/Solaris. > > When the server calls back will this create a new thread on the client > side? If not, I could see why I am locking up. The callback will be serviced by a new thread, so it will not block. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From rsimkin@htc.com Wed Jan 3 01:38:38 2001 From: rsimkin@htc.com (Simkin, Rick) Date: Tue, 2 Jan 2001 19:38:38 -0600 Subject: [omniORB] Thorough documentation Message-ID: <5B6E5316047CD311B66B009027B0A75C03B4BE9B@hlch01e.htc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07525.E684AF40 Content-Type: text/plain; charset="iso-8859-1" I have just started working on a project using omniORB 3.0.2 to connect to a service written using BOA, but I can't find documentation on the BOA interface. The sample code provided with this remote service makes me aware that the omniORB documentation covers essential points, but not all of CORBA 2.3. I would greatly appreciate a quick guide (a short list, or perhaps a URL) to thorough CORBA documentation (books or on-line): how to learn about BOA and ORB classes, for example, how to determine when to delete a pointer and when to let CORBA do it. Thank you for your help! ================ I speak for myself, not my employer ================= Rick Simkin rick.simkin@htc.com +1 (312) 697-2949 Goldman Sachs/Hull Group * 311 S. Wacker #1400 * Chicago IL 60606-6623 ------_=_NextPart_001_01C07525.E684AF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thorough documentation

Thank you for your help!

Interesting point! I'll guess that it has something = to do with the
server producing some responses asynchronously, and = delivering them
via CORBA calls to objects that the client = supplies.

> If you want documentation on BOA, you'll have to = look at the documentation
> for the ORB that was used to implement the = service you are trying to
> connect to.

Then that's just what I'll have to do. Thank = you.

Klaus Sonnenleiter wrote:
> The best resource I could find was the Advanced = CORBA Programming in C++
> book written by Michi Henning and Steve Vinoski = published by Addison
> Wesley.

Thank you for this reference. I went to a bookstore = looking for CORBA
books, and saw only OMG's 3.0 reference. I'll check = other sources now.

Hi, For information about = "Advanced CORBA Programming in C++", this is the online store = : <http://store.awl.com/> or call 1-800-824-7799 (North-America = only... I supposed...!)

------_=_NextPart_001_01C0765B.E6E14B80-- From visschb@rjrt.com Thu Jan 4 14:54:00 2001 From: visschb@rjrt.com (Bruce Visscher) Date: Thu, 04 Jan 2001 09:54:00 -0500 Subject: [omniORB] Building OmniOrb3 examples on VMS References: <26D7602EA56DD21197BB0000F840029A03EA54DA@hceh71.post.ch> Message-ID: <3A548E88.A6DCCAAC@rjrt.com> Hi Jacob, erberj@post.ch wrote: > [...] > GDC006>make all > > Making ALL in [SRC.EXAMPLES.ECHO]... > %CREATE-I-EXISTS, [STUB] already exists > Compiling /OMNIROOT/IDL/ECHO.IDL... > 'import exceptions' failed; use -v for traceback > Warning! Falling back to string-based exceptions > 'import site' failed; use -v for traceback > Traceback (innermost last): > File "", line 1, in ? > I > m > p > o > r > t > E > r > r > o > r > : N > o > > m > o > d > u > l > e > > n > a > m > e > d > > o > s > ImportError: No module named os (Python's habit of writing one character at a time to the console doesn't get along with VMS mailboxes very well...) Check your PYTHONPATH symbol? What happens if you just "import os" from python? HTH, Bruce -- Bruce Visscher visschb@rjrt.com CONFIDENTIALITY NOTE: This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney-client or other legal privileges, and/or proprietary non-public information. If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please notify the sender by replying to this message and then delete it from your system. Use, dissemination, distribution, or reproduction of this message and/or any of its attachments (if any) by unintended recipients is not authorized and may be unlawful. From chris.newbold@laurelnetworks.com Thu Jan 4 15:19:12 2001 From: chris.newbold@laurelnetworks.com (Chris Newbold) Date: Thu, 04 Jan 2001 10:19:12 -0500 Subject: [omniORB] Default for omniORB::diiThrowsSysExceptions is wrong References: Message-ID: <3A549470.7000909@laurelnetworks.com> It appears that the default value for omniORB::diiThrowsSysExceptions is wrong, or at least in disagreement with the documentation. The documentation claims that from 2.8.0 the default is TRUE. The actual value seems to be FALSE, as found in omniORB.cc. -Chris Newbold Laurel Networks, Inc. From erberj@post.ch Thu Jan 4 16:09:29 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 4 Jan 2001 17:09:29 +0100 Subject: [omniORB] OmniOrb 3 and C Message-ID: <26D7602EA56DD21197BB0000F840029A03EA54DC@hceh71.post.ch> Hi, does OmniOrb3 also support simple C, if yes, what Do I have do specify as backend with the idl command? Best regards Jakob From hany@peac.com Thu Jan 4 11:56:54 2001 From: hany@peac.com (Hany Greiss) Date: Thu, 04 Jan 2001 11:56:54 +0000 Subject: [omniORB] Apache module Message-ID: <3A546506.12D211D8@peac.com> Hello, I have recently moved to omni-orb from mico. The server port was quite smooth and the performance of the server has improved, multi-threading, etc. I am having significant problems porting our Apache extension module. For some unknown reason, the call to the ORB_init function hangs. I know the right one is getting called because if I pass it anything other than omniORB3 as the last parameter it complains as it should. Has anyone tried writing an Apache module using omni-orb and if so, were similar problems seen? The configuration I am working on is Linux, RedHat 6.1, gcc 2.95. Thanks, Hany hany@portalsphere.com From dgrisby@uk.research.att.com Thu Jan 4 17:00:56 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 04 Jan 2001 17:00:56 +0000 Subject: [omniORB] fixed data type In-Reply-To: Message from Joel Schuster of "Wed, 27 Dec 2000 11:31:00 MST." <3A4A3564.F56993FA@cctus.com> Message-ID: <200101041700.RAA18251@pineapple.uk.research.att.com> On Wednesday 27 December, Joel Schuster wrote: > It seems that the Fixed data type has not yet > been implemented in the CORBA 2.3 compiant > OmniORB 3.0. Does anyone know when it will be > or if there is a development branch where it is? Fixed is not yet available. It is on the list of things to do, but we can't give a definite time-scale. Probably sooner rather than later, since it's quite simple. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 4 17:12:21 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 04 Jan 2001 17:12:21 +0000 Subject: [omniORB] OmniOrb 3 and Factory Finder Interface In-Reply-To: Message from erberj@post.ch of "Thu, 04 Jan 2001 15:18:21 +0100." <26D7602EA56DD21197BB0000F840029A03EA54D9@hceh71.post.ch> Message-ID: <200101041712.RAA18333@pineapple.uk.research.att.com> On Thursday 4 January, erberj@post.ch wrote: > does OmniOrb support this interface? What do you mean by support? The FactoryFinder is specified in IDL, so omniORB supports it in the sense that you can write client and server code which uses the interface. If you mean does omniORB provide an implementation of the interface, then no. The whole Life Cycle service is really just a design pattern. Implementations of all the interfaces are application specific. If you need something like the FactoryFinder, I strongly recommend that you write your own similar interface which is less generic. It will save you a lot of pain. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Thu Jan 4 17:15:13 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 04 Jan 2001 17:15:13 +0000 Subject: [omniORB] OmniOrb 3 and C In-Reply-To: Message from erberj@post.ch of "Thu, 04 Jan 2001 17:09:29 +0100." <26D7602EA56DD21197BB0000F840029A03EA54DC@hceh71.post.ch> Message-ID: <200101041715.RAA18370@pineapple.uk.research.att.com> On Thursday 4 January, erberj@post.ch wrote: > does OmniOrb3 also support simple C, if yes, what Do I have do specify as > backend with the idl command? No, omniORB does not support C, just C++ and Python. There is, of course, no reason why you can't interface C++ CORBA code with existing C code. If you _really_ want to use the unbelievably awkward C mapping, you should try ORBit or ILU. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From hany@peac.com Thu Jan 4 12:28:53 2001 From: hany@peac.com (Hany Greiss) Date: Thu, 04 Jan 2001 12:28:53 +0000 Subject: [omniORB] omni and Apache Message-ID: <3A546C85.52CA092B@peac.com> Hello again, Just to follow up on my previous e-mail regarding hanging on the call to ORB_init from within an Apache module. I came across a suggestion to insert tracing within the argc/argv parameters. When I did this the only output I received was, omniORB: strand Ripper: start. It appears to hang at this point. Any ideas? Thanks, Hany hany@portalsphere.com From eliot@isogen.com Thu Jan 4 15:21:41 2001 From: eliot@isogen.com (W. Eliot Kimber) Date: Thu, 04 Jan 2001 09:21:41 -0600 Subject: [omniORB] Re: A Stab at Python COM-to-CORBA Binding Generation References: <3A4D1462.5A1DD54A@isogen.com> Message-ID: <3A549505.DCA4FF14@isogen.com> "W. Eliot Kimber" wrote: > Here is the code. Enjoy. We've refined the code to the point that I think it is pretty complete. We've tested it by writing a little VB GUI against our CORBA objects. We've fixed a nasty ommission in the first version I posted, added support for "narrow", and figured out how to autogenerate all classes, including the "top level" class that makes the initial CORBA connection. Below are two packages, "gencombind.py" and "com2corba.py". gencombind.py is the omniidl back end, com2corba.py is a set of static classes and methods used by the generated classes. The code assumes the default mapping of IDL module/interface to python packages used by OmniIDL. Typical usage of the generated classes is (here using VB code): dim myServer as Object Set myServer = CreateObject("MyProject.MyServer") myServer.initializeCorbaReference ("corbaname::localhost#MyServer") If Err.Number <> 0 Then MsgBox "Creation of my server object failed: " & Err.Description Return End If dim obj2 as Object set obj2 = myServer.getSomeOtherObject() print obj2.getName() ' Prints the objects name. This would be from the IDL-defined methods. Each corba class has a built-in ClassName method and exposes the narrow() method, e.g.: dim obj3 as Object set obj3 = obj2.narrow("myproject.Module1.Interface2") if not obj3 is Nothing: print obj3.ClassName() ' should be "Interface2" It would easy to expose other CORBA-specific properties, such as the fully-qualified interface name, but I haven't done that yet just because I haven't found a need for it yet. It would also be easy to generate the inverse of this binding: Python that exposes COM objects through CORBA using OmniORB. That could be really useful for quickly corbatizing legacy COM systems at almost zero cost. gencombind.py: --- cut here --- #------------------------------------------------------------- # # COM-to-IDL Binding Generator # # Copyright (c) 2000, 2001 DataChannel, Inc. # # This software may be used for any purpose without restriction as long # as the above copyright notice is maintained. # # $Id$ #--------------------------------------------------------------- """ OmniORB back end for generating Python COM server classes that implement the IDL and delegate to the corresponding Python CORBA classes. To use this back end, use the omniidl command (provided with the OmniORB package). Go to the directory that contains the IDL you want to process and issue this command: omniidl -I. -bbonnellcorba.gencombind Bonnell.idl > outputfile.py After generating the COM binding file (outputfile.py), you must run that file to register the COM classes: python outputfile.py """ from omniidl import idlast, idlvisitor, idlutil, idltype import string import pythoncom progidMain = "myProduct" # FIXME: get this from an argument declaredClasses = [] # List of classes declared, used to generate COM registrations narrowLookups = {} # Dictionary for mapping IDL defined classname # to (stub class, wrap class) class ComVisitor (idlvisitor.AstVisitor): def visitAST(self, node): for n in node.declarations(): n.accept(self) def visitModule(self, node): print "import %s" % string.join(node.scopedName(), ".") for n in node.definitions(): n.accept(self) def visitInterface(self, node): name = node.identifier() fqName = string.join(node.scopedName(), ".") narrowLookups[fqName] = name global declaredClasses declaredClasses.append(name) guid = pythoncom.CreateGuid() desc = name # FIXME: generate a better description. progid = "%s.%s" % (progidMain, name) print """ class %s(CorbaWrapper): _reg_clsid_ = "%s" _reg_desc_ = "%s" _reg_progid_ = "%s" _public_attrs_ = [] _readonly_attrs_ = [] scopedName = "%s" corbaStubClass = %s """ % (name, guid, desc, progid, fqName, fqName) # Now generate the list of public methods spacingVar = " " * 22 publicMethodList = \ "'narrow',\n%s'ClassName',\n%s'initializeCorbaReference',\n%s" % \ (spacingVar, spacingVar, spacingVar) callables = node.callables() for callable in callables: if callable.__class__ == idlast.Operation: publicMethodList = "%s'%s',\n%s" % (publicMethodList, callable.identifier(), spacingVar) print " _public_methods_=[%s]" % publicMethodList print """ def lookupWrapClassForStubClass(self, stubClassName): return narrowLookups[stubClassName] """ for callable in callables: if callable.__class__ == idlast.Operation: generateMethodForOperation(callable) def generateMethodForOperation(operation): """ Given an operation, generates the corresponding COM-specific Python method. """ methodName = operation.identifier() comParms = "self" parms = operation.parameters() corbaParms = "" if len(parms) > 0: for param in parms: if param.is_in(): comParms = "%s, %s" % (comParms, param.identifier()) corbaParms = "%s%s," % (corbaParms, comparm2corbaparm(param)) corbaParms = corbaParms[:-1] # Slice off trailing "," print "\n def %s(%s):" % (methodName, comParms) returnType = operation.returnType() returnKind = returnType.kind() if returnKind == idltype.tk_alias: returnType = operation.returnType().unalias() returnKind = returnType.kind() # print "### returnKind=%s" % returnKind if returnKind == idltype.tk_void: print " self.corbaObject.%s(%s)" % (methodName, corbaParms) elif returnKind == idltype.tk_objref: print " return wrap(%s(self.corbaObject.%s(%s)))" % \ (returnType.name(), methodName, corbaParms) elif returnKind == idltype.tk_sequence: seqType = returnType.seqType() print " objs = self.corbaObject.%s(%s)" % (methodName, corbaParms) print " comObjs = []" if seqType.kind() == idltype.tk_objref: print " for obj in objs:" print " comObjs.append(wrap(%s(obj)))" % \ seqType.name() elif seqType.kind() == idltype.tk_string: print " for string in objs:" print " comObjs.append(str(string))" else: print " comObjs = objs" print " return wrap(Collection(data = comObjs))" else: print " return self.corbaObject.%s(%s)" % (methodName, corbaParms) def comparm2corbaparm(corbaParm): """ Given a corba parameter, returns the appropriate Python parameter. """ result = "" type = corbaParm.paramType() if type.kind() == idltype.tk_string: result = "str(%s)" % corbaParm.identifier() elif type.kind() == idltype.tk_objref: result = "unwrap(%s).corbaObject" % corbaParm.identifier() else: result = corbaParm.identifier() return result def run(tree, args): visitor = ComVisitor() print "#----------------------------------------------------------" print "# Generated by gencombind.py " print "#----------------------------------------------------------" print """ import sys from win32com.server.util import wrap, Collection # NOTE: we override unwrap below from win32com.server.exception import COMException from win32com.server import util from com2corba import * import traceback import CosNaming from omniORB import CORBA """ tree.accept(visitor) print "\nnarrowLookups = {" for (key, wrapClass) in narrowLookups.items(): print " '%s': %s," % (key, wrapClass) print "}" print "\nif __name__ == '__main__':" print " import win32com.server.register" for name in declaredClasses: print " win32com.server.register.UseCommandLine(%s)" % name #---- end of package com2corba.py: --- cut here --- #---------------------------------------------------------------- # # com2corba support methods and classes (package) # # Copyright (c) 2000, 2001 DataChannel, Inc. # # This software may be used for any purpose without restriction as long as the above # copyright notice is maintained. # # $Id: com2corba.py,v 1.1 2001/01/03 20:15:45 eliot Exp $ ## #---------------------------------------------------------------- from win32com.server.util import wrap, Collection # NOTE: we override unwrap below from win32com.server.exception import COMException from win32com.server import util from omniORB import CORBA import sys, string class InitializeCorbaReferenceError(COMException): pass class CorbaWrapper: def __init__(self, corbaObject = None): self.corbaObject = corbaObject def initializeCorbaReference(self, corbaloc): """ Given a corba location, gets a CORBA object reference to it if it doesn't already have one. """ corbaloc = str(corbaloc) if not self.corbaObject: orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID) try: self.corbaObject = orb.string_to_object(corbaloc) except Exception, exc: raise InitializeCorbaReferenceError("Failed to get CORBA" "object reference for location %s: %s" %\ (corbaloc, exc)) self.corbaObject = self.corbaObject._narrow(self.corbaStubClass) def ClassName(self): return self.__class__.__name__ def narrow(self, stubClassName): """ Implements the CORBA narrow method. stubClassName is the class name generated in the Python stubs from the IDL, i.e., 'module.module.interface' """ try: wrapClass = self.lookupWrapClassForStubClass(str(stubClassName)) cObj = self.corbaObject._narrow(wrapClass.corbaStubClass) if cObj: return wrap(wrapClass(cObj)) else: return None except KeyError: return None def lookupWrapClassForStubClass(self, stubClassName): """ Given the name of a python stub class (e.g., full-qualified name from IDL), return the corresponding COM wrapping class. Raises KeyError if stubClassName not found. """ raise Exception("This is an abstract method. " "Must be implemented by subclasses") def unwrap(comObj): "Handle Nothing objects passed in from COM" if comObj == None: return NullCorbaObj() else: pyObj = util.unwrap(comObj) return pyObj class NullCorbaObj: "Provides a None object that has a corbaObject property" def __init__(self): self.corbaObject = None #---- end of package -- . . . . . . . . . . . . . . . . . . . . . . . . W. Eliot Kimber | Lead Brain 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.656.4139 | F 512.419.1860 | eliot@isogen.com w w w . d a t a c h a n n e l . c o m From trohed@yahoo.com Thu Jan 4 20:03:34 2001 From: trohed@yahoo.com (trohed) Date: Thu, 4 Jan 2001 12:03:34 -0800 (PST) Subject: [omniORB] omniORB3 on Compaq Tru64 UNIX V5.0A Message-ID: <20010104200334.22053.qmail@web10302.mail.yahoo.com> Has anyone ever used omniORB3 on Tru64 V5.0A? Thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From boris@imagine-sw.com Thu Jan 4 22:34:00 2001 From: boris@imagine-sw.com (Boris Khanales) Date: Thu, 4 Jan 2001 17:34:00 -0500 (EST) Subject: [omniORB] JDK Orb Message-ID: <200101042234.RAA07991@desmond.imagine_ny.com> Sorry for unrelated question, but anybody knows anything about time-out support for CORBA calls in SUN's JDK or maybe other Java ORBs? By the way, there was something for omni to set time-out, can somebody point me where was it? Thank You. From tran15@rohan.sdsu.edu Fri Jan 5 02:03:02 2001 From: tran15@rohan.sdsu.edu (Malcom X.) Date: Thu, 4 Jan 2001 18:03:02 -0800 (PST) Subject: [omniORB] OmniORB CFG Message-ID: Hi, does anyone have a sample OmniORB.CFG file I can look at or have any idea of what should be in this CFG file? What directory should this CFG file resides? Any special environment setting for naming service. I'm running Win2000 and OmniORB 3.0. I'm totally new to OmniORB naming service and had trouble getting eg3_impl and eg3_clt to talk. Thanks in advance. From nansan@etang.com Fri Jan 5 09:10:39 2001 From: nansan@etang.com (nansan) Date: Fri, 5 Jan 2001 17:10:39 +0800 (CST) Subject: [omniORB] need a help Message-ID: <3A558F8F.24402@mail-smtp2> I have downloaded omniORB_302.tar.gz. My computer is linux redhat7.0 with gcc-2.96,python-1.5.2,and egcs 6.2-1.1.2. I have changed "platform=i586_linux_2.0_glibc2.1_gcc2.96"in config/mk.dir and "python=/usr/bin/python" in mk/platform/i586_linux_2.0_glibc2.1_gcc2.96.mk. then i make the file successfully. The problem is that the examples can not run properly.It is always saying "cat ch corba::systemexeption". Can you tell me why and how to make it run? Thanks for any help. ----------------------------------------- 100Ԫ��ã� http://ecard.etang.com/progt/index.asp?s1=1&s2=1 From davidh@cavendish.co.uk Fri Jan 5 11:28:11 2001 From: davidh@cavendish.co.uk (David Hyde) Date: Fri, 5 Jan 2001 11:28:11 -0000 Subject: [omniORB] OmniORB In A Loop Message-ID: <31C9EC5EF9CAD111981300805F06666028B20D@phantom.cavendish.co.uk> Occassional I am getting into the situation that my when my client makes a call into a server it hangs. I've found that that it is looping around in a call to tcpSocketStrand::ll_recv(void* buf, size_t sz) in tcpSocketMTfactory.cc and the call that it makes to rx = select(pd_socket+1,&fds,0,&efds,&t) takes about 5 seconds. I've a feeling that this might be happening as a result of a fault in the server, but I don't know what. I can make seperate connections to the server whilst this is happening, so I know that it is generally ok. Does anyone have any pointers? Thanks David Hyde From steffann@nederland.net Fri Jan 5 12:48:50 2001 From: steffann@nederland.net (Sander Steffann) Date: Fri, 5 Jan 2001 13:48:50 +0100 Subject: [omniORB] Calling syslog from programs linking to libomniORB3.so (on Linux) Message-ID: <003c01c07715$da2af200$7101a8c0@OFFICE> Hello, I am trying to use syslog from a program that links to libomniORB3.so, but as soon as I link a program with omniORB, the calls to syslog don't work anymore, and the messages are displayed on stdout or stderr (I don't know for sure which one) instead of going to syslog. I tried this with a small program that only calls syslog() and then exits. When not linked with omniORB3, it works as expected, but when linked with omniORB3 it doesn't. Anybody any idea what can cause this (and how to solve it)? Sander. From vonWedel@lfpt.rwth-aachen.de Fri Jan 5 14:27:17 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Fri, 5 Jan 2001 15:27:17 +0100 Subject: [omniORB] Compiling omniORB with Python 2.0 Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 00509971C12569CB_= Content-Type: text/plain; charset="us-ascii" Hello, we have upgraded from Python 1.5.2 to Python 2.0 and now I want to upgrade omniORB as well. I checked out the sources from the development branches for omniORB and omniORBpy this morning. Compiling starts with the following warnings which look somewhat strange to me: ../../../../bin/sun4_sosV_5.7/omkdepend -D__SUNPRO_CC -D__cplusplus -DOMNIPY_MAJOR=0 -DOMNIPY_MINOR=5 -DOMNIORB_VERSION_STRING="3.0.2" -DOMNIORBPY_FOR_30 -I../../../../src/lib/omniORB2 -I../../../../src/lib/omniORB2/orbcore -I/usr/local/include -DPYTHON_INCLUDE= -DPYTHON_THREAD_INC= -I. -I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 common/pyomniFunc.cc common/pyThreadCache.cc common/pyTypeCode.cc common/pyMarshal.cc common/pyExceptions.cc omni30/pyServant.cc omni30/pyCallDescriptor.cc omni30/pyObjectRef.cc omni30/pyPOAManagerFunc.cc omni30/pyPOAFunc.cc omni30/pyORBFunc.cc omni30/omnipy.cc ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/Python.h: 44: # error "Python.h requires that stdio.h define NULL." ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/pyport.h: 390: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)." ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyMarshal.cc) common/pyMarshal.cc: 255: # error "omniidl requires Python 1.5.2 or higher" making export in src/lib/omniORBpy/modules/omni30... Are these actually omniORB problems? They look like a Python-related problem, to some extent... Anyone seen this before? Lars --=_alternative 00509971C12569CB_= Content-Type: text/html; charset="us-ascii"
Hello,

we have upgraded from Python 1.5.2 to Python 2.0 and now I want to upgrade omniORB as well.
I checked out the sources from the development branches for omniORB and omniORBpy this morning.
Compiling starts with the following warnings which look somewhat strange to me:

../../../../bin/sun4_sosV_5.7/omkdepend -D__SUNPRO_CC -D__cplusplus -DOMNIPY_MAJOR=0 -DOMNIPY_MINOR=5 -DOMNIORB_VERSION_STRING="3.0.2" -DOMNIORBPY_FOR_30 -I../../../../src/lib/omniORB2 -I../../../../src/lib/omniORB2/orbcore -I/usr/local/include -DPYTHON_INCLUDE=<python2.0/Python.h> -DPYTHON_THREAD_INC=<python2.0/pythread.h> -I. -I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 common/pyomniFunc.cc common/pyThreadCache.cc common/pyTypeCode.cc common/pyMarshal.cc common/pyExceptions.cc omni30/pyServant.cc omni30/pyCallDescriptor.cc omni30/pyObjectRef.cc omni30/pyPOAManagerFunc.cc omni30/pyPOAFunc.cc omni30/pyORBFunc.cc omni30/omnipy.cc
../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/Python.h: 44: # error "Python.h requires that stdio.h define NULL."
../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyomniFunc.cc) /usr/local/include/python2.0/pyport.h: 390: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from common/pyMarshal.cc) common/pyMarshal.cc: 255: # error "omniidl requires Python 1.5.2 or higher"
making export in src/lib/omniORBpy/modules/omni30...

Are these actually omniORB problems? They look like a Python-related problem, to some extent...
Anyone seen this before?

Lars
--=_alternative 00509971C12569CB_=-- From harri.pasanen@trema.com Fri Jan 5 14:38:42 2001 From: harri.pasanen@trema.com (Harri Pasanen) Date: Fri, 05 Jan 2001 15:38:42 +0100 Subject: [omniORB] Compiling omniORB with Python 2.0 References: Message-ID: <3A55DC72.7BD58FB8@trema.com> Those are just omkdepend warnings, you can ignore those. -Harri vonWedel@lfpt.rwth-aachen.de wrote: > > Hello, > > we have upgraded from Python 1.5.2 to Python 2.0 and now I want to > upgrade omniORB as well. > I checked out the sources from the development branches for omniORB > and omniORBpy this morning. > Compiling starts with the following warnings which look somewhat > strange to me: > > ../../../../bin/sun4_sosV_5.7/omkdepend -D__SUNPRO_CC -D__cplusplus > -DOMNIPY_MAJOR=0 -DOMNIPY_MINOR=5 -DOMNIORB_VERSION_STRING="3.0.2" > -DOMNIORBPY_FOR_30 -I../../../../src/lib/omniORB2 > -I../../../../src/lib/omniORB2/orbcore -I/usr/local/include > -DPYTHON_INCLUDE= > -DPYTHON_THREAD_INC= -I. -I../../../../include > -D__sparc__ -D__sunos__ -D__OSVERSION__=5 common/pyomniFunc.cc > common/pyThreadCache.cc common/pyTypeCode.cc common/pyMarshal.cc > common/pyExceptions.cc omni30/pyServant.cc omni30/pyCallDescriptor.cc > omni30/pyObjectRef.cc omni30/pyPOAManagerFunc.cc omni30/pyPOAFunc.cc > omni30/pyORBFunc.cc omni30/omnipy.cc > ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from > common/pyomniFunc.cc) /usr/local/include/python2.0/Python.h: 44: # > error "Python.h requires that stdio.h define NULL." > ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from > common/pyomniFunc.cc) /usr/local/include/python2.0/pyport.h: 390: > #error "LONG_BIT definition appears wrong for platform (bad gcc > config?)." > ../../../../bin/sun4_sosV_5.7/omkdepend: warning: (from > common/pyMarshal.cc) common/pyMarshal.cc: 255: # error "omniidl > requires Python 1.5.2 or higher" > making export in src/lib/omniORBpy/modules/omni30... > > Are these actually omniORB problems? They look like a Python-related > problem, to some extent... > Anyone seen this before? > > Lars From davidh@cavendish.co.uk Fri Jan 5 14:46:10 2001 From: davidh@cavendish.co.uk (David Hyde) Date: Fri, 5 Jan 2001 14:46:10 -0000 Subject: [omniORB] Object::_nil() Message-ID: <31C9EC5EF9CAD111981300805F06666028B20F@phantom.cavendish.co.uk> I am using OmniORB on winnt to build a COM control. From what I have read (Henning and Vinoski) calling _nil() on an object is guaranteed not to leak any resources even if CORBA::release() is not called using the returned reference. I am calling CORBA::release() on it, but Visual C++ is still reporting a memory leak when the application shuts down. Does anyone know why? Thanks David Hyde From jonas.reimers@se.adtranz.com Fri Jan 5 15:02:13 2001 From: jonas.reimers@se.adtranz.com (Jonas Reimers) Date: Fri, 5 Jan 2001 16:02:13 +0100 Subject: [omniORB] Error compiling with Omniidl Message-ID: <412569CB.00529CF7.00@demalng2.goc.adtranz.com> - OS: WIN NT 4.0 SP6 When running omniidl -bcxx test.idl I receive following error. omniidl: ERROR! omniidl: Could not open Python files for IDL compiler omniidl: Please put them in directory M:\CORBA\omniORB\src\tool\omniidl\cxx omniidl: (or set the PYTHONPATH environment variable) Traceback (innermost last): File "", line 26, in ? NameError: msg Running the PATH comman gives the following: PATH=c:\dmi\win32\bin;C:\WINNT\system32;C:\WINNT;C:\Program Files\Visio;C:\Progr am Files\Microsoft Office\Office;C:\Acrobat3\Reader;C:\Program Files\Adobe\Acrob at 4.0\Reader;C:\ccm45\bin;;C:\MSSQL\BINN;C:\Program Files\IONA\bin;C:\Program F iles\IONA\bin;C:\Program Files\IONA\bin;c:\program files\devstudio\sharedide\bin \ide;c:\program files\devstudio\sharedide\bin;c:\program files\devstudio\vc\bin; M:\CORBA\omniORB\bin\x86_win32;M:\Corba\omniORB\gnuwin\bin; I have searched in your database and found a similar error but In the answer it is said that it is a bug that is take care off? I typed the solution suggested in the answer and sets the libpath to: M:\CORBA\omniORB\lib\x86_win32\ but still gets the error message. Anny ideas? Your sincearly Jonas Reimers From trohed@yahoo.com Fri Jan 5 22:25:35 2001 From: trohed@yahoo.com (trohed) Date: Fri, 5 Jan 2001 14:25:35 -0800 (PST) Subject: [omniORB] example factory Message-ID: <20010105222535.27396.qmail@web10303.mail.yahoo.com> Does anyone have an example of a factory that I could look at? Thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From tran15@rohan.sdsu.edu Sat Jan 6 01:27:16 2001 From: tran15@rohan.sdsu.edu (Malcom X.) Date: Fri, 5 Jan 2001 17:27:16 -0800 (PST) Subject: [omniORB] How does omniNames find omniORB.cfg Message-ID: Hi, does anyone now how to setup the environment so that omniNames will read the omniORB.cfg when it starts. I'm running Win2000 and I tried the following: - set the PATH to the dir containing omniORB.cfg which is in c:\omni\etc - omniORB.cfg contains -ORBInitialHost localhost -ORBInitialPort 2809 - successfully started omniNames - tried to start eg3_impl from the command line c:\...\echo\eg3_impl but get an exception of SystemException When I started omniNames, then started eg3_impl with arguments: c:\...\echo\eg3_impl -ORBInitialHost localhost -ORBInitialPort 2809 everything worked fine. This showed that omniNames does not read omniORB.cfg. Any help is appreciated. Thanks From djr@uk.research.att.com Sat Jan 6 15:44:31 2001 From: djr@uk.research.att.com (David Riddoch) Date: Sat, 6 Jan 2001 15:44:31 +0000 (GMT) Subject: [omniORB] Object::_nil() In-Reply-To: <31C9EC5EF9CAD111981300805F06666028B20F@phantom.cavendish.co.uk> Message-ID: Hi, It is actually impossible to implement nil object references in a way that does not leak any memory at all. omniORB does technically 'leak memory' in this case, in the sense that it allocates an object that it never deletes. However this is a singleton -- it does not leak more and more memory as time goes on. The reason for this is that we have to guarentee that the nil object reference will be around at least as long as any _var instances that reference it. The _var objects might be static objects, in which case we can make no assumptions about when they will be destroyed. Thus the nil singleton has to be dynamically allocated, and we cannot ever delete it. Cheers, David On Fri, 5 Jan 2001, David Hyde wrote: > I am using OmniORB on winnt to build a COM control. From what I have read > (Henning and Vinoski) calling _nil() on an object is guaranteed not to leak > any resources even if CORBA::release() is not called using the returned > reference. I am calling CORBA::release() on it, but Visual C++ is still > reporting a memory leak when the application shuts down. > > Does anyone know why? From rocky1_2@rediffmail.com Fri Jan 5 17:54:50 2001 From: rocky1_2@rediffmail.com (Rocky) Date: Fri, 5 Jan 2001 23:24:50 +0530 Subject: [omniORB] Error compiling with Omniidl References: <412569CB.00529CF7.00@demalng2.goc.adtranz.com> Message-ID: <002d01c07740$9a6fbbc0$aa51c7cb@k.nayar> hi, think u missed a point in the readme.first file might be useful.. i am using the same system as u are and the following has worked for me: omniidl requires Python 1.5.2. You can download the full Python distribution from http://www.python.org/download/download_windows.html or ftp://ftp.uk.research.att.com/pub/omniORB/python/py152.exe Alternatively, for Windows on x86, you can install a minimal version of Python which contains just the functionality required by omniidl. The Win32 binary distribution of omniORB comes with this minimal python package. Download it from ftp://ftp.uk.research.att.com/pub/omniORB/python/omnipython-x86_win32.zip Unpack the zip file at the top of the omniORB tree. It places files in the bin, lib and include directories. ----- Original Message ----- From: Jonas Reimers To: Sent: Friday, January 05, 2001 8:32 PM Subject: [omniORB] Error compiling with Omniidl > - > OS: WIN NT 4.0 SP6 > > When running omniidl -bcxx test.idl I receive following error. > > omniidl: ERROR! > > omniidl: Could not open Python files for IDL compiler > omniidl: Please put them in directory M:\CORBA\omniORB\src\tool\omniidl\cxx > omniidl: (or set the PYTHONPATH environment variable) > > Traceback (innermost last): > File "", line 26, in ? > NameError: msg > > > Running the PATH comman gives the following: > > PATH=c:\dmi\win32\bin;C:\WINNT\system32;C:\WINNT;C:\Program Files\Visio;C:\Progr > am Files\Microsoft Office\Office;C:\Acrobat3\Reader;C:\Program Files\Adobe\Acrob > at 4.0\Reader;C:\ccm45\bin;;C:\MSSQL\BINN;C:\Program Files\IONA\bin;C:\Program F > iles\IONA\bin;C:\Program Files\IONA\bin;c:\program files\devstudio\sharedide\bin > \ide;c:\program files\devstudio\sharedide\bin;c:\program files\devstudio\vc\bin; > M:\CORBA\omniORB\bin\x86_win32;M:\Corba\omniORB\gnuwin\bin; > > > I have searched in your database and found a similar error but In the answer it > is said that it is a bug that is take care off? > I typed the solution suggested in the answer and sets the libpath to: > > M:\CORBA\omniORB\lib\x86_win32\ > > but still gets the error message. > > Anny ideas? > > > Your sincearly > Jonas Reimers > > > > From rocky1_2@rediffmail.com Fri Jan 5 17:47:11 2001 From: rocky1_2@rediffmail.com (Rocky) Date: Fri, 5 Jan 2001 23:17:11 +0530 Subject: [omniORB] OmniORB CFG References: Message-ID: <002201c0773f$886a80a0$aa51c7cb@k.nayar> hi, you don't really need to use an omniorb.cfg file for configuring the naming service. You can make the appropriate settings in the windows registry according to the instructions in the readme.first file. It would also be better if you could spell out the exact nature of the problem you are facing in running the examples.. ----- Original Message ----- From: Malcom X. To: Sent: Friday, January 05, 2001 7:33 AM Subject: [omniORB] OmniORB CFG > Hi, does anyone have a sample OmniORB.CFG file I can look at or have any > idea of what should be in this CFG file? > > What directory should this CFG file resides? Any special environment > setting for naming service. I'm running Win2000 and OmniORB 3.0. > > I'm totally > new to OmniORB naming service and had trouble getting eg3_impl and eg3_clt > to talk. > > Thanks in advance. > > > From chalky@null.net Sun Jan 7 02:18:20 2001 From: chalky@null.net (Stephen Davies) Date: Sun, 7 Jan 2001 13:18:20 +1100 (EST) Subject: [omniORB] Synopsis 0.2 Released Message-ID: Synopsis is a source code documentation tool that follows a modular architecture to adapt to different languages, comment styles and output formats. Currently it supports IDL and C++ languages and HTML output. It has the ability to scale to large projects, integrating well with Makefiles to only update documentation for changed files. One of the goals of Synopsis is to integrate the documentation between different languages, for example linking implementations in any language with their CORBA interfaces and vice versa. It is written in Python except for the C++ parser, which is a module written in C++ based on OpenC++. The IDL parser uses the omniidl tool from omniORB which is also written in Python. Support for a Python parser is planned for the next release. Changes: Release 0.2 adds C++ support and a rewritten HTML formatter. It is complete enough to be in use by the Berlin Project. Homepage: http://synopsis.sourceforge.net/ Download: http://sourceforge.net/projects/synopsis/ From gnana@mips.biochem.mpg.de Mon Jan 8 10:45:30 2001 From: gnana@mips.biochem.mpg.de (Gnana) Date: Mon, 8 Jan 2001 11:45:30 +0100 Subject: [omniORB] Synopsis 0.2 Released In-Reply-To: ; from chalky@null.net on Sun, Jan 07, 2001 at 01:18:20PM +1100 References: Message-ID: <20010108114530.A29231@mips.biochem.mpg.de> Hello, I used Synopsis 0.2 for my CORBA IDL documentation and I was impressed. I would like to know if there is a possibility of parsing an IDL file and writing out a interface and operation diagram (in UML?) so that it is easy to visualise at the whole IDL file. I use Dia to do this right now (manually though!). I am looking for opensource tool and not tools from Rational or Togethersoft. -gnana Quoting Stephen Davies : > > Synopsis is a source code documentation tool that follows a modular > architecture to adapt to different languages, comment styles and output > formats. Currently it supports IDL and C++ languages and HTML output. It > has the ability to scale to large projects, integrating well with > Makefiles to only update documentation for changed files. One of the goals > of Synopsis is to integrate the documentation between different languages, > for example linking implementations in any language with their CORBA > interfaces and vice versa. > > It is written in Python except for the C++ parser, which is a module > written in C++ based on OpenC++. The IDL parser uses the omniidl tool from > omniORB which is also written in Python. Support for a Python parser is > planned for the next release. > > Changes: > Release 0.2 adds C++ support and a rewritten HTML formatter. It is > complete enough to be in use by the Berlin Project. > > Homepage: > http://synopsis.sourceforge.net/ > > Download: > http://sourceforge.net/projects/synopsis/ > > > > > From gnana@mips.biochem.mpg.de Mon Jan 8 11:16:55 2001 From: gnana@mips.biochem.mpg.de (Gnana) Date: Mon, 8 Jan 2001 12:16:55 +0100 Subject: [omniORB] Synopsis 0.2 Released In-Reply-To: ; from chalky@null.net on Mon, Jan 08, 2001 at 10:11:52PM +1100 References: <20010108114530.A29231@mips.biochem.mpg.de> Message-ID: <20010108121655.B31166@mips.biochem.mpg.de> Hi Chalky, Quoting Stephen Davies : > > However, if you want this done then I can have a look into it. Dia's file > format is XML which is easy to generate. The only problem would be > positioning the diagram elements. An easy solution would be to leave this > to the user to open up Dia and rearrange anything, or it's possible that > interfaces and operations as needed. As a feature add, you could implement the 'easy' solution and later on as time permits, you can do the positioning of the Dia objects and also generate code for interface and operation from the Dia diagram. I saw a tool that can take a Dia XML file and output code, but I guess that tool was generating C++ code from the Dia UML diagram (data in XML). I don't know how many people out there need this feature. Definetely, I think this feature is a very good one to spend time on. I understand a lot of thinking has to go in especially in the positioning of the objects in Dia. Your tool came just in time when I was searching for a tool that can document our huge CORBA IDL files. Thanks. -gnana From kissa@iqsoft.hu Mon Jan 8 13:47:38 2001 From: kissa@iqsoft.hu (=?iso-8859-2?Q?Kiss_=C1rp=E1d?=) Date: Mon, 8 Jan 2001 14:47:38 +0100 Subject: [omniORB] Re: A Stab at Python COM-to-CORBA Binding Generatio n Message-ID: <4A93A58449F5D311ADF500508B8B74568B6987@exchange.iqsoft.hu> Hi, I have a little bit different solution for COM-to-Corba bindig. I wrote a simple COM class that wraps Corba interfaces dynamically. I don't use it in real applications, I just want to test it is possible this way or not... Recently I have made some modification on the source, so it works with Python 2.0 too. You can download it from here: http://starship.python.net/crew/arpadk/downloads/COMToCorba0.6.0.zip Cheers, Arpad Kiss From chalky@null.net Mon Jan 8 11:11:52 2001 From: chalky@null.net (Stephen Davies) Date: Mon, 8 Jan 2001 22:11:52 +1100 (EST) Subject: [omniORB] Synopsis 0.2 Released In-Reply-To: <20010108114530.A29231@mips.biochem.mpg.de> Message-ID: Hi Gnana, Synopsis' modular architecture will certainly allow a 'Formatter' that outputs some kind of UML diagram instead of web pages. In fact, we were sort of planning to do this in the future, but I don't think there are any immediate plans. However, if you want this done then I can have a look into it. Dia's file format is XML which is easy to generate. The only problem would be positioning the diagram elements. An easy solution would be to leave this to the user to open up Dia and rearrange anything, or it's possible that the formatter could parse an existing dia file and just update the interfaces and operations as needed. Tell me what you think. Chalky //--------=[ Chalky (Stephen Davies) -- Chalky@null.net ]=--------\\ //-------=[ Powered by Linux -- "Escape the Gates of Hell" ]=-------\\ //--=[ Programmer(C/C++/Java) and 4th Year CSE/CS Student at RMIT ]=--\\ From uche.ogbuji@fourthought.com Mon Jan 8 14:52:55 2001 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 08 Jan 2001 07:52:55 -0700 Subject: [omniORB] A Stab at Python COM-to-CORBA Binding Generation In-Reply-To: Message from "W. Eliot Kimber" of "Fri, 29 Dec 2000 16:46:58 CST." <3A4D1462.5A1DD54A@isogen.com> Message-ID: <200101081452.HAA10235@localhost.localdomain> > Having tried to find a free (or even evaluatable) CORBA-to-COM bridge > and failed, I did some experimentation and realized that writing a COM > wrapper in Python for CORBA objects was pretty easy with OmniORB and > omniidl (scarily easy, actually). The only complication I've found so > far is that our "top-level" class cannot be auto-generated, as it is the > one class that establishes the initial CORBA connection (or at least, I > haven't thought about the problem long enough to figure out how to > generate this class). This is an amazing co-oincidence, I think. I just happened to be working on an XPCOM (Mozilla's COM variation) to CORBA bridge, primarily as a way to bootstrap Mozilla as a console for 4Suite Server. I was using some Python for manipulating the IDLs and all that, but not as a wrapper because XPCOM right now only seems to connect to Javascript or C++ (please someone correct me if I'm wrong). Anyway, even more important than that I ran into this Mozilla bug. http://bugzilla.mozilla.org/show_bug.cgi?id=62196 Which makes it quite difficult to test what I've worked on so far, or to get any further. Or maybe I'm missing something: I've done a lot of work with CORBA but I'm a COM newbie and also a newbie to the Mozilla code-base. If anyone is interested in my work, i.e. if you're interested in developing a console for your CORBA servers using basic Mozilla JavaScript, please help me out by voting for this bug on Mozilla.org. The XPCOM/CORBA bridge will be open source (Apache license) when I get it working. I'll have a look at Eliot's code for possible sharing of ideas, even though he's tackling a somewhat different area with Windows COM (you lucky dog, you get Python/COM out of the box). Thanks all. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From cmeerw@web.de Mon Jan 8 15:27:19 2001 From: cmeerw@web.de (Christof Meerwald) Date: Mon, 8 Jan 2001 16:27:19 +0100 Subject: [omniORB] A Stab at Python COM-to-CORBA Binding Generation In-Reply-To: <200101081452.HAA10235@localhost.localdomain> References: <200101081452.HAA10235@localhost.localdomain> Message-ID: <20010108162719.A809@hacking.meerwald.priv.at> On Mon, 08 Jan 2001 07:52:55 -0700, uche.ogbuji@fourthought.com wrote: >bootstrap Mozilla as a console for 4Suite Server. I was using some Python for >manipulating the IDLs and all that, but not as a wrapper because XPCOM right >now only seems to connect to Javascript or C++ (please someone correct me if >I'm wrong). Take a look at the Blackwood project (http://www.mozilla.org/projects/blackwood) for a Java-XPCOM bridge. And the Komodo beta (http://www.activestate.com) includes a Python-XPCOM bridge (at least on Windows NT, haven't tried the Linux version yet) bye, Christof -- http://cmeerw.cjb.net http://cmeerw.cjb.net/wap/ mailto cmeerw at web.de AIM, Yahoo! Messenger: cmeerw From yan_gao@hp.com Tue Jan 9 06:36:14 2001 From: yan_gao@hp.com (GAO,YAN (HP-Singapore,ex3)) Date: Tue, 9 Jan 2001 14:36:14 +0800 Subject: [omniORB] POA over BOA Message-ID: <912404552D6CD411B57700D0B77532260173DD10@xsg03.sgp.hp.com> Hi, Anybody can tell me a little specifically of the advantage the POA over BOA? Regards, Gao Yan From prapier@coactive.com Tue Jan 9 19:14:06 2001 From: prapier@coactive.com (Peter Rapier) Date: Tue, 9 Jan 2001 11:14:06 -0800 Subject: [omniORB] POA/BOA IOR compatibility Message-ID: <7118259C3044D311942700508B2CA5BB4F256D@balance.coactive.com> We are hearing that clients created with POA based ORB's are having problems understanding a persistent IOR we create on our omniORB 2.6 - based server. It is my understanding that clients should be able to talk to our BOA based orb regardless of their ORB's object adapter and that IOR's have a specified format. Why would there be a problem with one ORB parsing or otherwise understanding anothers ORB's IOR? Any info that can be shared with me on this topic would be greatly appreciated. - Peter Rapier From chris.newbold@laurelnetworks.com Tue Jan 9 23:46:42 2001 From: chris.newbold@laurelnetworks.com (Chris Newbold) Date: Tue, 09 Jan 2001 18:46:42 -0500 Subject: [omniORB] Default for omniORB::diiThrowsSysExceptions is wrong References: <3A549470.7000909@laurelnetworks.com> Message-ID: <3A5BA2E2.1030403@laurelnetworks.com> It appears that the default value for omniORB::diiThrowsSysExceptions is wrong, or at least in disagreement with the documentation in the 3.0.2 release. The documentation claims that, starting with 2.8.0, the default is TRUE. The actual value seems to be FALSE, as found in the static initialization in omniORB.cc -Chris Newbold Laurel Networks, Inc. From john@drystone.co.uk Wed Jan 10 11:25:42 2001 From: john@drystone.co.uk (John Hedges) Date: Wed, 10 Jan 2001 11:25:42 -0000 Subject: [omniORB] omni and Apache Message-ID: <01C07AF8.120D1820.john@drystone.co.uk> Hi Hany I believe there are problems with Apache and pthreads. Try a single threaded orb for your module (mico definately works and orbit looks like it ought to). Cheers John On Thursday, January 04, 2001 12:29 PM, Hany Greiss [SMTP:hany@peac.com] wrote: > > > Hello again, > > Just to follow up on my previous e-mail regarding hanging on the call > to ORB_init from within an Apache module. I came across a suggestion to > insert tracing within the argc/argv parameters. When I did this the only > > output I received was, > > omniORB: strand Ripper: start. > > It appears to hang at this point. Any ideas? > > Thanks, > > Hany > hany@portalsphere.com > > > From S.Lo@uk.research.att.com Wed Jan 10 11:53:49 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 10 Jan 2001 11:53:49 +0000 Subject: [omniORB] omni and Apache In-Reply-To: <01C07AF8.120D1820.john@drystone.co.uk> References: <01C07AF8.120D1820.john@drystone.co.uk> Message-ID: <3ozogzk4he.fsf@neem.uk.research.att.com> It looks like my reply to Hany has not been CC to the list. So here it goes again: In one of our projects we have an apache module written to use omniORB. The important point is when to call ORB_init. In our apache module, the module dispatch structure looks like this: static int initialised = 0; // Spirit request content handler. static int spirit_handler(request_rec *r) { .... if (!initialised) { initialised = 1; int argc = 0; char** argv = NULL; CORBA::ORB_init(argc,argv,"omniORB3"); } .... } // Here is the list of content handlers for the module. static const handler_rec spirit_handlers[] = { {"spirit-handler", spirit_handler}, {NULL} }; // We have no command directives for this module. static const command_rec spirit_cmds[] = { {NULL} }; // And here is the list of callback routines. module spirit_module = { STANDARD_MODULE_STUFF, NULL, // Initializer. NULL, // Per-directory config. NULL, // Directory config merger. NULL, // Server config. NULL, // Server config merger. spirit_cmds, // Command table. spirit_handlers, // Handler list. NULL, // Filename-to-URI translation. NULL, // Validate userid. NULL, // Validate userid for this URI. NULL, // Host address access. NULL, // Check mime types. NULL, // Any last minute fixes. NULL, // Log. #if MODULE_MAGIC_NUMBER >= 19970103 NULL, // Header parser. #if MODULE_MAGIC_NUMBER >= 19970719 NULL, // Process initializer. #if MODULE_MAGIC_NUMBER >= 19970728 NULL, // Process cleanup. #if MODULE_MAGIC_NUMBER >= 19970902 NULL // Immediate handler. #endif #endif #endif #endif }; Notice that ORB_init is called in the handler itself. That means it will be called by the worker process that actually serve the http request. After ORB_init is called, the ORB will spawn a few internal threads. If the process call fork() soon afterwards, things will almost certainly not work. By putting ORB_init in the handler, it is certain that the process calling it will not be forking another process to do the work. Regards, Sai-Lai >>>>> John Hedges writes: > Hi Hany > I believe there are problems with Apache and pthreads. > Try a single threaded orb for your module (mico definately works and orbit looks like it ought to). > Cheers > John > On Thursday, January 04, 2001 12:29 PM, Hany Greiss [SMTP:hany@peac.com] wrote: >> >> >> Hello again, >> >> Just to follow up on my previous e-mail regarding hanging on the call >> to ORB_init from within an Apache module. I came across a suggestion to >> insert tracing within the argc/argv parameters. When I did this the only >> >> output I received was, >> >> omniORB: strand Ripper: start. >> >> It appears to hang at this point. Any ideas? >> >> Thanks, >> >> Hany >> hany@portalsphere.com >> >> >> -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From rds@apama.com Wed Jan 10 12:44:40 2001 From: rds@apama.com (Robert Smith) Date: Wed, 10 Jan 2001 12:44:40 -0000 Subject: [omniORB] omniNames and Java In-Reply-To: <3ozogzk4he.fsf@neem.uk.research.att.com> Message-ID: Our company would like to use omniNames as a nameserver for the ORB that comes with jdk1.3. (tnameserv does not persist names to disk so is no good for our purposes). When omniNames 3.0.2 is used the resolve_initial_references method in Java fails with an ArrayIndexOutOfBoundsException. This is due to a well known bug in the jdk1.3 ORB. However, omniNames 2.8.0 works fine with jdk 1.3. Why is this - how does omniNames 3.02 differ from 2.80? Is it perhaps due to the INS support in 3.02? Does the bug only affect the nameservice or can it cause problems if talking to other C++ code which uses omniORB? thanks for your help, Rob From dgrisby@uk.research.att.com Wed Jan 10 14:57:01 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 14:57:01 +0000 Subject: [omniORB] omniNames and Java In-Reply-To: Message from "Robert Smith" of "Wed, 10 Jan 2001 12:44:40 GMT." Message-ID: <200101101457.OAA28264@pineapple.uk.research.att.com> On Wednesday 10 January, "Robert Smith" wrote: > When omniNames 3.0.2 is used the resolve_initial_references method in Java > fails with an ArrayIndexOutOfBoundsException. This is due to a well known > bug in the jdk1.3 ORB. However, omniNames 2.8.0 works fine with jdk 1.3. > > Why is this - how does omniNames 3.02 differ from 2.80? Is it perhaps due to > the INS support in 3.02? Does the bug only affect the nameservice or can it > cause problems if talking to other C++ code which uses omniORB? The problem is with the object key, which is used to identify an object within an address space. omniORB 2.x always uses object keys which are 12 bytes in length. The JDK ORB is happy with that. omniORB 3's object keys vary in length depending on the name and policies of the POA in use. It seems to be the case that the JDK ORB has a bug for object keys shorter than 12 bytes, but only if the object is on the same host as the client. Unfortunately, the INS requires that the root context of the naming service has the object key "NameService", which is only 11 bytes. Not only that, but sub-contexts of the root context have objects keys of only 6 bytes. In C++ code that you write, you just need to make sure that the object keys for all your objects are longer than 12 bytes. omniORB generates the object key as follows: ( POA name )* [ nonce ] object id. Each tag is a single byte. The list of POA names represents the hierarchy of POAs. Transient POAs include an 8 byte nonce, used to keep the object keys unique for all time. System supplied object ids are always 4 bytes; user supplied ones can be any length. In the root POA, for example, the list of POA names is empty, so there is just nonce system id, which is 1 + 8 + 1 + 4 = 14 bytes, so that's OK. However, a persistent POA named "foo" using the system id policy would have "foo" system id = 1 + 3 + 1 + 4 = 9 bytes, which is too short for JavaIDL. If you need persistent POAs, make sure they have names of 10 characters or more, and you'll be OK. Please don't use this information to unpick omniORB's object keys. The details may well change in future. The Sun bug page for the problem is http://developer.java.sun.com/developer/bugParade/bugs/4351366.html Unfortunately, they have closed the issue, claiming that it is not a bug, despite the fact that it quite clearly is. Some of the comments add more details about why it fails. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Wed Jan 10 15:08:40 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 15:08:40 +0000 Subject: [omniORB] omniNames and Java In-Reply-To: Message from Duncan Grisby of "Wed, 10 Jan 2001 14:57:01 GMT." Message-ID: <200101101508.PAA28313@pineapple.uk.research.att.com> Following up my own post, I discovered some more interesting information. Bug number 4332373, which has actually been fixed, is the same problem, in a slightly different situation. It seems like the same buggy code is used in several (at least 3) different places. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From Richard.Turner@aculab.com Wed Jan 10 17:17:14 2001 From: Richard.Turner@aculab.com (Richard.Turner@aculab.com) Date: Wed, 10 Jan 2001 17:17:14 -0000 Subject: [omniORB] Problems building omniORB3 on SunOS 5.6 Message-ID: <0AEF0EB21F09D211AE4E0080C82733BFBFB333@mailhost.aculab.com> Hi This is my first time with omniORB so bear with me if this is obvious ... I'm running gcc 2.95.2 and GNU make 3.76.1 under SunOS 5.6 (Generic_105181-05 kernel). I've downloaded the 3.0.2 source code and the minimal python 1.5.2 material (omnipython-sun4_sosV_5_6_tar.gz) and made the right (well, hopefully right) changes to config/config.mk, mk/unix.mk and mk/platforms/sun4_sosV_5.6.mk. These now define platform as sun4_sosV_5.6, MKDIRHIER as mkdir -p, PYTHON as $(ABSTOP)/$(BINDIR)/omnipython and all the CXX... macros as necessary for using gcc/g++. I do a make export in the src directory. All appears to be well until I get to here ... ../../../../bin/sun4_sosV_5.6/omkdepend -D__cplusplus -D__GNUG__ -D__GNUC__ -DIDLMODULE_VERSION="0x2301" -I/usr/local/src/richard/omni/include -DPYTHON_INCLUDE= -I. -I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 idlc.cc idlpython.cc idlconfig.cc idldump.cc idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc idlutil.cc idlerr.cc lex.yy.cc y.t ab.cc ../../../../bin/sun4_sosV_5.6/omkdepend: warning: (from idlpython.cc) idlpython .cc: 302: # error "omniidl requires Python 1.5.2 or higher" This looks suspicious already as omnipython claims that it _is_ 1.5.2 ... $ ./omnipython Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import exceptions' failed; use -v for traceback Warning! Falling back to string-based exceptions 'import site' failed; use -v for traceback Python 1.5.2 (#3, Feb 17 2000, 12:43:07) [GCC 2.95 19990728 (release)] on sunos 5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> The build continues but eventally collapses at ... make[2]: Entering directory `/usr/local/src/richard/omni/src/lib/omniORB2' + mkdir -p omniORB3 ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 -ComniORB3 ../../../idl/Naming.idl Segmentation Fault make[2]: *** [omniORB3/Naming.hh] Error 139 make[2]: Leaving directory `/usr/local/src/richard/omni/src/lib/omniORB2' I've been through the FAQ and trawled the mailing list archive but I haven't had much luck in finding a cause or cure for this problem. I've since tried downloading the latest source snapshot (omniORB3-20010110_tar.gz) but this fails in exactly the same way. Help - can anyone enlighten me? Thanks, Richard Turner. richard.turner@aculab.com From Ben.Miller@Mercia.Com Wed Jan 10 17:24:15 2001 From: Ben.Miller@Mercia.Com (Ben Miller) Date: Wed, 10 Jan 2001 17:24:15 -0000 Subject: [omniORB] omniORB 3.0.x Message-ID: Hi all, Just a quick question: am I right in thinking that since this version of omniORB complies to the 2.3 CORBA spec, it supports pass by value semantics? Regards, Ben Miller Mercia Software Ltd. Mercia House Ashted Lock Aston Science Park Birmingham B7 4AZ, UK Registered Number: 1868855 (Cardiff) Tel: 44 (0)121 359 5096 Fax: 44 (0)121 359 0375 Web Site: http://www.mercia.com From dgrisby@uk.research.att.com Wed Jan 10 17:42:07 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 17:42:07 +0000 Subject: [omniORB] omniORB 3.0.x In-Reply-To: Message from Ben Miller of "Wed, 10 Jan 2001 17:24:15 GMT." Message-ID: <200101101742.RAA31010@pineapple.uk.research.att.com> On Wednesday 10 January, Ben Miller wrote: > Just a quick question: am I right in thinking that since this version > of omniORB complies to the 2.3 CORBA spec, it supports pass by value > semantics? I assume you mean valuetype? If so, I'm afraid that omniORB does not support it yet. By `complies', we mean that those bits which exist adhere to the spec. There are still some missing features. Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From Ben.Miller@Mercia.Com Wed Jan 10 17:52:40 2001 From: Ben.Miller@Mercia.Com (Ben Miller) Date: Wed, 10 Jan 2001 17:52:40 -0000 Subject: [omniORB] omniORB 3.0.x Message-ID: Okay. Yes, sorry, I do mean valuetype! In that case, can I use omniORB3 with RMI over IIOP? I've seen some discussion on this list previously that suggested that this could be done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's web-site (http://java.sun.com/j2se/1.3/docs/guide/rmi-iiop/rmi_iiop_pg.html#Wha tIs) says: "RMI-IIOP will interoperate with other ORBS that support the CORBA 2.3 specification. It will not interoperate with older ORBs, because these are unable to handle the IIOP encodings for Objects By Value. This support is needed to send RMI value classes (including strings) over IIOP." So I'm a bit confused as to whether the two will co-operate or not. Is it the case that I will have to be careful not to try to manipulate any non-IDL-native types in my interfaces? Can anyone shed any light on this? Cheers, Ben -----Original Message----- From: Duncan Grisby [mailto:dgrisby@uk.research.att.com] Sent: 10 January 2001 17:42 To: Ben Miller Cc: 'omniorb' Subject: Re: [omniORB] omniORB 3.0.x On Wednesday 10 January, Ben Miller wrote: > Just a quick question: am I right in thinking that since this version > of omniORB complies to the 2.3 CORBA spec, it supports pass by value > semantics? I assume you mean valuetype? If so, I'm afraid that omniORB does not support it yet. By `complies', we mean that those bits which exist adhere to the spec. There are still some missing features. Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- Mercia Software Ltd. Mercia House Ashted Lock Aston Science Park Birmingham B7 4AZ, UK Registered Number: 1868855 (Cardiff) Tel: 44 (0)121 359 5096 Fax: 44 (0)121 359 0375 Web Site: http://www.mercia.com From dgrisby@uk.research.att.com Wed Jan 10 18:04:23 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Wed, 10 Jan 2001 18:04:23 +0000 Subject: [omniORB] omniORB 3.0.x In-Reply-To: Message from Ben Miller of "Wed, 10 Jan 2001 17:52:40 GMT." Message-ID: <200101101804.SAA31174@pineapple.uk.research.att.com> On Wednesday 10 January, Ben Miller wrote: > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > discussion on this list previously that suggested that this could be > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > web-site I'm pretty certain that omniORB cannot be used with RMI-IIOP at the moment, no matter what types you use in your Java interfaces. If anyone knows otherwise, please let us know. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From popowich@chiliad.com Wed Jan 10 18:37:56 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 10 Jan 2001 13:37:56 -0500 Subject: [omniORB] omniORB 3.0.x In-Reply-To: <200101101804.SAA31174@pineapple.uk.research.att.com> References: <200101101804.SAA31174@pineapple.uk.research.att.com> Message-ID: <14940.44036.867756.866744@buckland.lilybay.com> Duncan Grisby writes: > On Wednesday 10 January, Ben Miller wrote: > > > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > > discussion on this list previously that suggested that this could be > > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > > web-site > > I'm pretty certain that omniORB cannot be used with RMI-IIOP at the > moment, no matter what types you use in your Java interfaces. If > anyone knows otherwise, please let us know. As the one who kicked off the "RMI over IIOP" thread and tried many ways to get omniORB to compile the IDL spit out from Sun's rmic compiler (jdk 1.3) I think I can verify that omniORB cannot be used with RMI-IIOP. The two sticking points for me were the usage of wstring (any usage of String in your java interface was converted to a wstring in the IDL) and valuetype (used liberally throughout the IDL), neither of which are supported by omniORB. I don't know if there are any other sticking points since I couldn't get beyond those problems. If you accept votes for what to develop next: whatever is needed for RMI-IIOP! Daniel Popowich From eliot@isogen.com Wed Jan 10 18:59:49 2001 From: eliot@isogen.com (W. Eliot Kimber) Date: Wed, 10 Jan 2001 12:59:49 -0600 Subject: [omniORB] omniORB 3.0.x References: <200101101804.SAA31174@pineapple.uk.research.att.com> <14940.44036.867756.866744@buckland.lilybay.com> Message-ID: <3A5CB125.DFCD06AD@isogen.com> Daniel Popowich wrote: > > Duncan Grisby writes: > > On Wednesday 10 January, Ben Miller wrote: > > > > > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > > > discussion on this list previously that suggested that this could be > > > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > > > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > > > web-site > > > > I'm pretty certain that omniORB cannot be used with RMI-IIOP at the > > moment, no matter what types you use in your Java interfaces. If > > anyone knows otherwise, please let us know. Just an info question: How is RMI-IIOP different from simply using CORBA object through java? I have the latter working with no difficulty (just ran idltojava on my IDL and imported the resulting client stub classes) against an OmniORB server, so I assume that RMI-IIOP is different from just using the built-in java ORB. Thanks, E. -- . . . . . . . . . . . . . . . . . . . . . . . . W. Eliot Kimber | Lead Brain 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.656.4139 | F 512.419.1860 | eliot@isogen.com w w w . d a t a c h a n n e l . c o m From popowich@chiliad.com Wed Jan 10 20:03:02 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 10 Jan 2001 15:03:02 -0500 Subject: [omniORB] omniORB 3.0.x In-Reply-To: <3A5CB125.DFCD06AD@isogen.com> References: <200101101804.SAA31174@pineapple.uk.research.att.com> <14940.44036.867756.866744@buckland.lilybay.com> <3A5CB125.DFCD06AD@isogen.com> Message-ID: <14940.49142.534595.865334@buckland.lilybay.com> W. Eliot Kimber writes: > Daniel Popowich wrote: > > > > Duncan Grisby writes: > > > On Wednesday 10 January, Ben Miller wrote: > > > > > > > In that case, can I use omniORB3 with RMI over IIOP? I've seen some > > > > discussion on this list previously that suggested that this could be > > > > done (http://www.uk.research.att.com/omniORB/archives/2001-01/ - Re: > > > > [omniORB] RMI over IIOP). However, the RMI-IIOP discussion on Sun's > > > > web-site > > > > > > I'm pretty certain that omniORB cannot be used with RMI-IIOP at the > > > moment, no matter what types you use in your Java interfaces. If > > > anyone knows otherwise, please let us know. > > Just an info question: How is RMI-IIOP different from simply using CORBA > object through java? I have the latter working with no difficulty (just > ran idltojava on my IDL and imported the resulting client stub classes) > against an OmniORB server, so I assume that RMI-IIOP is different from > just using the built-in java ORB. Simply, instead of being IDL->java, it's java->IDL. With RMI-IIOP, java programmers don't need to know a thing about IDL. They write their interfaces in java and implement their servers in java, just like RMI. Java client programmers can use the java interfaces without having to know any IDL mappings. It works like this: you write your interface in java, implement your server in java and then run the rmic compiler with a special switch, as in: 'rmic -iiop -idl mydomain.Foo' and *poof* you end up with Foo.idl. Now c++ or python programmers can compile Foo.idl and communicate with the java server. The problem folk are having is this: java passes by reference, so to express java in IDL required a new IDL type: valuetype. This allows passing objects by value. Think of it as a struct with methods, or an interface with data. The irony is that no other orb other than Sun's jdk (that I know of) support the new IDL types. So, it will be great, someday. Daniel Popowich From jeff@infohazard.org Wed Jan 10 20:25:11 2001 From: jeff@infohazard.org (Jeff Schnitzer) Date: Wed, 10 Jan 2001 12:25:11 -0800 Subject: [omniORB] omniORB 3.0.x Message-ID: <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> >From: Daniel Popowich [mailto:popowich@chiliad.com] > >The problem folk are having is this: java passes by reference, so to >express java in IDL required a new IDL type: valuetype. This allows >passing objects by value. Think of it as a struct with methods, or an >interface with data. The irony is that no other orb other than Sun's >jdk (that I know of) support the new IDL types. So, it will be great, >someday. I'm in the exact same situation; in fact, I subscribed to this list two days ago because I'm trying to figure out how to use RMI-IIOP to talk to a C++ server object. My guess is that if someone was super careful writing the Java interfaces (use byte[] instead of String, simple types only), rmic will probably produce idl which makes omniORB happy. Unfortunately I need to be able to burst an array of structures across the wire on a single remote call, so I (apparently) need valuetypes. I'm bewildered that CORBA had no standard way to send structs until so recently; Microsoft has had structs in the DCOM IDL for years. I'm going to be taking a look at Orbacus (http://www.ooc.com/ob/) next; it claims to support valuetypes. It's a commercial product but supposedly free for noncommercial use. I believe there are other commercial ORBs which support valuetypes, but they get pretty expensive. Jeff From popowich@chiliad.com Wed Jan 10 21:51:21 2001 From: popowich@chiliad.com (Daniel Popowich) Date: Wed, 10 Jan 2001 16:51:21 -0500 Subject: [omniORB] omniORB 3.0.x In-Reply-To: <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> References: <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> Message-ID: <14940.55641.496778.188904@buckland.lilybay.com> Jeff Schnitzer writes: > I'm in the exact same situation; in fact, I subscribed to this list two > days ago because I'm trying to figure out how to use RMI-IIOP to talk to > a C++ server object. Funny. I joined the list a few weeks ago for the same reason. > Unfortunately I need to be able to burst an array of structures across > the wire on a single remote call, so I (apparently) need valuetypes. > I'm bewildered that CORBA had no standard way to send structs until so > recently; Microsoft has had structs in the DCOM IDL for years. You *can* do this with CORBA (a sequence of structs) and always have been able to, it's just that rmic maps java objects to valuetypes. > I'm going to be taking a look at Orbacus (http://www.ooc.com/ob/) next; > it claims to support valuetypes. It's a commercial product but > supposedly free for noncommercial use. I believe there are other > commercial ORBs which support valuetypes, but they get pretty expensive. If you come up with something, please post it. -d From eliot@isogen.com Wed Jan 10 21:52:35 2001 From: eliot@isogen.com (W. Eliot Kimber) Date: Wed, 10 Jan 2001 15:52:35 -0600 Subject: [omniORB] omniORB 3.0.x References: <200101101804.SAA31174@pineapple.uk.research.att.com> <14940.44036.867756.866744@buckland.lilybay.com> <3A5CB125.DFCD06AD@isogen.com> <14940.49142.534595.865334@buckland.lilybay.com> Message-ID: <3A5CD9A3.CC7DB864@isogen.com> Daniel Popowich wrote: > It works like this: you write your interface in java, implement your > server in java and then run the rmic compiler with a special switch, > as in: 'rmic -iiop -idl mydomain.Foo' and *poof* you end up with > Foo.idl. Now c++ or python programmers can compile Foo.idl and > communicate with the java server. So am I correct in understanding this to mean that, modulo the non-support of valuetype, I don't have to explicitly write Java servants (as I would in Python or C++) in order to give remote CORBA clients access to the Java objects? If so, that's pretty handy. However, it seems to me that in real applications, you will almost always need to tailor your CORBA API in a way that is different from a straight Java API (or a straight Python API for that matter), such that a completely automatic mapping from Java classes to IDL classes will usually not be the optimal solution. So maybe it's not such a big deal in practice given that I may be motivated to write special Java CORBA servants anyway? Thanks, E. -- . . . . . . . . . . . . . . . . . . . . . . . . W. Eliot Kimber | Lead Brain 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.656.4139 | F 512.419.1860 | eliot@isogen.com w w w . d a t a c h a n n e l . c o m From mlauer@stud.uni-frankfurt.de Thu Jan 11 00:41:03 2001 From: mlauer@stud.uni-frankfurt.de (Michael Lauer) Date: Thu, 11 Jan 2001 01:41:03 +0100 Subject: [omniORB] Is this list active ? Message-ID: No mail since 6.12.2000 hmmm... have I been removed ? If so, why ? :M: -- Michael 'Mickey' Lauer . . . . . . . . . mickey@Vanille.de How could anyone know me - when I don't even know myself ? From Ben.Miller@Mercia.Com Thu Jan 11 09:58:14 2001 From: Ben.Miller@Mercia.Com (Ben Miller) Date: Thu, 11 Jan 2001 09:58:14 -0000 Subject: [omniORB] omniORB 3.0.x Message-ID: Er, snap (only I joined yesterday!)... -----Original Message----- From: Daniel Popowich [mailto:popowich@chiliad.com] Sent: 10 January 2001 21:51 To: Jeff Schnitzer Cc: popowich@chiliad.com; omniorb-list Subject: RE: [omniORB] omniORB 3.0.x Jeff Schnitzer writes: > I'm in the exact same situation; in fact, I subscribed to this list two > days ago because I'm trying to figure out how to use RMI-IIOP to talk to > a C++ server object. Funny. I joined the list a few weeks ago for the same reason. > Unfortunately I need to be able to burst an array of structures across > the wire on a single remote call, so I (apparently) need valuetypes. > I'm bewildered that CORBA had no standard way to send structs until so > recently; Microsoft has had structs in the DCOM IDL for years. You *can* do this with CORBA (a sequence of structs) and always have been able to, it's just that rmic maps java objects to valuetypes. > I'm going to be taking a look at Orbacus (http://www.ooc.com/ob/) next; > it claims to support valuetypes. It's a commercial product but > supposedly free for noncommercial use. I believe there are other > commercial ORBs which support valuetypes, but they get pretty expensive. If you come up with something, please post it. -d Mercia Software Ltd. Mercia House Ashted Lock Aston Science Park Birmingham B7 4AZ, UK Registered Number: 1868855 (Cardiff) Tel: 44 (0)121 359 5096 Fax: 44 (0)121 359 0375 Web Site: http://www.mercia.com From rogerb@harlequin.co.uk Thu Jan 11 10:29:48 2001 From: rogerb@harlequin.co.uk (Roger Barnett) Date: Thu, 11 Jan 2001 10:29:48 +0000 Subject: [omniORB] omniORB 3.0.x Message-ID: <802569D1.0039A980.00@notesman.man.harlequin.co.uk> >From: Daniel Popowich [mailto:popowich@chiliad.com] > >The problem folk are having is this: java passes by reference, so to >express java in IDL required a new IDL type: valuetype. This allows >passing objects by value. Think of it as a struct with methods, or an >interface with data. The irony is that no other orb other than Sun's >jdk (that I know of) support the new IDL types. So, it will be great, >someday. Err no, the problem is that people are trying to express Java in IDL - reverse engineering is never easy ! One good reason for ORB implementors being slow to support the whole objects-by-value thing is that the spec has been through some fairly major revisions (at least twice, IIRC) to try and get it "right". IMO this was largely because until the shape of CORBA Component support was finally decided there was no clear justification for introducing such a language-specific carbuncle onto the OMA and into OMG IDL. This is also why some of the more complex (and expensive) commercial products have now implemented obv - its part of their EJB/"portal" strategy. Roger Barnett From dgrisby@uk.research.att.com Thu Jan 11 10:31:51 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Thu, 11 Jan 2001 10:31:51 +0000 Subject: [omniORB] omniORB 3.0.x In-Reply-To: Message from "Jeff Schnitzer" of "Wed, 10 Jan 2001 12:25:11 PST." <7E95297C88EDED4EB43BADD11871FA798B53@CHILL.haunt.infohazard.org> Message-ID: <200101111031.KAA32609@pineapple.uk.research.att.com> On Wednesday 10 January, "Jeff Schnitzer" wrote: > Unfortunately I need to be able to burst an array of structures across > the wire on a single remote call, so I (apparently) need valuetypes. > I'm bewildered that CORBA had no standard way to send structs until so > recently; Microsoft has had structs in the DCOM IDL for years. CORBA has always had structs and other complex constructed types. The problem is that with most types in Java it is acceptable to use a nil reference to indicate the absence of an object. The original CORBA types have no way to represent that (although it has always been possible to fake it with unions or bounded sequences). Part of the objects by value specification adds "value boxes", which either contain the boxed type, or nil. So, you can have IDL like valuetype StringValue string; which is a type containing either a normal string, or nil. The Java to IDL mapping maps lots of things like that. The other problem is that with RMI, you can transmit objects which have behaviour as well as state. This relies on being able to transmit compiled code (via HTTP) if the receiving process doesn't have it. This clearly isn't going to work when transmitting to a language other than Java. But CORBA has a go anyway. You can declare a valuetype like valuetype Foo { public long l; public string s; long doSomething(in short a, in boolean b); }; When you receive one of those, you have to hope that you have an implementation of the doSomething() method, or you can get one from somewhere. Java can, in theory, transmit the code by HTTP as with RMI, but I'm not sure if it actually does yet. You could do the same thing with Python, as long as both client and server were Python. With C++, there's no hope at all. Anyway, it's all horribly ugly. If you want to be totally confused, read the section of the GIOP spec about marshalling valuetypes. It's going to be a long time before interoperability between ORBs is as good with valuetypes as it is with the other types. That said, we will probably support valuetype in the next major releases of omniORB and omniORBpy. No promises, though. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From erberj@post.ch Thu Jan 11 15:43:35 2001 From: erberj@post.ch (erberj@post.ch) Date: Thu, 11 Jan 2001 16:43:35 +0100 Subject: [omniORB] error compiling idl generated code Message-ID: <26D7602EA56DD21197BB0000F840029A03EA5512@hceh71.post.ch> When compiling the result of an IDL run, i do get the follwoing error. What is causing it? Thanks in advance Jakob class LongListCT : public _CORBA_Unbounded_Sequence< CORBA::LongLong> { .......................................................^ %CXX-E-EXPTYPSPECIFIER, expected a type specifier at line number 480 in file OMNIROOT:[SRC.EXAMPLES.ECHO]BASECS.HH;1 From prapier@coactive.com Fri Jan 12 01:17:25 2001 From: prapier@coactive.com (Peter Rapier) Date: Thu, 11 Jan 2001 17:17:25 -0800 Subject: [omniORB] corbaloc Message-ID: <7118259C3044D311942700508B2CA5BB4F2585@balance.coactive.com> I have worked with Orbacus 3, a BOA based orb that contains the "corbaloc" feature of the INS. Would it be possible to port this feature, which is in OO3 back into omniORB2.6? From looking through the archives it would appear that the INS has some dependency on the POA. Thanks Peter From erberj@post.ch Fri Jan 12 08:00:53 2001 From: erberj@post.ch (erberj@post.ch) Date: Fri, 12 Jan 2001 09:00:53 +0100 Subject: [omniORB] OmniOrb 3.0 and "long long" Message-ID: <26D7602EA56DD21197BB0000F840029A03EA5516@hceh71.post.ch> Hi, does OmniOrb support this type? The idl compiler translates it, but the ORB Include files seem not to know it. Regards Jakob From vonWedel@lfpt.rwth-aachen.de Fri Jan 12 08:52:38 2001 From: vonWedel@lfpt.rwth-aachen.de (vonWedel@lfpt.rwth-aachen.de) Date: Fri, 12 Jan 2001 09:52:38 +0100 Subject: [omniORB] omniORB / omniORBpy binaries for use with Python 2.0 Message-ID: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0031FBA1C12569D2_= Content-Type: text/plain; charset="us-ascii" Hi omniORBers, the omniORBpy pages state that > These binaries only work with Python 1.5.2. They will not work with later Python versions. Once Python 2.0 is released, we shall provide binaries for that too. Is there a plan when binaries for Python 2.0 will be released? Lars --=_alternative 0031FBA1C12569D2_= Content-Type: text/html; charset="us-ascii"
Hi omniORBers,

the omniORBpy pages state that

> These binaries only work with Python 1.5.2. They will not work with later Python versions. Once Python 2.0 is released, we shall provide binaries for
that too.

Is there a plan when binaries for Python 2.0 will be released?

Lars
--=_alternative 0031FBA1C12569D2_=-- From srowe@adaptivebroadband.com Fri Jan 12 09:20:58 2001 From: srowe@adaptivebroadband.com (Rowe, Simon) Date: Fri, 12 Jan 2001 09:20:58 -0000 Subject: [omniORB] Problems with omniORB app on WinNT Message-ID: <35940AC31FFCD311AAF8009027D0D07D2F5686@cambr-exch1.cambridge.adaptivebroadband.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07C78.F90B21F0 Content-Type: text/plain; charset="iso-8859-1" We're experiencing a problem with our application on Windows NT that is running fine on Linux and would appreciate some help with diagnosing what is wrong. Our application consists of four components, EC, EA, CS and a GUI. The first three are written in C++ using omniORB 2.8.0, the GUI is written in Java. The EC and EA are to run on NT, they can be started and can commuicate with each other. The CS runs on Linux, it fails to contact the EC, it cannot get a reference to the EC object. The GUI runs on either NT or Linux, neither can contact the EC. If I try and telnet to the IIOP port on the NT machine (either from the NT machine or from the Linux machine) I get a connection refused. netstat -a shows something is listening on INADDR_ANY on the expected port. If I shut down our processes and start an omniNames server on the same port I can connect to it. I've tried running with -ORBtraceLevel 25 all this shows is that the accept() is not unblocked for the above cases that fail. The previous version of our product worked fine but we've undergone an extensive re-write recently. I'm wondering if this is an OS issue but the debugging enviroment is so poor (I'm not a Windows fan...) I'm working blind. Any tips? Simon ------_=_NextPart_001_01C07C78.F90B21F0 Content-Type: text/html; charset="iso-8859-1"

We're experiencing a problem with our application on Windows NT that is running fine on Linux and would appreciate some help with diagnosing what is wrong.

Our application consists of four components, EC, EA, CS and a GUI. The first three are written in C++ using omniORB 2.8.0, the GUI is written in Java.

If I shut down our processes and start an omniNames server on the same port I can connect to it.

I'm wondering if this is an OS issue but the debugging enviroment is so poor (I'm not a Windows fan...) I'm working blind.

Any tips?

Simon

Er, scratch that one. It was a port configuration error. Sorry about that.

Simon

Hi,

Thanks.

Sincerely, Daniel von Tabouillot

__________________________________________________________________

Yes, it is fixed in the latest code stream of = V2.8 (omniORB-20001129.tar).

I’ve not checked 3.0 = yet.

Regards.

Neeraj

<= ![if = !supportEmptyParas]>

I see that you posted a bug in omniORB on OSF that was caused by = gethostbyname.=

Has this been fixed? If so, with which release,=

Thanks = =

Matthew Berry

vonWedel@lfpt.RWTH-Aachen.DE
Sent by: owner-omniorb-list@uk.research.att.com

17/01/01 12:01

To: omniorb-list@uk.research.att.com
cc:
Subject: [omniORB] Fatal exception during event sending

vonWedel@lfpt.RWTH-Aachen.DE
Sent by: owner-omniorb-list@uk.research.att.com

17/01/01 12:01

To: omniorb-list@uk.research.att.com
cc:
Subject: [omniORB] Fatal exception during event sending

Hi,

The IDL Command line I use is:

omniidl.exe -bcxx -K -Wbexample -Wbtp -Wbh=3D.h = -Wbs=3DSK.cpp=20 -Wbd=3DDynSK.cpp -Cr:\nova\corba\inc filename.idl

Also, am I right in thinking that the -WBexample = arguement=20 only generates example source for the inheritance = implementation?

P.S. I've included the warnings = below......

Roger Hughes

I have read the manual that comes with = omni orb and it suggests to keep retrying, but this does not explain = what is happening, each and everytime.

Server on Solaris, client on NT, using = omniorb 3.0.1

Mikey

Further to this e-mail I was able to switch on tracing an = extrapolate the=20 following information

Can=20 anyone explain what we is going on here?

-----Original Message-----
From: Michael Keay=20 [mailto:MKeay@SeeBeyond.com]
Sent: Monday, January 22, 2001 = 3:03=20 PM
To: Omniorb-List@Uk. Research. Att. Com=20 (E-mail)
Subject: [omniORB] = CORBA::COMM_FAILURE

We have been working on a project, to = connect to a=20 thirdparty system. We are getting a COMM_FAILURE exception when = trying to=20 invoke a method on an object reference. But we do have a valid object = reference. Yet, when we use the supplied, sample client, everything = works=20 fine. Does, anyone have any idea why we would experience such an=20 exception?

I have read the manual that comes with = omni orb and=20 it suggests to keep retrying, but this does not explain what is = happening,=20 each and everytime.

Server on Solaris, client on NT, using = omniorb=20 3.0.1

Mikey =

Thanks for the prompt reply.

I have been able to step through my code and I am able to determine the following.

The server object process is started.
The server object process is terminated when the client side attempts to invoke the relevant method.

Any ideas?

Here is what happened:

1. ORB starts up and was given "GAPS1" port 7655 to resolve initial
references. It managed to the root naming context from GAPS1.

2. May be a lookup is done to the naming service to get an object reference
of type ZImporter. This also succeeded. Notice that this step is not
shown on the trace. I'm just guessing.

You should check wheter you indeed have a ZImporter object running somewhere
and it has been registered with the naming service.

Sai-Lai

>>>>> Michael Keay writes:

> I have read the manual that comes with omni orb and it suggests to keep
> retrying, but this does not explain what is happening, each and everytime.

> Server on Solaris, client on NT, using omniorb 3.0.1

> Mikey

One solution to my problem is to use a different port for every application, in which case each thread is unblocked seprately.

-- 
Arnault Bonafos     Software Engineer
Tumbleweed    Communications    Corp.
ph: (650) 216-2027  fx: (650) 216-2003

--------------1F9AEE06BAC29CDBE6CAB9B9-- From lars@ibp.de Wed Jan 24 23:41:12 2001 From: lars@ibp.de (Lars Immisch) Date: Thu, 25 Jan 2001 00:41:12 +0100 Subject: [omniORB] compile problems on Win32, NT4 In-Reply-To: <3oofwwztox.fsf@neem.uk.research.att.com> References: <200101232318.AAA11443@googleplex.ibp.de> <3oofwwztox.fsf@neem.uk.research.att.com> Message-ID: <200101242341.AAA12606@googleplex.ibp.de> Hi Sai-Lai, > The fix to your previous bug report is now in the repository. Thanks a lot; I managed to compile omniORB in the meantime and the bug is fixed. > I've no idea what is causing the omnicpp problem. We have seem reports > about strange behaviours on Windows 98. That seems to do with the use of > pipe to send the preprocessor output to omniidl. There is now a -T option > to omniidl to tell it to use a temporary file instead of a pipe. You may > want to APPEND the following to mk/platforms/x86_nt_4.0.mk: > > OMNIORB_IDL_ONLY += -T > > However I should also say that I've never seen this on NT. May be it is > time to reboot your box. By fortunate mistake, I have found out that if I build omniORB *without* the BuildDebugBinary option in mk/config.mk, it works ok. With the BuildDebugBinary option set to 1, omniidl crashes (and this is reproducable). I like having the debug binaries, so I normally enable it by default. Just to let you know, I have experimented with the -T flag and it makes no difference. > On the make clean problem. This is a known problem if the gnumake version > is older than ~3.77. I've put up a new gun-win32-lite.zip which is based on > a later version of cygwin and do come with a later version of gnumake. Thanks. I'll redo the build with my normal cygwin environment now and/or check the latest gnu-win32-lite. - Lars From rodrigc@mediaone.net Thu Jan 25 01:27:43 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Wed, 24 Jan 2001 20:27:43 -0500 Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <3A6F5503.5CC0C9B7@sympatico.ca>; from seefeld@sympatico.ca on Wed, Jan 24, 2001 at 05:19:47PM -0500 References: <3A6F5503.5CC0C9B7@sympatico.ca> Message-ID: <20010124202743.A29575@mediaone.net> Hi, How does this tool compare with doxygen? We have started using doxygen at work, and the output is very nice: http://www.stack.nl/~dimitri/doxygen/ -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From seefeld@sympatico.ca Thu Jan 25 01:50:43 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 24 Jan 2001 20:50:43 -0500 Subject: [omniORB] Synopsis 0.3 released References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> Message-ID: <3A6F8673.8803E4EC@sympatico.ca> Craig Rodrigues wrote: > > Hi, > > How does this tool compare with doxygen? We have started > using doxygen at work, and the output is very nice: > http://www.stack.nl/~dimitri/doxygen/ yeah, I know about doxygen. However, synopsis is written in a different spirit. It's highly modular, in that it lets you plug in new parsers and formatters. I think you are *much* more flexible with this approach. I don't know doxygen's inner workings in detail, I just know that it's all one single tool, i.e. a single parser that needs to know about all the languages, and even document string conventions being used. It wasn't fit for what I wanted it to do, that's why I started synopsis. My main interest is the berlin project, where we have a pretty big base of IDL interfaces and implementations in various languages (notably C++ and python). So I wanted a tool that understands all of them, and can even cross reference between these modules. That's now possible. I don't think that doxygen can do that. In any case, synopsis is still relatively young. A lot of ideas are there and need to be fleshed out. Help is always welcome ! :) A big acknowledgement has to go to Duncan, as his wonderful omniidl implementation provided the basic ideas, I just generalized the AST, and added some plugins around that :) Regards, Stefan From rodrigc@mediaone.net Thu Jan 25 02:26:15 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Wed, 24 Jan 2001 21:26:15 -0500 Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <3A6F8673.8803E4EC@sympatico.ca>; from seefeld@sympatico.ca on Wed, Jan 24, 2001 at 08:50:43PM -0500 References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> <3A6F8673.8803E4EC@sympatico.ca> Message-ID: <20010124212615.A29904@mediaone.net> On Wed, Jan 24, 2001 at 08:50:43PM -0500, Stefan Seefeld wrote: > > In any case, synopsis is still relatively young. A lot of ideas > are there and need to be fleshed out. Help is always welcome ! :) Well, one thing I would suggest is, look at the tags that doxygen supports, and support those in synopsis as well. It is very nice in a software project to standardize on one style of documenting code. For example, the javadoc style is the default style for Java programmers. It is a pain in the neck to change documenting standards to appease the latest documentation generator. :) -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From seefeld@sympatico.ca Thu Jan 25 02:48:40 2001 From: seefeld@sympatico.ca (Stefan Seefeld) Date: Wed, 24 Jan 2001 21:48:40 -0500 Subject: [omniORB] Synopsis 0.3 released References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> <3A6F8673.8803E4EC@sympatico.ca> <20010124212615.A29904@mediaone.net> Message-ID: <3A6F9408.70122894@sympatico.ca> Craig Rodrigues wrote: > > On Wed, Jan 24, 2001 at 08:50:43PM -0500, Stefan Seefeld wrote: > > > > In any case, synopsis is still relatively young. A lot of ideas > > are there and need to be fleshed out. Help is always welcome ! :) > > Well, one thing I would suggest is, look at the tags that > doxygen supports, and support those in synopsis as well. > > It is very nice in a software project to standardize on one > style of documenting code. For example, the javadoc style > is the default style for Java programmers. > > It is a pain in the neck to change documenting standards > to appease the latest documentation generator. :) Thanks, you make my point :) Synopsis is modular to the point that you can not only choose between a variety of comment parser/formatters, you can even plugin your own little python script ! (*) And yes, we currently do support javadoc style comments. Among others...:) Indeed, I always found it pretty pervers that people had to adapt to tools. It should be the other way around. Regards, Stefan (*) as an example for the kind of flexibility I'm talking about, I wrote a little python function as an extension to the Linker module. It maps C++ names to their IDL equivalents (POA_Foo maps to Foo, Bar_ptr maps to Bar); I use that to tell the linker how to resolve references, i.e. clicking on 'Bar_ptr' will take you to the definition of the 'Bar' type... From rodrigc@mediaone.net Thu Jan 25 02:58:43 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Wed, 24 Jan 2001 21:58:43 -0500 Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <3A6F9408.70122894@sympatico.ca>; from seefeld@sympatico.ca on Wed, Jan 24, 2001 at 09:48:40PM -0500 References: <3A6F5503.5CC0C9B7@sympatico.ca> <20010124202743.A29575@mediaone.net> <3A6F8673.8803E4EC@sympatico.ca> <20010124212615.A29904@mediaone.net> <3A6F9408.70122894@sympatico.ca> Message-ID: <20010124215843.A29962@mediaone.net> On Wed, Jan 24, 2001 at 09:48:40PM -0500, Stefan Seefeld wrote: > > It is a pain in the neck to change documenting standards > > to appease the latest documentation generator. :) > > Thanks, you make my point :) You're welcome! The other open source ORB I use (TAO) has completely changed over to doxygen style commenting (that's why I know about doxygen). Here is an example of their documentation: http://doc.ece.uci.edu/Doxygen/Beta/html/ And here is an example source file with doxygen comments: http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ace/ACE.h The TAO project switched from the OSE tools (http://ose.sourceforge.net/) to doxygen, and that required changing all the source code. But doxygen output is pretty nice, so they considered it worth it. Would synopsis be compatible with this format? -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From chalky@null.net Thu Jan 25 03:33:32 2001 From: chalky@null.net (Stephen Davies) Date: Thu, 25 Jan 2001 14:33:32 +1100 (EST) Subject: [omniORB] Synopsis 0.3 released In-Reply-To: <20010124215843.A29962@mediaone.net> Message-ID: Hi Craig, I am the 'other' developer for Synopsis. Version 0.3 includes modular comment parsing and formatting, which has already been used to support the "//." style comments used in Berlin's sources and the "/**" style used by javadoc. On top of this you can also use javadoc-style @tags whatever format you use, although only @see has been implemented so far. Adding further styles is very possible, as is adding other features we do not currently support such as inline inheritance graphs on the Class pages. Indeed, version 0.4 may well support most if not all of doxygen's syntax as another plugin. 0.3 includes a formatter that generates an inheritance diagram as a test of the GraphViz (the same tool used by doxygen) which will probably be extended to include the inheritance/ collaboration diagrams directly in HTML pages by 0.4. I am excited by how modular Synopsis is, compared to other monolithic tools. It has the potential to adapt itself to any situation you may require. The more features we implement the more we refactor common functionality -- the current HTML layout is modelled after Javadoc which I have used before, but it is entirely possible that by 0.4 we will support other layouts such as that used by doxygen. We will ensure that doing so will pave the way for other layouts such that it will be trivial for users to write a small python script to format things as they like! Following similar principles has already led to the possibility of writing your own little python script to format or parse comments and reference it from the command-line (without modifing synopsis itself!). Feedback from potential users such as yourself is extremely valuable to us. Although Synopsis originated as a tool to document Berlin, it has the possibility for much wider use, driven by requests such as this. Both Stefan and I are taking steps such that each extra feature *enhances* the elegance of the design, rather than convoluting it as I have seen elsewhere. I must admit however, that Stefan did a good job of laying out a very elegant base upon which we have been working :) Stay tuned :) //--------=[ Chalky (Stephen Davies) -- Chalky@null.net ]=--------\\ //-------=[ Powered by Linux -- "Escape the Gates of Hell" ]=-------\\ //--=[ Programmer(C/C++/Java) and 4th Year CSE/CS Student at RMIT ]=--\\ From tobias_eriksson@agilent.com Thu Jan 25 10:19:20 2001 From: tobias_eriksson@agilent.com (ERIKSSON,TOBIAS (A-Sweden,ex1)) Date: Thu, 25 Jan 2001 11:19:20 +0100 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() and when? Message-ID: <4B68A8D2B880D311BCB70090278CBF621F7D4E@cordelia> Hi I'm trying to use narrow to tell me if the type of the object beeing narrowed actually is of the type I want, I think that it will throw BAD_PARAM if they are not the same, is this correct and are there any others? Regards Tobias From S.Lo@uk.research.att.com Thu Jan 25 13:59:04 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 25 Jan 2001 13:59:04 +0000 Subject: [omniORB] Problems compiling omni4_0_develop In-Reply-To: <3A6F0207.1050105@factoriaX.com> (Marc Ordinas i Llopis's message of "Wed, 24 Jan 2001 11:25:43 -0500") References: <3A6F0207.1050105@factoriaX.com> Message-ID: <3owvbjwx5j.fsf@neem.uk.research.att.com> The omni4_0_develop branch should now compile. Apart from some missing GNUmakefiles, I have to make some changes to the cxx backend to fix the error you've seen. Its interesting that the backend problem only occurs when omniidl is given a relative path name as the -p option. I suggest you do a fresh cvs checkout. I'm not 100% sure a cvs update will pick up the changes in directory names etc. Sai-Lai >>>>> Marc Ordinas i Llopis writes: > Hi all, > I'm sending this message here as I don't know where else I can get help on > this. I'm trying to compile omni4_0_develop as I wanted to try the new > codeset features, but I get lots of problems. > My development system is RedHat 7 with the last compiler (which works > compiling omniORB 3.0.2) and python 2.0 on an Athlon. > Just out of CVS, after editing config.mk and i586_linux_2.0_glibc2.1.mk, I > try make export in src/. It all goes well until it gets to the omniORB2 > directory, where it complains it does not have a 'dir.mk' file. I change > dir.mk in src/lib to set the subdirs to 'omnithread' and 'omniORB' instead > of 'omniORB2', as per the update.log I think omniORB2 is no longer used. > Then it complains that omniORB/ does not have a GNUmakefile, so I copy all > the GNUmakefiles from the omniORB2/ dir tree. That seems to work just until > it tries to generate the stubs for some files, when python fails (this also > happened with python 1.5.2, by the way). It says: > make[2]: Entering directory `/home/marc/codi/omni/src/lib/omniORB' > ../../../bin/i586_linux_2.0_glibc2.1/omniidl -bcxx -Wba > -p../../../src/lib/omniORB -Wbdebug -nf -WbF -ComniORB4 > ../../../idl/corbaidl.idl > omniidl: fatalError occurred, in debug mode. >>> An internal exception was caught > Stack: > ------------------------- > File "../../../bin/i586_linux_2.0_glibc2.1/omniidlrun.py", line 97, in ? > omniidl.main.main() > File "./main.py", line 422, in main > File "../../../src/lib/omniORB/omniidl_be/cxx/__init__.py", line 276, in > run > Make stubs for the Interface Repository appear in the CORBA module""" > File "../../../src/lib/omniORB/omniidl_be/cxx/util.py", line 152, in > fatalError > Exception: > ------------------------- > Traceback (most recent call last): > File "../../../src/lib/omniORB/omniidl_be/cxx/__init__.py", line 248, in > run > """cdrUnmarshal(TypeCode, string) -> data > File > "/home/marc/codi/omni/src/lib/omniORB/omniidl_be/cxx/header/__init__.py", > line 280, in run > defs_fragment(defs_stream, tree) > File > "/home/marc/codi/omni/src/lib/omniORB/omniidl_be/cxx/header/__init__.py", > line 140, in defs_fragment > import omniidl_be.cxx.header.defs > ImportError: No module named defs > make[2]: *** [omniORB4/corbaidl_defs.hh] Error 1 > make[2]: Leaving directory `/home/marc/codi/omni/src/lib/omniORB' > make[1]: *** [export] Error 1 > I've tried anything I've been able to think of to get it to include defs, > but even as I can import it in an interactive session, I'm unable to make > it work. > And by the way, I think there's an error in src/lib/omniORB/dir.mk, some > files are not prepended the directory omniORB4. Here's the diff : > Index: dir.mk > =================================================================== > RCS file: /cvsroot/omni/src/lib/omniORB/Attic/dir.mk,v > retrieving revision 1.7.2.5 > diff -r1.7.2.5 dir.mk > 66c66 > < omniORB4/corbaidl_defs.hh corbaidl_operators.hh corbaidl_poa.hh: > corbaidl.idl > --- >> omniORB4/corbaidl_defs.hh omniORB4/corbaidl_operators.hh > omniORB4/corbaidl_poa.hh: corbaidl.idl > Thanks for any help, > Marc Ordinas i Llopis, > factoriaX -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From AIlinykh@SECTORBASE.COM Thu Jan 25 16:53:42 2001 From: AIlinykh@SECTORBASE.COM (Ilinykh, Andre) Date: Thu, 25 Jan 2001 08:53:42 -0800 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? Message-ID: <8F4C99C66D04D4118F580090272A7A234F356D@sectorbase1.sectorbase.com> There are others, for example COMM_FAILURE. _narrow() can check the type of real object. I'm not sure when it does this way. At least, every time I create object reference by string_to_object("corbaloc:iiop:/...") it goes to my server. Thanks, Andrey -----Original Message----- From: ERIKSSON,TOBIAS (A-Sweden,ex1) [mailto:tobias_eriksson@agilent.com] Sent: Thursday, January 25, 2001 2:19 AM To: omniorb-list@uk.research.att.com Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() and when? Hi I'm trying to use narrow to tell me if the type of the object beeing narrowed actually is of the type I want, I think that it will throw BAD_PARAM if they are not the same, is this correct and are there any others? Regards Tobias From S.Lo@uk.research.att.com Thu Jan 25 18:11:21 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 25 Jan 2001 18:11:21 +0000 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? In-Reply-To: <8F4C99C66D04D4118F580090272A7A234F356D@sectorbase1.sectorbase.com> ("Ilinykh, Andre"'s message of "Thu, 25 Jan 2001 08:53:42 -0800") References: <8F4C99C66D04D4118F580090272A7A234F356D@sectorbase1.sectorbase.com> Message-ID: <3on1cfwlh2.fsf@neem.uk.research.att.com> _narrow() may or may not have to contact the real object to determine whether the operation should succeed. The chapter on type checking in the omniORB user guide explains this in some detail. Since a remote invocation may be called as part of a _narrow, the full range of system exception may be reported. By the way, omniORB never needs to contact the server to do string_to_object. If you have some code that shows the contrary, please send it to me. Sai-Lai >>>>> Ilinykh, Andre writes: > There are others, for example COMM_FAILURE. _narrow() can check the type of > real object. I'm not sure when it does this way. At least, every time I > create object reference by string_to_object("corbaloc:iiop:/...") it goes to > my server. > Thanks, > Andrey > -----Original Message----- > From: ERIKSSON,TOBIAS (A-Sweden,ex1) > [mailto:tobias_eriksson@agilent.com] > Sent: Thursday, January 25, 2001 2:19 AM > To: omniorb-list@uk.research.att.com > Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() > and when? > Hi > I'm trying to use narrow to tell me if the type of the object beeing > narrowed actually is of the type I want, > I think that it will throw BAD_PARAM if they are not the same, is this > correct and are there any others? > Regards > Tobias -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From AIlinykh@SECTORBASE.COM Thu Jan 25 18:35:57 2001 From: AIlinykh@SECTORBASE.COM (Ilinykh, Andre) Date: Thu, 25 Jan 2001 10:35:57 -0800 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? Message-ID: <8F4C99C66D04D4118F580090272A7A234F356E@sectorbase1.sectorbase.com> We don't use NameService, I create object Factory using IP and port. Every time server is down I get COMM_FAILURE exception. This is my code. Thank you, Andrey bool InitFactory() { char tmp[256]; sprintf(tmp,"corbaloc:iiop:%s:2000/KeyOfMyServer",ssIP); CORBA::Object_var obj = orb->string_to_object(tmp); try { fref= SS::SubscriptionFactory::_narrow(obj); } catch(...){ return false; } if( CORBA::is_nil(fref) ) { //cerr << "Can't narrow reference to type SF (or it was nil)." << endl; return false; } return true; } -----Original Message----- From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com] Sent: Thursday, January 25, 2001 10:11 AM To: omniorb-list@uk.research.att.com Subject: Re: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? _narrow() may or may not have to contact the real object to determine whether the operation should succeed. The chapter on type checking in the omniORB user guide explains this in some detail. Since a remote invocation may be called as part of a _narrow, the full range of system exception may be reported. By the way, omniORB never needs to contact the server to do string_to_object. If you have some code that shows the contrary, please send it to me. Sai-Lai >>>>> Ilinykh, Andre writes: > There are others, for example COMM_FAILURE. _narrow() can check the type of > real object. I'm not sure when it does this way. At least, every time I > create object reference by string_to_object("corbaloc:iiop:/...") it goes to > my server. > Thanks, > Andrey > -----Original Message----- > From: ERIKSSON,TOBIAS (A-Sweden,ex1) > [mailto:tobias_eriksson@agilent.com] > Sent: Thursday, January 25, 2001 2:19 AM > To: omniorb-list@uk.research.att.com > Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() > and when? > Hi > I'm trying to use narrow to tell me if the type of the object beeing > narrowed actually is of the type I want, > I think that it will throw BAD_PARAM if they are not the same, is this > correct and are there any others? > Regards > Tobias -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From S.Lo@uk.research.att.com Thu Jan 25 19:16:09 2001 From: S.Lo@uk.research.att.com (Sai-Lai Lo) Date: 25 Jan 2001 19:16:09 +0000 Subject: [omniORB] Which exceptions can be thrown by a call to _narrow () and when? In-Reply-To: <8F4C99C66D04D4118F580090272A7A234F356E@sectorbase1.sectorbase.com> ("Ilinykh, Andre"'s message of "Thu, 25 Jan 2001 10:35:57 -0800") References: <8F4C99C66D04D4118F580090272A7A234F356E@sectorbase1.sectorbase.com> Message-ID: <3og0i7wih2.fsf@neem.uk.research.att.com> Your code just illustrates my point. The ORB does not have to contact the object in string_to_object. It has to in _narrow because there is no type information supplied in corbaloc. >>>>> Ilinykh, Andre writes: > We don't use NameService, I create object Factory using IP and port. > Every time server is down I get COMM_FAILURE exception. > This is my code. > bool InitFactory() > { > char tmp[256]; > sprintf(tmp,"corbaloc:iiop:%s:2000/KeyOfMyServer",ssIP); > CORBA::Object_var obj = orb->string_to_object(tmp); > try { > fref= SS::SubscriptionFactory::_narrow(obj); > } catch(...){ > return false; > } > if( CORBA::is_nil(fref) ) { > //cerr << "Can't narrow reference to type SF (or it was > nil)." << endl; > return false; > } > return true; > } > -----Original Message----- > From: Sai-Lai Lo [mailto:S.Lo@uk.research.att.com] > Sent: Thursday, January 25, 2001 10:11 AM > To: omniorb-list@uk.research.att.com > Subject: Re: [omniORB] Which exceptions can be thrown by a call to > _narrow () and when? > _narrow() may or may not have to contact the real object to determine > whether the operation should succeed. The chapter on type checking in the > omniORB user guide explains this in some detail. Since a remote invocation > may be called as part of a _narrow, the full range of system exception may > be reported. > By the way, omniORB never needs to contact the server to do > string_to_object. If you have some code that shows the contrary, please > send it to me. > Sai-Lai >>>>> Ilinykh, Andre writes: >> There are others, for example COMM_FAILURE. _narrow() can check the type > of >> real object. I'm not sure when it does this way. At least, every time I >> create object reference by string_to_object("corbaloc:iiop:/...") it goes > to >> my server. >> Thanks, >> Andrey >> -----Original Message----- >> From: ERIKSSON,TOBIAS (A-Sweden,ex1) >> [mailto:tobias_eriksson@agilent.com] >> Sent: Thursday, January 25, 2001 2:19 AM >> To: omniorb-list@uk.research.att.com >> Subject: [omniORB] Which exceptions can be thrown by a call to _narrow() >> and when? >> Hi >> I'm trying to use narrow to tell me if the type of the object beeing >> narrowed actually is of the type I want, >> I think that it will throw BAD_PARAM if they are not the same, is this >> correct and are there any others? >> Regards >> Tobias > -- > Sai-Lai Lo S.Lo@uk.research.att.com > AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com > 24a Trumpington Street Tel: +44 1223 343000 > Cambridge CB2 1QA Fax: +44 1223 313542 > ENGLAND -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND From mberry@mweb.co.za Fri Jan 26 06:21:32 2001 From: mberry@mweb.co.za (Matthew Berry) Date: Fri, 26 Jan 2001 08:21:32 +0200 Subject: [omniORB] FW: Exception problems Message-ID: Sorry, silly me left the new exception off the raises list. Working now. Thanks -----Original Message----- From: Matthew Berry [mailto:mberry@mweb.co.za] Sent: 19 January 2001 02:20 To: omniORB Subject: Exception problems Within my IDL file I have a number of exceptions defined, having added "unexpectedResult" this morning. .... // Exceptions exception dbOutputFailed {}; exception unknownProduct {}; exception undefinedError {}; exception unexpectedResult {}; In my server code, I am throw an exception like: throw CTP::unexpectedResult() but on my client I get a SystemException. I ORB trace from the server looks like: ll_send: 68 bytes 4749 4f50 0100 0101 3800 0000 0000 0000 GIOP....8....... 0200 0000 0200 0000 1e00 0000 4944 4c3a ............IDL: 6f6d 672e 6f72 672f 434f 5242 412f 554e omg.org/CORBA/UN 4b4e 4f57 4e3a 312e 3000 0000 0000 0000 KNOWN:1.0....... 0200 0000 .... If I change the line to throw CTP::undefinedError() Everthing works fine, the tracing being ll_send: 68 bytes 4749 4f50 0100 0101 3800 0000 0000 0000 GIOP....8....... 0200 0000 0100 0000 2800 0000 4944 4c3a ........(...IDL: 6272 6f6e 6572 2e63 6f2e 756b 2f43 5450 broner.co.uk/CTP 2f75 6e64 6566 696e 6564 4572 726f 723a /undefinedError: 312e 3000 1.0. I tried renaming "unexpectedResult" to "badAnswerFromON" and I still get the SystemException. Any ideas on what's/where I am going wrong. Configuration: 2.80 / RH 6.2 / gcc 2.91.66 From dignac@ftw.rsc.raytheon.com Thu Jan 25 21:16:57 2001 From: dignac@ftw.rsc.raytheon.com (Demron Ignace) Date: Thu, 25 Jan 2001 16:16:57 -0500 Subject: [omniORB] Omniorb 3.0.2 and MFC Message-ID: <052569DF.0074E631.00@notesmail.ftw.rsc.raytheon.com> I am having a serious problems with threads created in the CORBA layer executing MFC calls in my implementation class. Does OmniOrb make use of MFC threads? From steve.brenneis@attws.com Fri Jan 26 13:10:45 2001 From: steve.brenneis@attws.com (Brenneis, Steve) Date: Fri, 26 Jan 2001 08:10:45 -0500 Subject: [omniORB] Omniorb 3.0.2 and MFC Message-ID: omniORB uses its own threads library which is based on either POSIX threads (on Unix flavors and VMS) or Win32 threads (on Windows). omniThreads is as close to bullet-proof as I've seen. In most cases you cannot access or execute MFC code or resources from omniThreads. In some instances, you can invoke a macro (used to be AfxManageThreadState, maybe still is) upon entry into a section of MFC thread code and it would survive the close encounter. This doesn't always work and the rules under which it does work seem to be governed by phases of the moon or some other Microsoft arcana. In fact, most MFC threads can't access or execute other MFC threads or their resources. If you need an MFC thread (especially one which has a window)to act upon something going on in an omniThread, it is usally best to use PostMessage or even PostThreadMessage (if that one is still around). Don't use SendMessage since the recipient processing is done within the same thread. All MFC threads have an idle processing loop and the thread will process the message when it gets to it. omnniORB does not use MFC threads. Those of us who have used omniORB on MS-Windows really appreciate that and hope it will never change. Hope this helps. -----Original Message----- From: Demron Ignace [mailto:dignac@ftw.rsc.raytheon.com] Sent: Thursday, January 25, 2001 4:17 PM To: omniorb-list@uk.research.att.com Subject: [omniORB] Omniorb 3.0.2 and MFC I am having a serious problems with threads created in the CORBA layer executing MFC calls in my implementation class. Does OmniOrb make use of MFC threads? From dgrisby@uk.research.att.com Fri Jan 26 15:25:29 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Fri, 26 Jan 2001 15:25:29 +0000 Subject: [omniORB] packaging omniorb In-Reply-To: Message from Pinchak Stanley of "Tue, 23 Jan 2001 21:20:39 PST." <20010124052039.39855.qmail@web12211.mail.yahoo.com> Message-ID: <200101261525.PAA19938@pineapple.uk.research.att.com> On Tuesday 23 January, Pinchak Stanley wrote: > Hi my name is Stanley Pinchak and I would like to > create a debian package of omniorb 3.0.2. [...] Great! The best starting point is probably the RPMs which Sander Steffann and Jared Peterson have been working on. If the Debian packages can follow the same basic layout, that will make things nicer for people using more than one Linux distribution. Jared's RPMs are available from http://www.tgflinux.com/omni/ I haven't got around to testing the latest versions yet, so there may be a few problems with them. RedHat users could also give them a go, and let us know if they work. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From count0@building2.co.jp Fri Jan 26 18:18:13 2001 From: count0@building2.co.jp (Huw Rogers) Date: Sat, 27 Jan 2001 03:18:13 +0900 Subject: clean shutdown on signal (was Re: shutdown() SEGVs (was Re: [omniORB] atexit, exit, _exit, and ORB::destroy())) References: <200012041043.KAA07951@pineapple.uk.research.att.com> <3A5FDC3C.4B6BAD5A@building2.co.jp> Message-ID: <3A71BF65.5FD0A655@building2.co.jp> Summary: don't call shutdown() from within a signal handler under Linux. Well this cost me several days, but I figured it out. It's a wierd problem with LinuxThreads and signals. Hope this helps someone else out there. It might be a good idea to note this somewhere in the documentation even though it's totally platform specific. All pthread_* functions are unsafe to be called from within signal handlers under Linux, and can apparently cause memory corruption within the LinuxThreads library if you do so. The only permissible thing to do in a signal handler is sem_post(), and have a thread waiting on the same semaphore (from the LinuxThreads FAQ, doh). So you can't call shutdown() directly from a signal handler under Linux, and neither can you create a thread to call shutdown() in the handler. You have to do that before- hand and have it wait on a semaphore until the time comes. So in main(): sem_init(...) pthread_create(...) // the dedicated finalization thread sigaction(...) // the signal handler orb->run() // woken up by the finalization thread calling shutdown() orb->destroy() _exit(code) in the signal handler for SIGINT/SIGTERM: sem_post(...) // wake up the finalization thread ... and in the finalization thread: sem_wait(...) // wait to die orb->shutdown(!0) return(0) Cue weary sigh... -Huw > From rgruet@intraware.com Fri Jan 26 17:37:32 2001 From: rgruet@intraware.com (Richard Gruet) Date: Fri, 26 Jan 2001 09:37:32 -0800 Subject: [omniORB] Omnipy binaries compatible with Python 2.0 ? Message-ID: <3A71B5DB.203C0E4A@intraware.com> Hi, I'm looking for a release of the Omnipy binaries that would be compatible with Python 2.0. It seems not to exist so far. When will it be available on the Omniorb site ? Cheers -- Richard Gruet -- Sr Application Architect Intraware, Inc. Mailto:rgruet@intraware.com http://www.intraware.com Voice: (001) 925-253-6512 Fax: (001) 925-253-4599 From lesha12@hotmail.com Sat Jan 27 01:12:03 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Sat, 27 Jan 2001 04:12:03 +0300 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 Message-ID: Hello, I've lost hope to compile omniORB_3.0.2 under Solaris2.6 using gcc2.95.2. I get the following message during ompillation: ====================================================================== ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 -ComniORB3 ../../../idl/Naming.idl omniidl: ERROR! omniidl: Could not open IDL compiler module _omniidlmodule.so omniidl: Please make sure it is in directory /usr/local/omni/lib/sun4_sosV_5.6 omniidl: (or set the PYTHONPATH environment variable) omniidl: (The error was `ld.so.1: python: fatal: libstdc++.so.2.10.0: open failed: No such file or directory') ======================================================================== Could someone explain me how I can avoid this problem, PLEASE. Thank you in advance. Regards, Aleksey. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From marc@factoriaX.com Sat Jan 27 16:44:58 2001 From: marc@factoriaX.com (Marc Ordinas i Llopis) Date: Sat, 27 Jan 2001 11:44:58 -0500 Subject: [omniORB] Problems compiling omni4_0_develop References: <3A6F0207.1050105@factoriaX.com> <3owvbjwx5j.fsf@neem.uk.research.att.com> Message-ID: <3A72FB0A.2090108@factoriaX.com> Sai-Lai Lo wrote: > The omni4_0_develop branch should now compile. Apart from some missing > GNUmakefiles, I have to make some changes to the cxx backend to fix the > error you've seen. Its interesting that the backend problem only occurs > when omniidl is given a relative path name as the -p option. > > I suggest you do a fresh cvs checkout. I'm not 100% sure a cvs update will > pick up the changes in directory names etc. Thanks, I got it to start compiling. Unfortunately, it dies like this: /usr/bin/g++ -c -O2 -Wall -Wno-unused -I.. -D_REENTRANT -DUSE_omniORB_logStream -D_OMNIORB_LIBRARY -DCONFIG_DEFAULT_LOCATION='"/etc/omniORB.cfg"' -DUnixArchitecture -I. -I../../../../include -D__x86__ -D__linux__ -D__OSVERSION__=2 -o static/bootstrapstub.o bootstrapstub.cc In file included from bootstrapstub.cc:31: ../omniORB4/bootstrapSK.cc: In method `void _0RL_cd_96f078e2247ab9da_20000000::marshalReturnedValues (cdrStream &)': ../omniORB4/bootstrapSK.cc:164: Internal error: Segmentation fault. Please submit a full bug report. See for instructions. But I'm pretty sure this is just the compiler in RH7, known for its helpful error messages... I'll keep trying and tell you if I get any further, although I'm afraid I'll have to wait until the next gcc release. By the way, may I ask which development environment do you develop omniORB 4 on? Thanks again, Marc Ordinas i Llopis factoriaX From rodrigc@mediaone.net Sat Jan 27 15:17:29 2001 From: rodrigc@mediaone.net (Craig Rodrigues) Date: Sat, 27 Jan 2001 10:17:29 -0500 Subject: [omniORB] Problems compiling omni4_0_develop In-Reply-To: <3A72FB0A.2090108@factoriaX.com>; from marc@factoriaX.com on Sat, Jan 27, 2001 at 11:44:58AM -0500 References: <3A6F0207.1050105@factoriaX.com> <3owvbjwx5j.fsf@neem.uk.research.att.com> <3A72FB0A.2090108@factoriaX.com> Message-ID: <20010127101729.A13220@mediaone.net> On Sat, Jan 27, 2001 at 11:44:58AM -0500, Marc Ordinas i Llopis wrote: > _0RL_cd_96f078e2247ab9da_20000000::marshalReturnedValues (cdrStream &)': > ../omniORB4/bootstrapSK.cc:164: Internal error: Segmentation fault. > Please submit a full bug report. > See for instructions. > > But I'm pretty sure this is just the compiler in RH7, known for its Yikes, RH 7. I've been trying to avoid that version since Redhat threw in beta release of gcc in that distribution. You should do: rpm -q gcc gcc-c++ cpp libstdc++ libstdc++-devel and then go to ftp://rawhide.redhat.com/pub/rawhide/i386/RedHat/ and see if there are newer versions of those rpm's that fix your compiler bug. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From dek_ml@konerding.com Sat Jan 27 17:56:19 2001 From: dek_ml@konerding.com (dek_ml@konerding.com) Date: Sat, 27 Jan 2001 09:56:19 -0800 Subject: [omniORB] Problems compiling omni4_0_develop In-Reply-To: Your message of "Sat, 27 Jan 2001 10:17:29 EST." <20010127101729.A13220@mediaone.net> Message-ID: <200101271756.JAA09936@konerding.com> Craig Rodrigues writes: >On Sat, Jan 27, 2001 at 11:44:58AM -0500, Marc Ordinas i Llopis wrote: >> _0RL_cd_96f078e2247ab9da_20000000::marshalReturnedValues (cdrStream &)': >> ../omniORB4/bootstrapSK.cc:164: Internal error: Segmentation fault. >> Please submit a full bug report. >> See for instructions. >> >> But I'm pretty sure this is just the compiler in RH7, known for its > >Yikes, RH 7. I've been trying to avoid that version since Redhat threw in >beta release of gcc in that distribution. You should do: >rpm -q gcc gcc-c++ cpp libstdc++ libstdc++-devel Yes. Don't attempt to develop on RH7. Instead, use Red Hat 6.2, with gcc/g++ 2.95.2, and if you really need a standard C++, use STLport-4.0. Wait until Red Hat gets their act together in 7.1 or 7.2 before switching over. Dave From tororoland@freemail.hu Sun Jan 28 16:27:05 2001 From: tororoland@freemail.hu (T|r� Roland) Date: Sun, 28 Jan 2001 17:27:05 +0100 (CET) Subject: [omniORB] Corba-COM bridge Message-ID: hi i use windows nt4 with visual c++6 i made a com dll that is called by a corba client and the server is a vb application that is calling my dll with the COM interface the problem is if i call a service form my corba client the dll gets the control and the corba service is running but in the function witch is called my corba client is a Fire_ event /because i have to reach the vb side/ and at this point the corba core is crasing it is crashing in the giopServer.cc at line 728 catch(...) { if( omniORB::traceLevel > 1 ) { omniORB::logger l; l << "WARNING -- method \'" << operation() << "\' raised an unexpected\n" " exception (not a CORBA exception).\n"; } CORBA::UNKNOWN ex(0, CORBA::COMPLETED_MAYBE); CHECK_AND_MAYBE_MARSHALL_SYSTEM_EXCEPTION (UNKNOWN,ex); } anyone has an idea what can be the solutoin? From davidh@cavendish.co.uk Mon Jan 29 08:29:32 2001 From: davidh@cavendish.co.uk (David Hyde) Date: Mon, 29 Jan 2001 08:29:32 -0000 Subject: [omniORB] Corba-COM bridge Message-ID: <31C9EC5EF9CAD111981300805F06666028B229@phantom.cavendish.co.uk> If I understand you correctly what you are saying is that you are = having problems when a callback comes into your COM control from CORBA and you = have to pass it back to the front end as an event. The problem is that apartment threaded objects have to fire events off = their main threads only and the CORBA call is entering your control on a = seperate thread. You have to marshall the object's reference using CoMarshalInterThreadInterfaceInStream and then unmarshall it with CoGetInterfaceAndReleaseStream when the event comes in. You then use = the unmarshalled pointer to fire the events. MSDN and VC++ newsgroups have examples of doing this. Regards David -----Original Message----- From: T|r=F5" Roland [mailto:tororoland@freemail.hu] Sent: Sunday, January 28, 2001 4:27 PM To: omniorb-list@uk.research.att.com Subject: [omniORB] Corba-COM bridge hi=20 i use windows nt4 with visual c++6=20 i made a com dll that is called by a corba client and the=20 server is a vb application that is calling my dll with the=20 COM interface the problem is if i call a service form my corba client the=20 dll gets the control and the corba service is running but=20 in the function witch is called my corba client is a Fire_ event /because i have to reach the vb side/ and at this=20 point the corba core is crasing=20 it is crashing in the giopServer.cc=20 at line 728 catch(...) { if( omniORB::traceLevel > 1 ) { omniORB::logger l; l << "WARNING -- method \'" << operation() << "\'=20 raised an unexpected\n" " exception (not a CORBA exception).\n"; } CORBA::UNKNOWN ex(0, CORBA::COMPLETED_MAYBE); CHECK_AND_MAYBE_MARSHALL_SYSTEM_EXCEPTION (UNKNOWN,ex); } anyone has an idea what can be the solutoin? From tolaini@libero.it Mon Jan 29 10:54:12 2001 From: tolaini@libero.it (Sandro Tolaini) Date: Mon, 29 Jan 2001 11:54:12 +0100 Subject: [omniORB] Multiple profiles Message-ID: <005f01c089e1$d1d332a0$2c01010a@psitrust.com> Can someone clarify what are the standard actions took by omniORB when multiple profiles are specified in an IOR? I'd like to use a corbaloc URI with multiple profiles in order to connect to the first available server, but it seems that omniORB only tries the first profile. Also, is there a way to reconnect to another profile if the initial server goes down? Cheers, Sandro Tolaini From dgrisby@uk.research.att.com Mon Jan 29 11:35:19 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 11:35:19 +0000 Subject: [omniORB] problem with insPOA and Factory object In-Reply-To: Message from =?iso-8859-1?Q?Juan_Carlos_Coru=F1a?= of "Tue, 23 Jan 2001 09:45:00 +0100." Message-ID: <200101291135.LAA08687@pineapple.uk.research.att.com> On Tuesday 23 January, =?iso-8859-1?Q?Juan_Carlos_Coru=F1a?= wrote: > I try to implement a Factory object to create instances of another > object, but without success. [...] > class MQ_Factory_i(MQ_module__POA.MQ_Factory): > def create_MQ(self): > print 'creating MQ' > mq = MQ_class_i() > return mq._this() [...] > The problem appears here in the last line ("session = > mq_jcoruna.Login('jcoruna')"). The system doesn't return any value and > waits until timeout. The system works correctly without the Factory. The problem is that your MQ_class object has been activated in the Root POA, because of the implicit activation on the call to _this(). You haven't activated the Root POA, so requests to the MQ_class object are blocked. That is why implicit activation is evil. It is better to explicitly activate your objects in the POA you want them in, and avoid the use of _this(). Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 29 11:39:01 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 11:39:01 +0000 Subject: [omniORB] Omnipy binaries compatible with Python 2.0 ? In-Reply-To: Message from "Richard Gruet" of "Fri, 26 Jan 2001 09:37:32 PST." <3A71B5DB.203C0E4A@intraware.com> Message-ID: <200101291139.LAA08742@pineapple.uk.research.att.com> On Friday 26 January, "Richard Gruet" wrote: > I'm looking for a release of the Omnipy binaries that would be > compatible with Python 2.0. > It seems not to exist so far. When will it be available on the Omniorb > site ? In the next release, which should be soon, there will be binaries for 2.0 as well as 1.5.2. I can't be more specific than that, I'm afraid. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 29 11:40:25 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 11:40:25 +0000 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 In-Reply-To: Message from "Aleksey Varzhel" of "Sat, 27 Jan 2001 04:12:03 +0300." Message-ID: <200101291140.LAA08760@pineapple.uk.research.att.com> On Saturday 27 January, "Aleksey Varzhel" wrote: > I've lost hope to compile omniORB_3.0.2 under Solaris2.6 using gcc2.95.2. > I get the following message during ompillation: [...] > omniidl: (The error was `ld.so.1: python: fatal: libstdc++.so.2.10.0: open > failed: No such file or directory') You need to set LD_LIBRARY_PATH to point to the lib directory of wherever you installed gcc, so it can find libstdc++. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From steve.brenneis@attws.com Mon Jan 29 13:10:06 2001 From: steve.brenneis@attws.com (Brenneis, Steve) Date: Mon, 29 Jan 2001 08:10:06 -0500 Subject: [omniORB] JDC Bug 4385162, fixed! Message-ID: Apparently all the pleading and begging worked. Has anyone tried the fix? Does it work? Steve Brenneis Developer-II AT&T Wireless Desk: (336) 286-1783 Cell: (336) 456-3290 Fax: (336) 286-1880 Steve.Brenneis@attws.com "You can tune a piano, but you can't tuna fish" -- Groucho Marx From dgrisby@uk.research.att.com Mon Jan 29 14:04:05 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 14:04:05 +0000 Subject: [omniORB] JDC Bug 4385162, fixed! In-Reply-To: Message from "Brenneis, Steve" of "Mon, 29 Jan 2001 08:10:06 EST." Message-ID: <200101291404.OAA09428@pineapple.uk.research.att.com> On Monday 29 January, "Brenneis, Steve" wrote: > Apparently all the pleading and begging worked. Has anyone tried the fix? > Does it work? I'm afraid to say that that isn't actually the bug affecting use of omniNames. It has to do with code set negotiation, which omniORB 3 doesn't support. The bug would have affected interoperability with omniORB 4, though. The object key length bug is still closed, marked "not a bug". Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From bglenden@cv3.cv.nrao.edu Mon Jan 29 15:27:47 2001 From: bglenden@cv3.cv.nrao.edu (Brian Glendenning) Date: Mon, 29 Jan 2001 08:27:47 -0700 Subject: [omniORB] omniORBpy and Python 2.0 References: <200101291404.OAA09428@pineapple.uk.research.att.com> Message-ID: <003201c08a08$0f3cace0$e8015892@aoc.nrao.edu> I hope this question isn't in some FAQ I couldn't find! Does the current release work with Python 2.0? Also, is this list available in digest form? Regards, Brian Glendenning From djs@uk.research.att.com Mon Jan 29 15:32:07 2001 From: djs@uk.research.att.com (David Scott) Date: Mon, 29 Jan 2001 15:32:07 +0000 (GMT) Subject: [omniORB] Internal Exception while compiling IDL file In-Reply-To: <20001220021243.A29325@mips.biochem.mpg.de> Message-ID: On Wed, 20 Dec 2000, Gnana wrote: > I am trying to compile a huge IDL file with omniidl > and this is what i get. > > [internal exception in omniIDL's C++ backend] > Hi, Sorry for the delay fixing this problem. It turned out that there was a nasty bug in the C++ backend's scoped name handling code which would only surface when you write IDL like: interface I{}; module M{ interface I: ::I{}; interface I2: I{}; }; I've committed a bugfix to the omni3_develop branch-- it should be available on the external CVS server tomorrow. Let me know if there are any problems with it. HTH! -- Dave Scott From dgrisby@uk.research.att.com Mon Jan 29 15:46:34 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 15:46:34 +0000 Subject: [omniORB] omniORBpy and Python 2.0 In-Reply-To: Message from "Brian Glendenning" of "Mon, 29 Jan 2001 08:27:47 MST." <003201c08a08$0f3cace0$e8015892@aoc.nrao.edu> Message-ID: <200101291546.PAA10200@pineapple.uk.research.att.com> On Monday 29 January, "Brian Glendenning" wrote: > Does the current release work with Python 2.0? Yes, but the binaries we distribute do not work with anything but 1.5.2. If you recompile for Python 2.0, it works fine. > Also, is this list available in digest form? Yes. Send mail to majordomo@uk.research.att.com with a body of subscribe omniorb-list-digest For some reason, this information isn't on our in-touch page. I'll add it... Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From jnye@micro-optics.com Mon Jan 29 14:53:53 2001 From: jnye@micro-optics.com (jnye@micro-optics.com) Date: Mon, 29 Jan 2001 10:53:53 -0400 Subject: [omniORB] Persistent Objects Question Message-ID: <388331E016F0D411A9F000A0C9DB1BC511BD0B@GATEWAY> Hi All, I'm not sure if this is an omni-specific question, or if this is just a misunderstading I have with persistent references. To start off, here is my understanding of how persistent references work: Persistent references outlive the process in which the objects they refer to live. This means that theoretically, I should be able to create a persistent object reference, write it to disk in some registry at software installation time and it should never have to be updated (unless the server code changes somehow and even then, I'm not sure if it should change if the interface did not change). My Goal: I'm kind of adopting COM's installation method where If I want CORBA objects to reside in Dlls, their Dlls will get registered in the system with an exported DllRegisterServer and servers in executables will use a command line switch of /regserver to install themselves -> this will result in a persistent IOR being written to some globally accessible registration database or file. When the server executables are run with the /regserver command line option, they register themselves then simply exit. My Problem: The infrastructure is all set up, the only problem that I am having now is setting up a persistent reference. I run my test server exe as myobject.exe /regserver It indeed registers an IOR in a registration database, but when clients attempt to use the IOR, they get a COMM_FAILURE exception. If I change the myobject code to register the IOR each time it is started (which is undesirable), clients can access the server with no problem. In other words, the server's IOR is not persistent for some reason. My Code: I've included the main program for the server which creates a child POA with the persistent and user id assignment policies, then calls create_reference_with_id on that child POA with an id that I created using string_to_ObjectId. I would expect for that reference to be the same each time since it is persistent. Not so -- clients can't use it across server restarts, either. Can someone review my code and tell me what I am doing wrong? TIA, Jason //////// Code //////////////////////////////////////////////////////////////// int main(int argc, char * argv) { try { namespace PS = PortableServer; // Easier to read!! // Initialize the orb CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Get reference to Root POA CORBA::Object_var obj = orb->resolve_initial_references("RootPOA"); PS::POA_var poa = PS::POA::_narrow(obj); // Activate POA manager PS::POAManager_var mgr = poa->the_POAManager(); PS::LifespanPolicy_var lifespan = poa->create_lifespan_policy(PS::PERSISTENT); PS::IdAssignmentPolicy_var assign = poa->create_id_assignment_policy(PS::USER_ID); CORBA::PolicyList poaPolicyList; poaPolicyList.length(2); poaPolicyList[0] = PS::LifespanPolicy::_duplicate(lifespan); poaPolicyList[1] = PS::IdAssignmentPolicy::_duplicate(assign); PS::POA_var childPOA = poa->create_POA("MyObjectPOA", mgr, poaPolicyList); lifespan->destroy(); assign->destroy(); MyObjectImpl servant; PS::ObjectId_var oid = PS::string_to_ObjectId("MyObject"); // Just register and exit. if (findCmdLineArg(argc, argv, "/RegServer")) { // Object registration/unregistration. try { CORBA::Object_var ref = childPOA->create_reference_with_id(oid, "IDL:MyObject:1.0"); CORBA::String_var ior = orb->object_to_string(ref); // Simply writes a reference to a globally accessable registration file in the form: // // MyObject=IOR:..... // ObjectRegistrar::registerIOR("MyObject", (const char *)ior); } catch (...) { ::MessageBox(0, "Failed to register IOR", "MyObject", 0); return -1; } } else { // Normal execution of server. mgr->activate(); // Activate object. childPOA->activate_object_with_id(oid, &servant); orb->run(); } } catch(const CORBA::Exception &e ) { int size; cout << e._NP_repoId(&size) << endl; return -1; } return 0; } From lesha12@hotmail.com Mon Jan 29 17:20:24 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Mon, 29 Jan 2001 20:20:24 +0300 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 Message-ID: Hello, Thanks for help. That error has gone. However now I have an another failure at the same place. I tried to recompile python but it did not help. ====================================================================== ../../../bin/sun4_sosV_5.6/omniidl -bcxx -Wba -p../../../src/lib/omniORB2 -ComniORB3 ../../../idl/Naming.idl omniidl: ERROR! omniidl: Could not open IDL compiler module _omniidlmodule.so omniidl: Please make sure it is in directory /usr/local/omni/lib/sun4_sosV_5.6 omniidl: (or set the PYTHONPATH environment variable) omniidl: (The error was `ld.so.1: python: fatal: relocation error: file /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol _Py_NoneStruct: referenced symbol not found') gmake[2]: *** [omniORB3/Naming.hh] Error 1 gmake[2]: Leaving directory `/usr/local/omni/src/lib/omniORB2' gmake[1]: *** [export] Error 2 gmake[1]: Leaving directory `/usr/local/omni/src/lib' gmake: *** [export] Error 2 ====================================================================== I would be very grateful if could help me with this issue. Thank you. Best regards, Aleksey. >From: Duncan Grisby >To: "Aleksey Varzhel" >CC: omniorb-list@uk.research.att.com >Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 >Date: Mon, 29 Jan 2001 11:40:25 +0000 > >On Saturday 27 January, "Aleksey Varzhel" wrote: > > > I've lost hope to compile omniORB_3.0.2 under Solaris2.6 using >gcc2.95.2. > > I get the following message during ompillation: > >[...] > > omniidl: (The error was `ld.so.1: python: fatal: libstdc++.so.2.10.0: >open > > failed: No such file or directory') > >You need to set LD_LIBRARY_PATH to point to the lib directory of >wherever you installed gcc, so it can find libstdc++. > >Cheers, > >Duncan. > >-- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From jnye@micro-optics.com Mon Jan 29 17:49:29 2001 From: jnye@micro-optics.com (jnye@micro-optics.com) Date: Mon, 29 Jan 2001 13:49:29 -0400 Subject: [omniORB] Persistent Objects Question Message-ID: <388331E016F0D411A9F000A0C9DB1BC511BD0C@GATEWAY> Hi David, Nope, that was just a typo -- my program actually has a WinMain and I just threw in main for the purposes of the email. Thanks anyway, Jason. -----Original Message----- From: David Byron [mailto:dbyron@coactive.com] Sent: Monday, January 29, 2001 1:40 PM To: 'jnye@micro-optics.com' Subject: RE: [omniORB] Persistent Objects Question I doubt this is it, and I haven't looked closely at your code, but argv is usually declarded as (char **argv) or (char *argv[]). Maybe it will have some effect. -DB > int main(int argc, char * argv) > { > try > { > namespace PS = PortableServer; // Easier to read!! > > // Initialize the orb > CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); > > // Get reference to Root POA > CORBA::Object_var obj = > orb->resolve_initial_references("RootPOA"); > PS::POA_var poa = PS::POA::_narrow(obj); > > // Activate POA manager > PS::POAManager_var mgr = poa->the_POAManager(); > > PS::LifespanPolicy_var lifespan = > poa->create_lifespan_policy(PS::PERSISTENT); > PS::IdAssignmentPolicy_var assign = > poa->create_id_assignment_policy(PS::USER_ID); > > CORBA::PolicyList poaPolicyList; > poaPolicyList.length(2); > poaPolicyList[0] = PS::LifespanPolicy::_duplicate(lifespan); > poaPolicyList[1] = PS::IdAssignmentPolicy::_duplicate(assign); > > PS::POA_var childPOA = poa->create_POA("MyObjectPOA", mgr, > poaPolicyList); > lifespan->destroy(); > assign->destroy(); > > MyObjectImpl servant; > PS::ObjectId_var oid = PS::string_to_ObjectId("MyObject"); > > // Just register and exit. > if (findCmdLineArg(argc, argv, "/RegServer")) > { > // Object registration/unregistration. > try > { > CORBA::Object_var ref = > childPOA->create_reference_with_id(oid, "IDL:MyObject:1.0"); > CORBA::String_var ior = orb->object_to_string(ref); > > // Simply writes a reference to a globally accessable > registration file in the form: > // > // MyObject=IOR:..... > // > ObjectRegistrar::registerIOR("MyObject", > (const char *)ior); > } > catch (...) > { > ::MessageBox(0, "Failed to register IOR", > "MyObject", 0); > return -1; > } > } > else > { > // Normal execution of server. > mgr->activate(); > > // Activate object. > childPOA->activate_object_with_id(oid, &servant); > orb->run(); > } > } > catch(const CORBA::Exception &e ) > { > int size; > cout << e._NP_repoId(&size) << endl; > return -1; > } > > return 0; > } From dgrisby@uk.research.att.com Mon Jan 29 17:56:33 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 17:56:33 +0000 Subject: [omniORB] Persistent Objects Question In-Reply-To: Message from jnye@micro-optics.com of "Mon, 29 Jan 2001 10:53:53 -0400." <388331E016F0D411A9F000A0C9DB1BC511BD0B@GATEWAY> Message-ID: <200101291756.RAA14014@pineapple.uk.research.att.com> On Monday 29 January, jnye@micro-optics.com wrote: [...] > It indeed registers an IOR in a registration database, but when clients > attempt to use the IOR, they get a COMM_FAILURE exception. If I change the > myobject code to register the IOR each time it is started (which is > undesirable), clients can access the server with no problem. In other words, > the server's IOR is not persistent for some reason. It looks like your code is doing all the right things, with one important omission. You have to make sure that the server listens on the same TCP port every time it starts up. To do that, use the -ORBpoa_iiop_port command line argument. Your program can insert the argument so it doesn't actually have to be on the command line. See the omniNames or omniMapper source for how to do that. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From dgrisby@uk.research.att.com Mon Jan 29 17:59:32 2001 From: dgrisby@uk.research.att.com (Duncan Grisby) Date: Mon, 29 Jan 2001 17:59:32 +0000 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 In-Reply-To: Message from "Aleksey Varzhel" of "Mon, 29 Jan 2001 20:20:24 +0300." Message-ID: <200101291759.RAA14038@pineapple.uk.research.att.com> On Monday 29 January, "Aleksey Varzhel" wrote: > omniidl: (The error was `ld.so.1: python: fatal: relocation error: file > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol _Py_NoneStruct: > referenced symbol not found') That normally happens when you try to use the _omniidl library with a different version of Python to the one it was compiled against. Make sure that the "python" on your path is the same version of Python as the one specified in the mk/platforms/sun4_sosV_5.6.mk file. Alternatively, have you stripped your python executable? If so, the symbols in it won't be available to the omniidl extension. Cheers, Duncan. -- -- Duncan Grisby \ Research Engineer -- -- AT&T Laboratories Cambridge -- -- http://www.uk.research.att.com/~dpg1 -- From lesha12@hotmail.com Mon Jan 29 18:27:03 2001 From: lesha12@hotmail.com (Aleksey Varzhel) Date: Mon, 29 Jan 2001 10:27:03 -0800 Subject: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 References: <200101291759.RAA14038@pineapple.uk.research.att.com> Message-ID: I have compiled Python 1.5.2 and the file mk/platforms/sun4_sosV_5.6.mk contains a link to /usr/local/bin/python. Regarding "stripping" my python executable I am not sure what it is. I'm not familiar with Python and I've installed it to support omniORB only. Could you advise how I can check if it was stripped ? Thank you. ----- Original Message ----- From: "Duncan Grisby" To: "Aleksey Varzhel" Cc: Sent: Monday, January 29, 2001 9:59 AM Subject: Re: [omniORB] Compilation problem gcc2.95.2 omni3.0.2 Solaris2.6 > On Monday 29 January, "Aleksey Varzhel" wrote: > > > omniidl: (The error was `ld.so.1: python: fatal: relocation error: file > > /usr/local/omni/lib/sun4_sosV_5.6/_omniidlmodule.so: symbol _Py_NoneStruct: > > referenced symbol not found') > > That normally happens when you try to use the _omniidl library with a > different version of Python to the one it was compiled against. Make > sure that the "python" on your path is the same version of Python as > the one specified in the mk/platforms/sun4_sosV_5.6.mk file. > > Alternatively, have you stripped your python executable? If so, the > symbols in it won't be available to the omniidl extension. > > Cheers, > > Duncan. > > -- > -- Duncan Grisby \ Research Engineer -- > -- AT&T Laboratories Cambridge -- > -- http://www.uk.research.att.com/~dpg1 -- > > From ghickey@northplains.com Mon Jan 29 20:17:33 2001 From: ghickey@northplains.com (Grant Hickey) Date: Mon, 29 Jan 2001 15:17:33 -0500 Subject: [omniORB] Character Encoding Message-ID: Our company is using Omniorb on multiple platforms (Sun, Windows NT, Mac). We are having some character encoding problems. -Does Corba provide any character encoding across platforms? -Are there any hooks into omniorb which would allow us to encode everything sent across the wire into unicode? Grant Hickey North Plains Systems From MKeay@SeeBeyond.com Mon Jan 29 21:17:33 2001 From: MKeay@SeeBeyond.com (Michael Keay) Date: Mon, 29 Jan 2001 13:17:33 -0800 Subject: [omniORB] argv processing Message-ID: <9B85913BDA568742B72DAF6DF54ECBC60159CC78@mail01.stc.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08A38.E50F4A00 Content-Type: text/plain; charset="iso-8859-1" Can someone explain why argv processing for -ORB parameters when calling ORB_init starts at argv[1] when there seems no reason for it to start at argv[0]? ------_=_NextPart_001_01C08A38.E50F4A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable argv processing

Can someone explain why argv = processing for -ORB parameters when calling ORB_init starts at argv[1] = when there seems no reason for it to start at argv[0]?

-----Original Message-----
From: Michael Keay [mailto:MKeay@SeeBeyond.com]
Sent: Monday, January 29, 2001 3:15 PM
To: Omniorb-List@Uk. Research. Att. Com (E-mail)
Subject: [omniORB] Date: Mon, 29 Jan 2001 15:13:57 -0800

I have been having a lot of trouble recently with OmniOrb on NT. The project I was working was trying to use the DLL version of the libraries. When ever I invoked a method on an object I received a COMM_FAILURE exception. After 2 weeks of looking into this, the guys who produced this thrid party object said there is an issue with the DLL versions and that I should use a static libraries. What is the issue here first of all.

Now to the issue I currently have. I am now using the static libraries and everytime on ORB_init, I get a windows system exception, Access Violation. Has anyone else experienced this issue, and what is the solution, if theire is a solution to this problem?