knemeyer@ix.netcom.com<= /DIV>

I have = installed the=20 Windows-95 binary release of version 2.6.0

and rebuilt the = echo examples=20 (only) with MSC++ 6 + Patchkit 1 and

gnu-win32-lite. The=20 rebuilt example eg1 runs=20 successfully,

eg2's IOR argument exceeds the DOS window cmd line length=20 limit,

and eg3 fails in trying to = contact the=20 naming service.

The = environment =20 variable OMNIORB2_CONFIG is set to the filepath

of the configuration file (added after = initial=20 failures) which

contains:

NAMESERVICE IOR:. . = .

ORBInitialHost = localhost

ORBInitialPort = 12345

Registry also contains the = above 3 values;=20 the IOR has been checked

against the nameservice.exe = startup=20 message; localhost is the only

entry in the \WINDOWS\Hosts = file; the=20 system was rebooted.

omninames (not rebuilt) is running: Checkpointing=20 completed.

eg3_impl = started, then=20 eg3_clt started (in DOS windows).

After some delay = ...

eg3_impl: Caught system = exception=20 COMM_FAILURE, unable to contact the naming service.

eg3_clt: Caught = system=20 exception COMM_FAILURE, unable to contact the naming service.
hello: = cannot=20 invoke on a nil object reference.

omninames is = still=20 running.

------=_NextPart_000_0000_01BE35FF.AFAC7480-- From Hugo.Vandeputte@meteo.fr Mon Jan 4 11:44:58 1999 From: Hugo.Vandeputte@meteo.fr (Hugo.Vandeputte) Date: Mon, 04 Jan 1999 12:44:58 +0100 Subject: [omniORB] Instantiating objects within (an initially) non executing server References: <199812311311.IAA16648@lion.gte.com> Message-ID: <3690A9BA.71FAB17D@meteo.fr> Gary D. Duzan wrote: > > The short answer is that no, this functionality is not available out > of the box. I believe there are hooks that can let you write a bit of > code to activate the object yourself, but that's it. > > Gary Duzan > GTE Laboratories I am actually working on an example and testsuite on load balancing and server starting on omniOrb (on unix). It's maybe not the better solution,but I hope it could help someone. First release in one or two weeks... Regards. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ H.Vandeputte o o o SCEM/TTI/DEV o o o mailto:Hugo.Vandeputte@meteo.fr _____ _ o __/_ Tel: 05.61.07.81.91 (_____)/ \ /o \/| _____/ ___ _// >____/\| _/_______/ ___/ / / /_/ /_/ ____________________________________________________________________ From dbyron@coactive.com Mon Jan 4 23:43:58 1999 From: dbyron@coactive.com (David Byron) Date: Mon, 04 Jan 1999 15:43:58 -0800 Subject: [omniORB] namespace handling when a compiler doesn't support it Message-ID: <3.0.5.32.19990104154358.00b10640@refuge> Apologies if this has been dealt with before, but the archive search was down when I tried to look.... I am porting OmniORB2 to a compiler that doesn't support namespaces (Diab, for those interested). The macros for dealing with namespaces when the compiler doesn't put code for a particular namespace in a class. I have multiple files that share a namespace, as in: file1.idl --------- module foo { // some declarations }; file2.idl --------- #include "file1.idl" module foo { // some more declarations }; In file2.hh, this becomes: #include class foo { // some more declarations, turned into C++ } Unfortunately, the stubs are trying to declare class foo twice, which my compiler flags as an error. Am I using namespaces in an unexpected way, or is there another way to define the _CORBA_MODULE... macros to deal with this? I can remove the namespace if I must, but I'd rather not. Thanks for your help. -DB --- David Byron dbyron@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausalito, CA 94965 fax:(415)289-1320 From dcmay@object-workshops.com Tue Jan 5 01:32:24 1999 From: dcmay@object-workshops.com (Dietmar May) Date: Mon, 4 Jan 1999 20:32:24 -0500 Subject: [omniORB] namespace handling when a compiler doesn't support it Message-ID: David, > I am porting OmniORB2 to a compiler that doesn't support namespaces (Diab, for > those interested). The macros for dealing with namespaces when the compiler > doesn't put code for a particular namespace in a class. Orbix (pre-namespace circa ver. 2.2) handled this using concatenation of the module name with the interface name, separated by '_'. This generates: class foo_yourclass : ... { ... }; This is similar to the COM mapping in the CORBA interoperability spec, chapter 13. However, I don't think that omniORB can support this without changes (don't know how much would be required, but pretty sure you'd have to change omniORB sources in omni2idl). Look in src/tool/omniidl2/omniORB2_be/o2be_interface.cc (and o2be_constant.cc, etc). This is where the .hh and .cc generators are located. For instance: void o2be_interface::produce_hdr(std::fstream &s) { ... IND(s); s << "class " << uqname() << "_Helper {\n"; ... } See also o2be_name in src/tool/omniidl2/omniORB2_be/o2be.h. The method fqname() seems to return the fully qualified name (ie. scope name + unqualified name). If you can change uqname() to test a flag (that indicates whether to use concatenation), and return either the original value of uqname() or return fqname(), it may be pretty simple. Hope this is helpful. Regards, Dietmar May Software Architect Object Workshops, Inc. dcmay@object-workshops.com From objectdata@siliware.com Mon Jan 4 19:38:47 1999 From: objectdata@siliware.com (objectdata) Date: Mon, 04 Jan 1999 19:38:47 +0000 Subject: [omniORB] The Jini Community Message-ID: <369118C6.AC4E0B98@siliware.com> Sorry for the interruption. The Jini Community is a new gathering place where developers can discuss Javasoft's Jini technology. It has chat rooms, web board, security, email listserv, and search engine. The url for the new site is http://jini.siliware.com. Currently, we are seeking strategic alliances, partners, forum administrators, volunteers, and Jini related news, products, demos, and tutorials. If you or someone you know would like to participate in making Jini products and services or just simple wish to work with Jini, please let us know. You can become a forum administrator, showcase your Jini products and services, and exchange links to your Jini website. Take advantage of Javasoft's Source Community License. If you have not downloaded Jini and compiled the examples, you don't know what your missing. Jini is the next wave! Why not become a part of it. You got where you are by working harder than the next guy. Here is your chance to do it again. http://jini.siliware.com Jini Community Administrator Siliware, Inc. 45 Rockefeller Center, 20th Floor New York, NY 10111 Voice 212-332-8193 From dbyron@coactive.com Tue Jan 5 00:51:21 1999 From: dbyron@coactive.com (David Byron) Date: Mon, 04 Jan 1999 16:51:21 -0800 Subject: [omniORB] namespace handling when a compiler doesn't support it In-Reply-To: Message-ID: <3.0.5.32.19990104165121.00b07df0@refuge> >> I am porting OmniORB2 to a compiler that doesn't support namespaces (Diab, >for >> those interested). The macros for dealing with namespaces when the compiler >> doesn't put code for a particular namespace in a class. > >Orbix (pre-namespace circa ver. 2.2) handled this using concatenation of the >module name with the interface name, separated by '_'. This generates: > >class foo_yourclass : ... >{ > ... >}; > >This is similar to the COM mapping in the CORBA interoperability spec, chapter >13. However, I don't think that omniORB can support this without changes (don't >know how much would be required, but pretty sure you'd have to change omniORB >sources in omni2idl). > >Look in src/tool/omniidl2/omniORB2_be/o2be_interface.cc (and o2be_constant.cc, >etc). This is where the .hh and .cc generators are located. > >For instance: > >void o2be_interface::produce_hdr(std::fstream &s) >{ > ... > IND(s); s << "class " << uqname() << "_Helper {\n"; > ... >} > >See also o2be_name in src/tool/omniidl2/omniORB2_be/o2be.h. > >The method fqname() seems to return the fully qualified name (ie. scope name + >unqualified name). > >If you can change uqname() to test a flag (that indicates whether to use >concatenation), and return either the original value of uqname() or return >fqname(), it may be pretty simple. > >Hope this is helpful. Thanks for the pointer. This gets me very close to what I need. I think the actual place I'll make the change is in o2be_module.cc in o2be_module::produce_hdr(). It generates a _CORBA_MODULE followed by the name of the module. CORBA_sysdep.h does the 'right thing' depending on whether namespaces are supported or not. It would be nice if I could make the macro in CORAB_sysdep.h really smart by using __FILE__, but it's inside quotes, and doesn't seem easily messed with, besides including the full path, etc. To do this properly, I suppose I'd add a command line parameter to omniidl2 to tell it how to behave. Unfortunately, it makes the generated code platform specific, instead of platform independent. Or maybe, I'll add a script to my makefile that greps for _CORBA_MODULE and makes the change for me. Has anyone else run into this problem, and found another solution? -DB --- David Byron dbyron@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausalito, CA 94965 fax:(415)289-1320 From dbyron@coactive.com Tue Jan 5 02:11:14 1999 From: dbyron@coactive.com (David Byron) Date: Mon, 04 Jan 1999 18:11:14 -0800 Subject: [omniORB] namespace handling when a compiler doesn't support it In-Reply-To: <3.0.5.32.19990104165121.00b07df0@refuge> References: Message-ID: <3.0.5.32.19990104181114.00b0c1e0@refuge> >>> I am porting OmniORB2 to a compiler that doesn't support namespaces (Diab, >>for >>> those interested). The macros for dealing with namespaces when the compiler >>> doesn't put code for a particular namespace in a class. >> >>Orbix (pre-namespace circa ver. 2.2) handled this using concatenation of the >>module name with the interface name, separated by '_'. This generates: >> >>class foo_yourclass : ... >>{ >> ... >>}; >> >>This is similar to the COM mapping in the CORBA interoperability spec, chapter >>13. However, I don't think that omniORB can support this without changes (don't >>know how much would be required, but pretty sure you'd have to change omniORB >>sources in omni2idl). >> >>Look in src/tool/omniidl2/omniORB2_be/o2be_interface.cc (and o2be_constant.cc, >>etc). This is where the .hh and .cc generators are located. >> >>For instance: >> >>void o2be_interface::produce_hdr(std::fstream &s) >>{ >> ... >> IND(s); s << "class " << uqname() << "_Helper {\n"; >> ... >>} >> >>See also o2be_name in src/tool/omniidl2/omniORB2_be/o2be.h. >> >>The method fqname() seems to return the fully qualified name (ie. scope name + >>unqualified name). >> >>If you can change uqname() to test a flag (that indicates whether to use >>concatenation), and return either the original value of uqname() or return >>fqname(), it may be pretty simple. >> >>Hope this is helpful. > >Thanks for the pointer. This gets me very close to what I >need. I think the actual place I'll make the change is in >o2be_module.cc in o2be_module::produce_hdr(). It generates >a _CORBA_MODULE followed by the name of the module. >CORBA_sysdep.h does the 'right thing' depending on whether >namespaces are supported or not. It would be nice if I >could make the macro in CORAB_sysdep.h really smart by using >__FILE__, but it's inside quotes, and doesn't seem easily >messed with, besides including the full path, etc. To do >this properly, I suppose I'd add a command line parameter to >omniidl2 to tell it how to behave. Unfortunately, it makes >the generated code platform specific, instead of platform >independent. Or maybe, I'll add a script to my makefile >that greps for _CORBA_MODULE and makes the change for me. Hate to reply to myself, but.... The script to hack the module name is not enough. Or at least my simple one wasn't. Changes to omniidl seem to be required to make this work.... I'll post the changes to the IDL compiler if I can get the time to make them. For now, the namespaces have to go :( -DB --- David Byron dbyron@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausalito, CA 94965 fax:(415)289-1320 From knemeyer@ix.netcom.com Wed Jan 6 15:25:33 1999 From: knemeyer@ix.netcom.com (Manfred Knemeyer) Date: Wed, 6 Jan 1999 08:25:33 -0700 Subject: [omniORB] Failure to connect to omninames Message-ID: <002001be3988$ce5ba2c0$a44bd6ce@default> This is a multi-part message in MIME format. ------=_NextPart_000_001D_01BE394E.20E0FA80 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable On a standalone Windows-95 system without a network interface card, I can not connect to the names service. Do I need to configure TCP/IP for loop- back? If so, How do I do this? ------=_NextPart_000_001D_01BE394E.20E0FA80 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

On a standalone = Windows-95 system=20 without a network

interface card, I can = not connect to=20 the names

service. Do I need = to=20 configure TCP/IP for loop-

back? If so, How = do I do=20 this?

------=_NextPart_000_001D_01BE394E.20E0FA80-- From djr@orl.co.uk Wed Jan 6 15:29:45 1999 From: djr@orl.co.uk (David Riddoch) Date: Wed, 6 Jan 1999 15:29:45 +0000 (GMT) Subject: [omniORB] Re: omniorb and java In-Reply-To: <367E9C42.CA89FDF2@erols.com> Message-ID: Thanks for the suggestion - this will appear in the next release. There will be two new command line options ... -ORBinConScanPeriod -ORBoutConScanPeriod Cheers, David On Mon, 21 Dec 1998, Armen Yampolsky wrote: > In working with Sun's Java CORBA libraries (Java IDL) client-side, we > have noticed another issue: Although setting the > omniORB::idleConnectionScanPeriod on our server gives us control over > omniORB's connection shutdown scheme, it is not a complete fix. Since > the omniNames service runs in its own process, it is not affected by our > settings and uses the default hard-coded 30 second scan period. You will > find that addressing it from a java ORB will fail after a >60 second > delay. We simply altered the omniNames.cc file in order to allow us to > set the timeout via command line. > > This may be a simple but very helpful addition to omniORB. IMHO, it > would give it a consistency (why can we set the timeout for one process > and not another?). Could we convince the developers to add it? > > Cheers, > -Armen > > -- > Armen Yampolsky > Axiom Software Labs > New York From S.Lo@orl.co.uk Wed Jan 6 17:39:39 1999 From: S.Lo@orl.co.uk (Sai-Lai Lo) Date: 06 Jan 1999 17:39:39 +0000 Subject: [omniORB] Re: Connection Handler In-Reply-To: Armen Yampolsky's message of "Tue, 22 Dec 1998 12:06:06 -0500" References: <367FD17E.4A738F3D@erols.com> Message-ID: <3or9t847xg.fsf@neem.cam-orl.co.uk> >>>>> Armen Yampolsky writes: > I posted this question to the mailing list, and received a good number > of responses essentially saying -- "I need to know too, when you find > out, please tell me!" But alas, no information has been forthcoming, so > I would like to ask you directly: > I need to implement strict object disposal on my server. Many of my > servants place locks on databases, and I need a guarantee that all locks > and resources belonging to a rogue (disconnected) client are freed, no > matter the reason for the connection loss. > In working with other ORB vendors, I had implemented an Evictor pattern, > wherein a map was maintained by the server, tracking all connected > clients and their respective objects. I had a handler for the > (proprietary) connected and aborted events. If a client dropped > unexpectedly, my server knew about it and cleaned up after it. Now I am > moving to omniORB2, and am looking for such a hook. I see the events > written to cerr if I crank up the debug level, so I know that somewhere, > the ORB knows about the client IP and knows when the client connects and > disconnects. I'll be looking into the source soon, but am hoping someone > can tell me of such a hook, or even recommend a "proper" way to do > distributed garbage collection with omniORB. Hi! Garbage collecting objects on the server when the clients have failed is a topic that has been discussed quite a few times on the mailing list in the past. You may want to check the archive for some of the proposed solutions. Unlike other ORBs, there is no way to insert a handler into omniORB2 to get a callback when a connection is made or when it is broken. It is my opinion that using the status of network connections to detect client failure is a poor way of doing the job and does not fit in very well with the CORBA framework. It is the job of the ORB to decide when is the best time to establish a connection and how many connections are necessary to communicate with the server. The ORB should also have the freedom to shutdown idle connections when it is appropriate. This is in conflict with the idea of allowing the application to deduce the status of the remote end purely from the status of the related network connections. Essentially what is required is for the server to associate a session with each client. All the objects created on the server within the session are linked together with a representation of the session in the server. When the session is closed or broken, the server can walk through the list and dispose of all its associated objects. The question then reduces to how to represent a session and detects when it has failed. There are various ways to do so. For example, a session can be represented as a CORBA object provided by the client. The server holds an object reference to this session object. Periodically, a thread in the server checks if the session object can still be contacted. If communication with the session object fails, the server thread does the garbage collection. Of course there should also be a fast way for the client to close a session orderly. The refresh mechanism used by the server is only meant to be a last resort to detect client failures. Regards, Sai-Lai -- Dr. Sai-Lai Lo | Research Scientist | E-mail: S.Lo@orl.co.uk | Olivetti & Oracle Research Lab | 24a Trumpington Street Tel: +44 223 343000 | Cambridge CB2 1QA Fax: +44 223 313542 | ENGLAND From doug@clark.net Thu Jan 7 01:15:13 1999 From: doug@clark.net (Doug Anderson) Date: Wed, 6 Jan 1999 20:15:13 -0500 Subject: [omniORB] Re: Connection Handler Message-ID: <001601be39db$2e073d40$0500000a@cc702523-a.hwrd1.md.home.com> Hi, Sai Lai wrote: >Unlike other ORBs, there is no way to insert a handler into omniORB2 to get >a callback when a connection is made or when it is broken. It is my opinion >that using the status of network connections to detect client failure is >a poor way of doing the job and does not fit in very well with the CORBA >framework. It is the job of the ORB to decide when is the best time to >establish a connection and how many connections are necessary to communicate >with the server. Not to mention the fact that this would not work well in a connection-LESS GIOP implementation, ala IIOP over UDP?? (if and when such a beast becomes commonplace!) Doug From janssen@parc.xerox.com Thu Jan 7 03:16:05 1999 From: janssen@parc.xerox.com (Bill Janssen) Date: Wed, 6 Jan 1999 19:16:05 PST Subject: [omniORB] Re: Connection Handler In-Reply-To: <3or9t847xg.fsf@neem.cam-orl.co.uk> References: <367FD17E.4A738F3D@erols.com> <3or9t847xg.fsf@neem.cam-orl.co.uk> Message-ID: Excerpts from ext.omniorb: 6-Jan-99 [omniORB] Re: Connection Ha.. Sai-Lai Lo@orl.co.uk (3640) > Unlike other ORBs, there is no way to insert a handler into omniORB2 to get > a callback when a connection is made or when it is broken. It is my opinion > that using the status of network connections to detect client failure is > a poor way of doing the job and does not fit in very well with the CORBA > framework. It is the job of the ORB to decide when is the best time to > establish a connection and how many connections are necessary to communicate > with the server. The ORB should also have the freedom to shutdown idle > connections when it is appropriate. This is in conflict with the idea of > allowing the application to deduce the status of the remote end purely from > the status of the related network connections. Exactly right. We do the same in ILU. > For example, a session can be > represented as a CORBA object provided by the client. The server holds an > object reference to this session object. Periodically, a thread in the > server checks if the session object can still be contacted. If > communication with the session object fails, the server thread does the > garbage collection. Of course there should also be a fast way for the > client to close a session orderly. The refresh mechanism used by the server > is only meant to be a last resort to detect client failures. This mechanism is built into ILU as part of our distributed garbage collection system. Bill From ayampolsky@erols.com Thu Jan 7 03:39:55 1999 From: ayampolsky@erols.com (Armen Yampolsky) Date: Wed, 06 Jan 1999 22:39:55 -0500 Subject: [omniORB] Re: Connection Handler References: <367FD17E.4A738F3D@erols.com> <3or9t847xg.fsf@neem.cam-orl.co.uk> Message-ID: <36942C8B.64D65ECD@erols.com> Thanks, my understanding is much clearer now. I will begin to implement a session-based evictor, and will write a thread that checks clients. I wanted to minimize client pings, but I guess it will not result in too much network traffic... Thank you for this clear explanation. Cheers, -Armen > Armen Yampolsky writes: > > In working with other ORB vendors, I had implemented an Evictor pattern, > > wherein a map was maintained by the server, tracking all connected > > clients and their respective objects. I had a handler for the > > (proprietary) connected and aborted events. If a client dropped > > unexpectedly, my server knew about it and cleaned up after it. Now I am > > moving to omniORB2, and am looking for such a hook. Sai-Lai Lo wrote: > It is the job of the ORB to decide when is the best time to > establish a connection and how many connections are necessary to communicate > with the server. The ORB should also have the freedom to shutdown idle > connections when it is appropriate. This is in conflict with the idea of > allowing the application to deduce the status of the remote end purely from > the status of the related network connections. > > Essentially what is required is for the server to associate a session with > each client. All the objects created on the server within the session are > linked together with a representation of the session in the server. When > the session is closed or broken, the server can walk through the list and > dispose of all its associated objects. > > The question then reduces to how to represent a session and detects when it > has failed. There are various ways to do so. For example, a session can be > represented as a CORBA object provided by the client. The server holds an > object reference to this session object. Periodically, a thread in the > server checks if the session object can still be contacted. If > communication with the session object fails, the server thread does the > garbage collection. Of course there should also be a fast way for the > client to close a session orderly. The refresh mechanism used by the server > is only meant to be a last resort to detect client failures. -- Armen Yampolsky Axiom Software Labs New York From dcmay@object-workshops.com Thu Jan 7 05:09:23 1999 From: dcmay@object-workshops.com (Dietmar May) Date: Thu, 7 Jan 1999 00:09:23 -0500 Subject: [omniORB] Re: Connection Handler Message-ID: Armen, > Thanks, my understanding is much clearer now. I will begin to implement a > session-based evictor, and will write a thread that checks clients. I wanted > to minimize client pings, but I guess it will not result in too much network > traffic... A factor in our handling of network connections is that we DON'T want clients to HAVE to be servers as well. You might consider whether it is acceptable for the client to notify the server that it is still active and using resources, rather than the server querying the client (which requires the client to become a server too). Most clients could perform an occasional keep-alive request during idle time (or GUI-timer) processing without requiring an extra thread. Regards, Dietmar May Software Architect Object Workshops, Inc. dcmay@object-workshops.com From myles@ams.co.nz Thu Jan 7 04:21:12 1999 From: myles@ams.co.nz (Myles Penlington) Date: Thu, 7 Jan 1999 17:21:12 +1300 Subject: [omniORB] Re: Connection Handler Message-ID: <01BE3A62.205C52C0@myles> A minor improvement on this is to borrow the concept of a watch dog = timer from real time embedded systems. So only ping the clients if the = timer expires. How the timer is reset for each session object is the tricky part.=20 The simplest method would be to add code for each CORBA method on the = server side object. eg ResetSessionTimer, i.e So whenever a call is made = to a method on the server side object, the sever side method resets the = watch dog timer for the session object from the originating session. Other variations could be to change the ping frequency/timer expiry = period, depending on the operations in progress. Myles Penlington. -----Original Message----- From: Armen Yampolsky [SMTP:ayampolsky@erols.com] Sent: Thursday, January 07, 1999 4:40 PM To: omniorb-list@orl.co.uk Subject: [omniORB] Re: Connection Handler Thanks, my understanding is much clearer now. I will begin to implement = a session-based evictor, and will write a thread that checks clients. I = wanted to minimize client pings, but I guess it will not result in too much = network traffic... Thank you for this clear explanation. Cheers, -Armen From gdd0@gte.com Thu Jan 7 14:10:32 1999 From: gdd0@gte.com (Gary D. Duzan) Date: Thu, 07 Jan 1999 09:10:32 -0500 Subject: [omniORB] Re: Connection Handler Message-ID: <199901071410.JAA25330@lion.gte.com> Well, strictly speaking you can't do GIOP over a connectionless transport since it is inherently connection-oriented, but not all CORBA communication has to be GIOP-based. Gary Duzan GTE Laboratories In Message <001601be39db$2e073d40$0500000a@cc702523-a.hwrd1.md.home.com> , "Doug Anderson" wrote: =>Hi, => =>Sai Lai wrote: =>>Unlike other ORBs, there is no way to insert a handler into omniORB2 to get =>>a callback when a connection is made or when it is broken. It is my opinion =>>that using the status of network connections to detect client failure is =>>a poor way of doing the job and does not fit in very well with the CORBA =>>framework. It is the job of the ORB to decide when is the best time to =>>establish a connection and how many connections are necessary to =>communicate =>>with the server. => =>Not to mention the fact that this would not work well in a connection-LESS =>GIOP implementation, ala IIOP over UDP?? (if and when such a beast =>becomes commonplace!) => =>Doug => => => From cbst@oce.nl Thu Jan 7 14:31:42 1999 From: cbst@oce.nl (Casper Stoel) Date: Thu, 07 Jan 1999 15:31:42 +0100 Subject: [omniORB] Porting omniEvents to NT? Message-ID: <3694C54E.F4F44E62@oce.nl> As will be clear from the subject, who has ported Paul Nader's omniEvents to NT? I am no porting wizard and could use some help in this task... Any pointers are welcome! Casper Stoel From dcmay@object-workshops.com Thu Jan 7 15:49:56 1999 From: dcmay@object-workshops.com (Dietmar May) Date: Thu, 7 Jan 1999 10:49:56 -0500 Subject: [omniORB] Re: Connection Handler Message-ID: > A minor improvement on this is to borrow the concept of a watch dog timer from > real time embedded systems. So only ping the clients if the timer expires. > > How the timer is reset for each session object is the tricky part. > > The simplest method would be to add code for each CORBA method on the server > side object. eg ResetSessionTimer, i.e So whenever a call is made to a method > on the server side object, the sever side method resets the watch dog timer > for the session object from the originating session. > > Other variations could be to change the ping frequency/timer expiry period, > depending on the operations in progress. > > Myles Penlington. Now, if only we could get the ORB to do this, perhaps changing the IDL compiler to call thru a function pointer (if set) in every dispatch() method ... we might have something like Armen was originally asking for. (It avoids the tediousness (as Stroustrup puts it) of repetitive code - and the accompanying propensity for errors). Now, the question is whether there is a unique handle for each client that could be used automatically (obviously not the socket handle), or does the client have to explicitly pass in a server-assigned handle as a parameter to each IDL call? ie. is it possible to uniquely and unambiguously identify a client based on connection parameters, given the abilty (and need) of the ORB to shut down and re-open connections? Dietmar From renzo.tomaselli@tecnotp.inet.it Thu Jan 7 16:50:33 1999 From: renzo.tomaselli@tecnotp.inet.it (Renzo Tomaselli) Date: Thu, 7 Jan 1999 17:50:33 +0100 Subject: [omniORB] Re: Connection Handler Message-ID: <199901071649.RAA13936@venere.inet.it> Hi, why not using contexts to avoid an extra parameter on each IDL call ? Identifying the client sounds much like identifying the principal for security reasons or identifying the current transaction for other purpose= s (the implicit way). Since the connection is out of this game, it seems to me that the client is the only subject enabled to specify its own identit= y as thread/process/host or whatever else. From long time ago discussions o= n this list about contexts, I remember they weren't much welcome; however having a client identity/principal identity/transaction control as extra parameters in each call would be terrific. Comments are much welcome, Renzo Tomaselli =20 -------------------------------------------------------------------------= -- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 0461 773164 Fax. +39 0461 771514 e-mail: renzo.tomaselli@tecnotp.inet.it =20 -------------------------------------------------------------------------= -- ---------- > From: Dietmar May > To: 'Myles Penlington' ; 'Armen Yampolsky' ; omniorb-list@orl.co.uk > Subject: RE: [omniORB] Re: Connection Handler > Date: gioved=EC 7 gennaio 1999 16.49 >=20 >=20 > Now, if only we could get the ORB to do this, perhaps changing the IDL compiler=20 > to call thru a function pointer (if set) in every dispatch() method ... we=20 > might have something like Armen was originally asking for. (It avoids t= he > tediousness (as Stroustrup puts it) of repetitive code - and the accompanying=20 > propensity for errors). >=20 > Now, the question is whether there is a unique handle for each client that=20 > could be used automatically (obviously not the socket handle), or does the=20 > client have to explicitly pass in a server-assigned handle as a paramet= er to=20 > each IDL call? ie. is it possible to uniquely and unambiguously identif= y a=20 > client based on connection parameters, given the abilty (and need) of t= he ORB=20 > to shut down and re-open connections? >=20 > Dietmar >=20 >=20 From knemeyer@ix.netcom.com Sat Jan 9 05:40:45 1999 From: knemeyer@ix.netcom.com (Manfred Knemeyer) Date: Fri, 8 Jan 1999 22:40:45 -0700 Subject: [omniORB] Failure to connect to omninames Message-ID: <000401be3b92$9bfa78e0$a44bd6ce@default> Thank you for the response, Dietmar. The MS Loopback Adapter seems to be an NT thing; it is not available on Windows-95. My concern about loopback appears unfounded. A "localhost" configuration should be adequate. Sorry to learn that others also have not been able to get omninames to run on standalone Windows-95. >There is a loopback network device driver available under Windows (I think it's >95, not NT that has it). Try to change your network adapter to Microsoft >(801.3) MS Loopback. > >Sorry I can't be more specific: we only run NT here on machines with network >adapters, so I don't have a copy of Windows95 installed on any machines at >present. > >I also don't know if this will fix your underlying problem. I know that we've >had problems running omniNames under Win95 - never debugged the cause. > >Hope this is helpful. > >Regards, >Dietmar May From knemeyer@ix.netcom.com Sat Jan 9 05:45:48 1999 From: knemeyer@ix.netcom.com (Manfred Knemeyer) Date: Fri, 8 Jan 1999 22:45:48 -0700 Subject: [omniORB] Help Please - Unable to contact naming service on Windows-95 Message-ID: <001301be3b93$50a0cf60$a44bd6ce@default> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01BE3B58.A2D23AC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Thank you for the response, Michael. I have rebuilt everything and still am not able to connect to omninames. Has anyone else been able to get the Windows-95 package to run on a standalone system? HI, try to recompile the whole omniorb2 package. I had the same problem = and it had been fixed afterwards. cu Michael Muchitsch -----Urspr=FCngliche Nachricht----- Von: Manfred Knemeyer An: omniORB Datum: Montag, 4. Januar 1999 11:07 Betreff: [omniORB] Help Please - Unable to contact naming = service on Windows-95 =20 =20 Hopefully someone can suggest why I am not able to run omniORB2 on my standalone Windows-95 system. I have not been able to = find obviously relevant info in the archives. Any help will be appreciated. I very much would like to experiment and learn = using omniOrb2. To narrow the problem, I have tried to list all of = the details below. Thanks for your patience in reading them. =20 knemeyer@ix.netcom.com =20 I have installed the Windows-95 binary release of version 2.6.0 and rebuilt the echo examples (only) with MSC++ 6 + Patchkit 1 = and gnu-win32-lite. The rebuilt example eg1 runs successfully, eg2's IOR argument exceeds the DOS window cmd line length limit, and eg3 fails in trying to contact the naming service. =20 The environment variable OMNIORB2_CONFIG is set to the filepath of the configuration file (added after initial failures) which contains: NAMESERVICE IOR:. . . ORBInitialHost localhost ORBInitialPort 12345 =20 Registry also contains the above 3 values; the IOR has been = checked against the nameservice.exe startup message; localhost is the = only entry in the \WINDOWS\Hosts file; the system was rebooted. =20 omninames (not rebuilt) is running: Checkpointing completed. =20 =20 eg3_impl started, then eg3_clt started (in DOS windows). =20 After some delay ... =20 eg3_impl: Caught system exception COMM_FAILURE, unable to = contact the naming service. =20 eg3_clt: Caught system exception COMM_FAILURE, unable to contact = the naming service. hello: cannot invoke on a nil object reference. =20 omninames is still running. =20 =20 ------=_NextPart_000_0010_01BE3B58.A2D23AC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Thank you for = the response,=20 Michael.

I have rebuilt everything and still am not = able

to connect to = omninames.

Has anyone else been able to = get the=20 Windows-95

package to run on a standalone=20 system?

HI,

try to recompile the whole omniorb2 package. I = had the=20 same problem and it had been fixed afterwards.

Michael Muchitsch

-----Ursprüngliche=20 Nachricht-----
Von: Manfred Knemeyer <knemeyer@ix.netcom.com>
= An:=20 omniORB <omniorb-list@orl.co.uk>
= Datum:=20 Montag, 4. Januar 1999 11:07
Betreff: [omniORB] = Help=20 Please - Unable to contact naming service on=20 Windows-95

Hopefully someone can=20 suggest why I am not able to run omniORB2

on my standalone Windows-95 = system. I=20 have not been able to find

obviously relevant info = in the=20 archives. Any help will be

appreciated. I = very much=20 would like to experiment and learn using

omniOrb2. To = narrow the=20 problem, I have tried to list all of the

details below. = Thanks for=20 your patience in reading them.

knemeyer@ix.netcom.com<= /DIV>

I have = installed the=20 Windows-95 binary release of version 2.6.0

and = rebuilt the echo=20 examples (only) with MSC++ 6 + Patchkit 1 and

gnu-win32-lite. =20 The rebuilt example = eg1 runs=20 successfully,

eg2's IOR argument = exceeds the DOS window cmd line = length=20 limit,

and eg3 fails in trying = to contact=20 the naming service.

The = environment =20 variable OMNIORB2_CONFIG is set to the filepath

of the configuration file (added = after initial=20 failures) which

contains:

NAMESERVICE IOR:. . = .

ORBInitialHost=20 localhost

ORBInitialPort = 12345

Registry also contains = the above 3=20 values; the IOR has been checked

against the = nameservice.exe startup=20 message; localhost is the only

entry in the = \WINDOWS\Hosts file;=20 the system was rebooted.

omninames (not rebuilt) is = running:=20 Checkpointing completed.

eg3_impl started,=20 then eg3_clt started (in DOS windows).

After some delay = ...

eg3_impl: Caught system = exception=20 COMM_FAILURE, unable to contact the naming = service.

eg3_clt: Caught=20 system exception COMM_FAILURE, unable to contact the naming=20 service.
hello: cannot invoke on a nil object=20 reference.

omninames is still=20 running.

------=_NextPart_000_0010_01BE3B58.A2D23AC0-- From knemeyer@ix.netcom.com Sat Jan 9 13:40:07 1999 From: knemeyer@ix.netcom.com (Manfred Knemeyer) Date: Sat, 9 Jan 1999 06:40:07 -0700 Subject: [omniORB] RE: Unable to contact naming service. Message-ID: <004901be3bd5$92f42820$bd4cd6ce@default> This is a multi-part message in MIME format. ------=_NextPart_000_0046_01BE3B9A.E5A12C20 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable I have now finally been able to establish a connection to the naming service on a standalone Windows-95 system = without a network interface card. This required that dialup networking (DUN) be up and running (which connects to my ISP) before omninames is started - and DUN not then stopped. Any suggestions on how to get around this ? ------=_NextPart_000_0046_01BE3B9A.E5A12C20 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

I have now = finally been able=20 to establish a

connection = to the naming service on a = standalone=20 Windows-95 system without a network interface card.

This required = that dialup=20 networking (DUN) be up

and running = (which connects=20 to my ISP) before

omninames is = started - and=20 DUN not then stopped.

Any suggestions = on how to=20 get around = this=20 ?

------=_NextPart_000_0046_01BE3B9A.E5A12C20-- From shichunhui@usa.net Mon Jan 11 02:14:30 1999 From: shichunhui@usa.net (shich) Date: Mon, 11 Jan 1999 10:14:30 +0800 Subject: [omniORB] how can I download omniORB Message-ID: <36995E86.92A07C44@usa.net> hi,I am a new comer,I have tried to download the omniORB for windows and solaris.But the ftp.orl.co.uk doesn't support broken-resume download so I always ended my download with broken file and broken heart.Anyone here would suggest a better site for me? From dbyron@coactive.com Tue Jan 12 00:19:29 1999 From: dbyron@coactive.com (David Byron) Date: Mon, 11 Jan 1999 16:19:29 -0800 Subject: [omniORB] method call in nbufferedstream.cc Message-ID: <3.0.5.32.19990111161929.00b33950@refuge> In nbufferedstream.cc, I'm having a problem compiling the following line of code from NetBufferedStream::WrUnlock() Strand_Sync::WrUnlock(); Strand_Sync comes from: typedef Strand::Sync Strand_Sync; in rope.h. Anyway, there is a static function in class Strand::Sync called WrUnlock. It's signature is: static void WrUnlock(Strand* s); >From this, it would appear that the call in nbufferedstream.cc is missing an argument. Another possibility is that the desired method is: void WrUnlock(_CORBA_Boolean held_rope_mutex=0); which is a protected method in class Strand::Sync. If this is the desired method, then the Strand_Sync:: would be removed. Doing this causes the code to compile fine. To note, I'm using the Metaware High C/C++ compiler... So the question is, which of the two WrUnlock methods is supposed to be called here? Thanks for your help. -DB --- David Byron dbyron@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausalito, CA 94965 fax:(415)289-1320 From djr@orl.co.uk Tue Jan 12 09:12:29 1999 From: djr@orl.co.uk (David Riddoch) Date: Tue, 12 Jan 1999 09:12:29 +0000 (GMT) Subject: [omniORB] method call in nbufferedstream.cc In-Reply-To: <3.0.5.32.19990111161929.00b33950@refuge> Message-ID: On Mon, 11 Jan 1999, David Byron wrote: > In nbufferedstream.cc, I'm having a problem compiling the following > line of code from NetBufferedStream::WrUnlock() > > Strand_Sync::WrUnlock(); > > Strand_Sync comes from: > > typedef Strand::Sync Strand_Sync; > > in rope.h. > > Anyway, there is a static function in class Strand::Sync called > WrUnlock. It's signature is: > > static void WrUnlock(Strand* s); > > >From this, it would appear that the call in nbufferedstream.cc is > missing an argument. Another possibility is that the desired method is: > > void WrUnlock(_CORBA_Boolean held_rope_mutex=0); > > which is a protected method in class Strand::Sync. Yes its this one. > If this is the desired method, then the Strand_Sync:: would be removed. > Doing this causes the code to compile fine. To note, I'm using the > Metaware High C/C++ compiler... But Strand_Sync::WrUnlock() is being called from NetBufferedStream::WrUnlock(). If you remove the Strand_Sync:: then you will get a recursive call back into NetBufferedStream::WrUnlock(). Looks like you have a compiler bug. To work-around the problem try: Strand::Sync::WrUnlock(); Hope this solves the problem. David From bjornw@fairplay.no Tue Jan 12 15:55:30 1999 From: bjornw@fairplay.no (bjornw@fairplay.no) Date: 12 Jan 1999 16:55:30 +0100 Subject: [omniORB] To delete or not to delete.... Message-ID: Hi omniorbers! Let us say that I have a server that allocates a sequence of elements, and that the client deletes it. Is that it? The reason I'm asking is because I have a server that grows and grows and grows ...=20 Here is some pseudo code that illustrate a typical scenario // idl file typedef sequence long_seq; interface server { long_seq query(); }; // server-implementation long_seq * server::query() { long_seq *ptr =3D new long_seq; return ptr; } // client implementation long_seq *ptr =3D server->query(); delete ptr; bjornw> Sincerely ------------------------------------------------------- Bj=F8rn Wennberg email: bjornw@fairplay.no=20 ms: +47 950 82 657 Senior Programmer phone: +47 22405538 FairPlay International AS fax: +47 22405539 From djr@orl.co.uk Wed Jan 13 09:38:18 1999 From: djr@orl.co.uk (David Riddoch) Date: Wed, 13 Jan 1999 09:38:18 +0000 (GMT) Subject: [omniORB] To delete or not to delete.... In-Reply-To: Message-ID: As far as I know what you've done is correct. If you look in the stub code, you should see something like this ... CORBA::Boolean _sk_server::dispatch(...) { if (strcmp(_0RL_op,"query") =3D=3D 0) { ... long_seq_var _0RL_result; _0RL_result =3D query(); ... } ... } So the sequence should be deleted by the destructor of long_seq_var. Let us know if you find a leak in the ORB! Cheers, David On 12 Jan 1999 bjornw@fairplay.no wrote: > Hi omniorbers! >=20 > Let us say that I have a server that allocates a sequence of elements, > and that the client deletes it. Is that it? The reason I'm asking is > because I have a server that grows and grows and grows ...=20 >=20 > Here is some pseudo code that illustrate a typical scenario >=20 > // idl file > typedef sequence long_seq; >=20 > interface server { > long_seq query(); > }; >=20 > // server-implementation > long_seq * > server::query() > { > =09long_seq *ptr =3D new long_seq; > =09return ptr; > } >=20 > // client implementation > long_seq *ptr =3D server->query(); > delete ptr; >=20 > bjornw> Sincerely >=20 > ------------------------------------------------------- > Bj=F8rn Wennberg email: bjornw@fairplay.no=20 > ms: +47 950 82 657 > Senior Programmer phone: +47 22405538 > FairPlay International AS fax: +47 22405539 >=20 >=20 From Renzo Tomaselli" This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01BE3EED.5284AAB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, as a developer of a distributed imaging application which makes use = of OmniORB I run into some maintenance issues since the application is = packaged into a number of dlls connected through a dynamic loader. = Everything works fine as far as OmniORB is concerned. It happens that = modules which have indipendent life but some form of dependency (A calls = B methods) run into incompatibility problems such as changing a method = signature because IDL design changed but runtime or installation made a = poor job. A quick screening of OmniORB sources pointed out as the = version field of Interface Rep. Id is not used and it seems also that = IIOP doesn't transmit IntfRepID along requests. Woudn't it be a good = choice for version control of interdipendent objects ? Would it violate = any CORBA specs to have it transmitted from client stubs to the server = so that the implementation skeleton can check it against its own, = refusing to dispatch unmatched versions ? Comments are welcome, Renzo = Tomaselli =20 -------------------------------------------------------------------------= -- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 0461 773164 Fax. +39 0461 771514 e-mail: renzo.tomaselli@eclipse-net.it =20 -------------------------------------------------------------------------= -- ------=_NextPart_000_00CD_01BE3EED.5284AAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there,

as a developer of = a=20 distributed imaging application which makes use of OmniORB I run into = some=20 maintenance issues since the application is packaged into a number of = dlls=20 connected through a dynamic loader. Everything works fine as far as = OmniORB is=20 concerned. It happens that modules which have indipendent life but some = form of=20 dependency (A calls B methods) run into incompatibility problems such as = changing a method signature because IDL design changed but runtime or=20 installation made a poor job. A quick screening of OmniORB sources = pointed out=20 as the version field of Interface Rep. Id is not used and it seems also = that=20 IIOP doesn't transmit IntfRepID along requests. Woudn't it be a good = choice for=20 version control of interdipendent objects ? Would it violate any CORBA = specs to=20 have it transmitted from client stubs to the server so that the = implementation=20 skeleton can check it against its own, refusing to dispatch = unmatched =20 versions ?

Comments are=20 welcome,

          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  =20 Renzo Tomaselli     =20
---------------------------------------------------------------------= ------
TecnoTP=20 s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi=20 Valsugana, Trento TN ITALY
Tel. +39 0461=20 773164      Fax. +39 0461 771514
e-mail: renzo.tomaselli@eclipse-ne= t.it  =20
---------------------------------------------------------------------= ------

------=_NextPart_000_00CD_01BE3EED.5284AAB0-- From rshoup@tumbleweed.com Wed Jan 13 17:03:52 1999 From: rshoup@tumbleweed.com (Randy Shoup) Date: Wed, 13 Jan 1999 09:03:52 -0800 Subject: [omniORB] HTTP tunnelling issues? Message-ID: <369CD1F8.95670082@tumbleweed.com> All -- We are potentially considering developing an addition to omniORB to support ORB requests over HTTP (to tunnel under firewalls). I just wanted to query the folks on the list to see if there has been any work done on this by anyone else for omniORB. We are aware of Orbix's WonderWall product, but suspect (without proof) that this might not work in a purely omniORB environment. Before deciding to embark on this project, we also will look carefully at Sai Lai's suggestions about how to add an additional transport to omniORB (http://www.orl.co.uk:80/omniORB/archives/1998-02/0050.html). Any further issues that anyone might be aware of? If we do, in fact, develop this, we would of course make it available to the omniORB community at large. Judging by the several requests for this functionality on the list over time, I suspect that there is demand out there. Thanks, -- Randy _________________________________________________________________ Randy Shoup (650)569-3682 Software Architect rshoup@tumbleweed.com Tumbleweed Software Corporation From lavoie@proksim.com Wed Jan 13 19:39:32 1999 From: lavoie@proksim.com (Martin Lavoie) Date: Wed, 13 Jan 1999 14:39:32 -0500 Subject: [omniORB] omniORB 2.5.0 Message-ID: <41C174DACD99D211AD090008C760380D0917@proksim.com> Hi everyone, Anybody still has version 2.5.0 or know where I can get it ? We have old code here which does not compile because of IDL changes that we just want to execute for test purposes and we don't want to go back and patch it to work with 2.6.1. We use to have it on our server, but our server got robbed 8-(. So if you know where I can get it, I would appreciate a lot. I'm looking for the win32_x86 compiled version. thanks, - martin ------------------------------------------------------------------------= --------------- Martin Lavoie Proksim Software Inc. System Architect 425, Place Jacques-Cartier lavoie@proksim.com Suite 201 Tel: (514) 940-4263 Montr=E9al, Qu=E9bec Fax: (514) 940-9091 Canada. H2Y 3B1 ------------------------------------------------------------------------= --------------- L'imagination est plus importante que le savoir. (Imagination is more important than knowledge.)=20 Einstein (Albert), On Science. From dbyron@coactive.com Wed Jan 13 20:11:29 1999 From: dbyron@coactive.com (David Byron) Date: Wed, 13 Jan 1999 12:11:29 -0800 Subject: [omniORB] another module/namespace question Message-ID: <3.0.5.32.19990113121129.00b492f0@refuge> As my search for namespace-aware compilers continues, it appears there are (at least) three levels of namespace support: 1. none 2. as long as the contents of a namespace are declared in exactly one file 3. namespace declarations work even if they in multiple files I'm working with a compiler that falls into category 2 (MetaWare High C/C++ 4.0a), so I figured I'd structure my IDL files as follows: master.idl ---------- module my_module { #include #include #include ... }; instead of having module my_module inside each IDL file. I figured omniidl would create a stub file master.hh with something like: _CORBA_MODULE my_module _CORBA_MODULE_BEG #include #include #include ... _CORBA_MODULE_END Unfortunately, the actual master.hh that's generated looks something like: #include #include #include _CORBA_MODULE my_module _CORBA_MODULE_BEG _CORBA_MODULE_END Is my solution a valid one? Should I change the IDL compiler to do what I want? Thanks for your help. -DB --- David Byron dbyron@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausalito, CA 94965 fax:(415)289-1320 From myles@ams.co.nz Wed Jan 13 21:19:50 1999 From: myles@ams.co.nz (Myles Penlington) Date: Thu, 14 Jan 1999 10:19:50 +1300 Subject: [omniORB] HTTP tunnelling issues? Message-ID: <01BE3FA7.6C138720@myles> The Inprise/Visibroker firewall/tunnelling product may work with OmniORB = - it just passes the requests through the firewall - have a look at = their website. >From what I have been told about Orbix's product - your suspicions would = be correct. Myles Penlington. -----Original Message----- From: Randy Shoup [SMTP:rshoup@tumbleweed.com] Sent: Thursday, January 14, 1999 6:04 AM To: omniorb-list@orl.co.uk Subject: [omniORB] HTTP tunnelling issues? All -- We are potentially considering developing an addition to omniORB to support ORB requests over HTTP (to tunnel under firewalls). I just wanted to query the folks on the list to see if there has been any work done on this by anyone else for omniORB. We are aware of Orbix's WonderWall product, but suspect (without proof) that this might not work in a purely omniORB environment. =20 Before deciding to embark on this project, we also will look carefully at Sai Lai's suggestions about how to add an additional transport to omniORB (http://www.orl.co.uk:80/omniORB/archives/1998-02/0050.html).=20 Any further issues that anyone might be aware of? If we do, in fact, develop this, we would of course make it available to the omniORB community at large. Judging by the several requests for this functionality on the list over time, I suspect that there is demand out there. Thanks, -- Randy _________________________________________________________________ =20 Randy Shoup (650)569-3682 =20 Software Architect rshoup@tumbleweed.com =20 Tumbleweed Software Corporation From rshoup@tumbleweed.com Thu Jan 14 03:46:51 1999 From: rshoup@tumbleweed.com (Randy Shoup) Date: Wed, 13 Jan 1999 19:46:51 -0800 Subject: [omniORB] SSL support status? Message-ID: <369D68AB.D4988563@tumbleweed.com> omniORB crew -- There have been some rumors of a working IIOP over SSL transport with omniORB (http://www.orl.co.uk/omniORB/archives/1998-11/0041.html). We would be very interested in SSL support, and may have to develop it ourselves if we can't beg, borrow, or steal it. We would prefer, of course, to leverage the hard work of others here :-) Is there a time-frame on when SSL support will be ready for prime time? The note I reference above says that you don't want to release it before IIOP1.1. Is IIOP1.1 required to get SSL to work with IIOP? -- Randy _________________________________________________________________ Randy Shoup (650)569-3682 Software Architect rshoup@tumbleweed.com Tumbleweed Software Corporation From djr@orl.co.uk Thu Jan 14 09:20:02 1999 From: djr@orl.co.uk (David Riddoch) Date: Thu, 14 Jan 1999 09:20:02 +0000 (GMT) Subject: [omniORB] another module/namespace question In-Reply-To: <3.0.5.32.19990113121129.00b492f0@refuge> Message-ID: David, When you #include an IDL file the compiler makes the assumption that you will also compile that file separately (to generate interface1.hh etc.). It will not produce stub code for the IDL in included files. To achieve a (partial) solution you could run the C pre-processor over master.idl yourself, remove the file and line number information (using sed or something) and IDL compile the result. I think this would be a lot less work than modifying the compiler yourself. David On Wed, 13 Jan 1999, David Byron wrote: > As my search for namespace-aware compilers continues, it appears there > are (at least) three levels of namespace support: > > 1. none > 2. as long as the contents of a namespace are declared in exactly one file > 3. namespace declarations work even if they in multiple files > > I'm working with a compiler that falls into category 2 (MetaWare High > C/C++ 4.0a), so I figured I'd structure my IDL files as follows: > > master.idl > ---------- > module my_module > { > #include > #include > #include > ... > }; > > instead of having module my_module inside each IDL file. > > I figured omniidl would create a stub file master.hh with something like: > > _CORBA_MODULE my_module > _CORBA_MODULE_BEG > > #include > #include > #include > ... > > _CORBA_MODULE_END > > Unfortunately, the actual master.hh that's generated looks something like: > > #include > #include > #include > > _CORBA_MODULE my_module > _CORBA_MODULE_BEG > > _CORBA_MODULE_END > > Is my solution a valid one? Should I change the IDL compiler to do > what I want? > > Thanks for your help. > > -DB > --- > David Byron dbyron@coactive.com > Coactive Networks, Inc. http://www.coactive.com > 4000 Bridgeway, Suite 303 voice:(415)289-1722 > Sausalito, CA 94965 fax:(415)289-1320 > > > From dmorgen@alum.mit.edu Thu Jan 14 21:20:33 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Thu, 14 Jan 1999 21:20:33 GMT Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: <3or9uisp1n.fsf@neem.cam-orl.co.uk> References: <366468EE.2615DB12@fairplay.no> <3or9uisp1n.fsf@neem.cam-orl.co.uk> Message-ID: <36a05c28.166031374@smtp.ne.mediaone.net> I'm trying to #include a .H file into my .IDL file. But the IDL compiler= is having problems: 1. If I do the #include within an interface, I get a "can't parse = statement" error & the compiler (omniidl2) crashes with a system exception. =20 2. So, for testing purposes, I moved the #include outside any interface = & tried again. I preceded the #include with a typedef statement, defining a type= used by the .H file. This compiled without error, but generated incorrect = code, e.g. in the .HH file: a. The #include statement is put at the front of the .HH file, while = the typedef is placed later, AFTER the #include, which requires it. b. The #include is for x.HH, when it should be for x.H. How can I get the IDL compiler to do what I need, which is handle a = struct defined within an interface, via a .H file, placing a typedef before the = struct? BTW, here's why I'm doing things this way ... I use the same struct in = different apps, some of which use CORBA, some of which use COM, & some of which use= both. The variables within the struct are carefully used so they generate = compatible data for both CORBA & COM, assuming the typedef mentioned above is = defined appropriately in both CORBA & COM .IDL files. I desperately want to = avoid having to define 2 different structs for CORBA & COM ... this is a very = large struct!!! =20 So I'm #include'ing one .H into both my CORBA & COM IDL files. I want to= do this within an interface, so the struct typedef is essentially given a = different name for CORBA than for COM, since one app will have both definitions. If the CORBA IDL compiler cannot be made to work with this approach, can = you suggest something better??? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From dmorgen@alum.mit.edu Thu Jan 14 21:44:36 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Thu, 14 Jan 1999 21:44:36 GMT Subject: [omniORB] Re: #include in .IDL file works incorrectly!!! In-Reply-To: <36a05c28.166031374@smtp.ne.mediaone.net> References: <366468EE.2615DB12@fairplay.no> <3or9uisp1n.fsf@neem.cam-orl.co.uk> <36a05c28.166031374@smtp.ne.mediaone.net> Message-ID: <36a16353.167867423@smtp.ne.mediaone.net> One other thing I've tried, which doesn't provide a solution ... use = #define's instead of the typedef & to override the struct's name. The IDL compiler= seems to use the #define when reading the #include'd file. However, it doesn't= put it into the .HH file. So any C++ source file #include'ing the .HH file, = thinking this will provide definitions for the CORBA stuff will be disappointed = when it comes to the struct ... it won't have the overridden name & type; the = solution is to provide redundant #define's (or perhaps in a #include ... assuming = the IDL compiler doesn't have problems with this ... which it probably will by generating a #include for a non-existent .HH file). Actually, the C++ = file, which #include's the .HH file will not compile because of the #include = created for a non-existent .HH file! BTW, I just confirmed that this approach works on the COM side, except = for the struct being defined outside the interface. However, a #define works appropriately (i.e. the IDL compiler applies it to the struct definition = code being generated), so it can be used to specify a unique struct name. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From rshoup@tumbleweed.com Fri Jan 15 02:15:26 1999 From: rshoup@tumbleweed.com (Randy Shoup) Date: Thu, 14 Jan 1999 18:15:26 -0800 Subject: [omniORB] SSL support status? References: <369D68AB.D4988563@tumbleweed.com> <3oiue97osj.fsf@neem.cam-orl.co.uk> Message-ID: <369EA4BE.B9D2F591@tumbleweed.com> Sai-Lai Lo wrote: > > Randy, > > >>>>> Randy Shoup writes: > > > There have been some rumors of a working IIOP over SSL transport with > > omniORB (http://www.orl.co.uk/omniORB/archives/1998-11/0041.html). We > > would be very interested in SSL support, and may have to develop it > > ourselves if we can't beg, borrow, or steal it. We would prefer, of > > course, to leverage the hard work of others here :-) > > I should be able to give you access to a version of omniORB with SSL > support in the next few days. Note that this version has not been subject > to vigorous testing and was done independent of the main development and > with omniORB_2.5.0. > > What I would like is to have your feedback on the API that we have added. > And of course any bug fixes you have done. Perfect. We've done some SSL stuff before, so hopefully we can give some constructive feedback. We'll also do the "vigorous testing" part :-), and would be happy to reintegrate the changes with 2.6.1 (or 2.7.0, if that becomes available soon). > > My intention is to integrate the stuff after the IIOP 1.1 work is done. > > > Is there a time-frame on when SSL support will be ready for prime > > time? The note I reference above says that you don't want to release it > > before IIOP1.1. Is IIOP1.1 required to get SSL to work with IIOP? > > The IIOP IOR extension to support SSL is defined in 1.1. So strictly > speaking omniORB should really talk IIOP 1.1 to get SSL to work but as far > as the message exchange is concern 1.0 will do. This was what I suspected. In my brief review of the OMG spec yesterday, it seemed like the IOR extensions are pretty much required for doing any sort of augmentation of the protocol (e.g., SSL, compression, etc.). It also seemed to me that the 1.1 IOR extensions might be required for introducing any alternate transport. I hope I am wrong, but I couldn't figure out how to shoehorn an alternate transport into an IIOP 1.0 profile, or similarly, how to give enough information through an IIOP 1.0 profile to help the ORB to make an intelligent decision between two transports. > > I have a bit of time at hand this week so I've started implementing > GIOP/IIOP 1.1. Once this is done, I may release a snapshot for people to > try out. That would be ideal. We'd be happy to beta test this. Thanks, -- Randy _________________________________________________________________ Randy Shoup (650)569-3682 Software Architect rshoup@tumbleweed.com Tumbleweed Software Corporation From bjornw@fairplay.no Fri Jan 15 12:55:51 1999 From: bjornw@fairplay.no (bjornw@fairplay.no) Date: 15 Jan 1999 13:55:51 +0100 Subject: [omniORB] Nasty omni_thread::sleep bug in posix.cc In-Reply-To: rshoup@tumbleweed.com's message of "Wed, 13 Jan 1999 19:46:51 -0800" References: <369D68AB.D4988563@tumbleweed.com> Message-ID: Hi there! If I'm calling omni_thread::sleep() with an argument greater that 2000 omni_thread:sleep() calls itself until my stack is full.... This only happens for platforms that do not use nanosleep(); Here is how it should be: void omni_thread::sleep(unsigned long secs, unsigned long nsecs /*=3D0*/) { ... if (nsecs > 2000) { // sleep(nsecs); // calls omni_thread::sleep(2000, 0); ::sleep(nsecs); // make sure we call correct sleep() } ... } bjornw> ------------------------------------------------------- Bj=F8rn Wennberg email: bjornw@fairplay.no=20 ms: +47 950 82 657 Senior Programmer phone: +47 22405538 FairPlay International AS fax: +47 22405539 From jlai@uswest.com Fri Jan 15 19:40:07 1999 From: jlai@uswest.com (Lai, Johnny) Date: Fri, 15 Jan 1999 12:40:07 -0700 Subject: [omniORB] Problem compiling 2.6.1 on HP-UX with aCC Message-ID: <93E5AA4FDA9FD011A53E00805FA74D430167F029@OMAEX01.mrg.uswest.com> I am having problem compiling 2.6.1 on HP-UX. When compiling posix.cc in the src/lib/omnithread directory, aCC gave these errors: aCC -c -g -I /opt/aCC/include -I /opt/HP-RT/usr/include +inst_v +DAportable -D_CMA_NOWRAPPERS_ -D_REENTRANT -DPthreadDraftVersion=4 -I. -I../../../include -D__hppa__ -D__hpux__ -D__OSVERSION __=10 -ldir posix.cc -o posix.o Error (future) 600: "/usr/include/stdio.h", line 79 # Type specifier is omitted; "int" is no longer assumed. typedef int64_t fpos64_t; /* 32bit position inside a file */ ^^^^^^^ Error 20: "/usr/include/stdio.h", line 79 # ',' expected before 'fpos64_t'. typedef int64_t fpos64_t; /* 32bit position inside a file */ ^^^^^^^^ .... .... The compile went fine until it got to the omnithread directory. Could this be an incompatibility between our pthread and aCC? Our pthread came with HP-RT developer's kit. Has anybody experienced similar problems? My system: HP-UX B.10.20 A 9000/829 HP aC++ Compiler S800 B3913DB A.01.07.01 HP-RT Developer's Kit B5487AA_APZ A.03.01 libcma.1: HP DCE/9000 1.5 Module: libcma.sl (Export) Date: Apr 29 1996 22:11:24 Thanks Johnny From gdd0@gte.com Fri Jan 15 20:12:33 1999 From: gdd0@gte.com (Gary D. Duzan) Date: Fri, 15 Jan 1999 15:12:33 -0500 Subject: [omniORB] Problem compiling 2.6.1 on HP-UX with aCC Message-ID: <199901152012.PAA22158@lion.gte.com> Just a guess from a quick look at the docs, but try adding the "-ext" flag to the compiler options. That may allow int64_t to be typedefed correctly. Gary Duzan GTE Laboratories In Message <93E5AA4FDA9FD011A53E00805FA74D430167F029@OMAEX01.mrg.uswest.com> , "Lai, Johnny" wrote: =>I am having problem compiling 2.6.1 on HP-UX. When compiling posix.cc in the =>src/lib/omnithread directory, aCC gave these errors: => =>aCC -c -g -I /opt/aCC/include -I /opt/HP-RT/usr/include +inst_v +DAportable =>-D_CMA_NOWRAPPERS_ -D_REENTRANT -DPthreadDraftVersion=4 -I. -I../../../include -D__hppa__ =>-D__hpux__ -D__OSVERSION __=10 -ldir posix.cc -o posix.o Error (future) 600: "/usr/include/stdio.h", line 79 # Type specifier is =>omitted; "int" is no longer assumed. typedef int64_t fpos64_t; /* 32bit position inside a file */ ^^^^^^^ Error 20: "/usr/include/stdio.h", line 79 # ',' expected before 'fpos64_t'. typedef int64_t fpos64_t; /* 32bit position inside a file */ ^^^^^^^^ .... =>.... => =>The compile went fine until it got to the omnithread directory. Could this =>be an incompatibility between our pthread and aCC? Our pthread came with =>HP-RT developer's kit. Has anybody experienced similar problems? => =>My system: =>HP-UX B.10.20 A 9000/829 =>HP aC++ Compiler S800 B3913DB A.01.07.01 =>HP-RT Developer's Kit B5487AA_APZ A.03.01 =>libcma.1: HP DCE/9000 1.5 Module: libcma.sl (Export) =>Date: Apr 29 1996 22:11:24 => =>Thanks =>Johnny => => From anders.ostling@neurope.ikea.com Sat Jan 16 18:04:47 1999 From: anders.ostling@neurope.ikea.com (Anders Vstling) Date: Sat, 16 Jan 1999 19:04:47 +0100 Subject: [omniORB] AIX runtime bomb Message-ID: <36A0D4BF.1E76C696@neurope.ikea.com> Hi AIX 4.2 RS/6000 (not PowerPC, only "Power") EGCS 1.1 Omniorb 2.6.1 (built using EGCS) My app bombs in (gdb) brea main Breakpoint 1 at 0x1000168c: file main.cxx, line 464. (gdb) r Starting program: /home/anos/acid/bin/acid Program received signal SIGSEGV, Segmentation fault. 0xd0311644 in pthread_key_create () (gdb) bt #0 0xd0311644 in pthread_key_create () #1 0xd031158c in pthread_key_create () #2 0xd0165538 in omni_thread::init_t::init_t () #3 0xd0167ef4 in global constructors keyed to omni_mutex::omni_mutex () #4 0xd01685e0 in _GLOBAL__FI_libomnithread_so () #5 0x100226ac in __do_global_ctors () #6 0x10022724 in __main () #7 0x10001688 in main () at main.cxx:455 #8 0x100001a0 in __start () (gdb) quit The program is running. Exit anyway? (y or n) y The program works fine on Linux /Anders From pooh@msu.ru Mon Jan 18 09:38:55 1999 From: pooh@msu.ru (Andrey Slepuhin) Date: Mon, 18 Jan 1999 12:38:55 +0300 (MEST) Subject: [omniORB] AIX runtime bomb In-Reply-To: <36A0D4BF.1E76C696@neurope.ikea.com> Message-ID: On 16-Jan-99 Anders Vstling wrote: > Hi > > AIX 4.2 RS/6000 (not PowerPC, only "Power") > EGCS 1.1 > Omniorb 2.6.1 (built using EGCS) > > My app bombs in > > (gdb) brea main > Breakpoint 1 at 0x1000168c: file main.cxx, line 464. > (gdb) r > Starting program: /home/anos/acid/bin/acid > > Program received signal SIGSEGV, Segmentation fault. > 0xd0311644 in pthread_key_create () > (gdb) bt >#0 0xd0311644 in pthread_key_create () >#1 0xd031158c in pthread_key_create () >#2 0xd0165538 in omni_thread::init_t::init_t () >#3 0xd0167ef4 in global constructors keyed to omni_mutex::omni_mutex () > >#4 0xd01685e0 in _GLOBAL__FI_libomnithread_so () >#5 0x100226ac in __do_global_ctors () >#6 0x10022724 in __main () >#7 0x10001688 in main () at main.cxx:455 >#8 0x100001a0 in __start () > (gdb) quit > The program is running. Exit anyway? (y or n) y > > The program works fine on Linux How do you link your program? The SIGSEGV above is typical when you link your program with non-thread-safe version of libc. Type dump -H and be sure that your program is linked against libc_r.a. Also note that by default egcs installation is not thread-safe. Regards, Andrey. From anders.ostling@neurope.ikea.com Mon Jan 18 11:34:43 1999 From: anders.ostling@neurope.ikea.com (Anders Vstling) Date: Mon, 18 Jan 1999 12:34:43 +0100 Subject: [omniORB] AIX runtime bomb References: Message-ID: <36A31C53.FA8281E5@neurope.ikea.com> Hi I found the problem in dejanews ! I had to specify -mthreads in the compiler command line, and now it magically works !!! /Anders Andrey Slepuhin wrote: > On 16-Jan-99 Anders Vstling wrote: > > Hi > > > > AIX 4.2 RS/6000 (not PowerPC, only "Power") > > EGCS 1.1 > > Omniorb 2.6.1 (built using EGCS) > > > > My app bombs in > > > > (gdb) brea main > > Breakpoint 1 at 0x1000168c: file main.cxx, line 464. > > (gdb) r > > Starting program: /home/anos/acid/bin/acid > > > > Program received signal SIGSEGV, Segmentation fault. > > 0xd0311644 in pthread_key_create () > > (gdb) bt > >#0 0xd0311644 in pthread_key_create () > >#1 0xd031158c in pthread_key_create () > >#2 0xd0165538 in omni_thread::init_t::init_t () > >#3 0xd0167ef4 in global constructors keyed to omni_mutex::omni_mutex () > > > >#4 0xd01685e0 in _GLOBAL__FI_libomnithread_so () > >#5 0x100226ac in __do_global_ctors () > >#6 0x10022724 in __main () > >#7 0x10001688 in main () at main.cxx:455 > >#8 0x100001a0 in __start () > > (gdb) quit > > The program is running. Exit anyway? (y or n) y > > > > The program works fine on Linux > > How do you link your program? The SIGSEGV above is typical when > you link your program with non-thread-safe version of libc. > Type dump -H and be sure that your program is > linked against libc_r.a. > > Also note that by default egcs installation is not thread-safe. > > Regards, > Andrey. -- -------------------------------------------------------- Anders �stling IKEA Corporate Technology Group Email: anders dot ostling AT neurope dot ikea dot com Phone: +46-42-25 73 45 Fax : +46-42-25 73 70 Mobil: +46-70-753 70 39 -------------------------------------------------------- From pooh@msu.ru Mon Jan 18 12:21:18 1999 From: pooh@msu.ru (Andrey Slepuhin) Date: Mon, 18 Jan 1999 15:21:18 +0300 (MEST) Subject: [omniORB] AIX runtime bomb In-Reply-To: <36A31C53.FA8281E5@neurope.ikea.com> Message-ID: On 18-Jan-99 Anders Vstling wrote: > Hi > > I found the problem in dejanews ! I had to specify -mthreads in the > compiler command line, and now it magically works !!! Well, -mthreads only implies -D_THREAD_SAFE at compile time and -lc_r -lpthreads at link time. But: *all* libraries should be rebuilt with -mthreads option. The same should be done for libstdc++ and libgcc. I use a custom patch that builds multilibbed egcs installation with thread-safe version of libraries. Also note that egcs-1.1 doesn't have thread-safe exception handling (IIRC this was fixed in egcs-1.1.1). Regards, Andrey. From S.Lo@orl.co.uk Mon Jan 18 18:00:02 1999 From: S.Lo@orl.co.uk (Sai-Lai Lo) Date: 18 Jan 1999 18:00:02 +0000 Subject: [omniORB] SSL support status? In-Reply-To: rshoup@tumbleweed.com's message of "Thu, 14 Jan 1999 18:15:26 -0800" References: <369D68AB.D4988563@tumbleweed.com> <3oiue97osj.fsf@neem.cam-orl.co.uk> <369EA4BE.B9D2F591@tumbleweed.com> Message-ID: <3ohfto31i5.fsf@neem.cam-orl.co.uk> OK! As promised, I have left a tar-ball of omniORB 2.5.0 + SSL stuff for Solaris 2.5 in ftp://ftp.orl.co.uk/pub/omniORB/omniORB_2.5.0_ssl.tar.gz. The SSL stuff uses SSLeay-0.9.0. Included in the tar-ball is the library and header files from SSLeay. The SSLeay executables are not included. The tar-ball compiles and the examples work for me. Documentation is still sparse. The source code and header files might be the best documentation. If you have questions and need some pointers, please contact Tatsuo Nakajima (CC:omniorb@orl.co.uk). As I said before, this is a snapshot of an ongoing development and has not been merged into the main development. Be prepared to dive in the source code if you encounter any problems. Regards, Sai-Lai >>>>> Randy Shoup writes: > Perfect. We've done some SSL stuff before, so hopefully we can give > some constructive feedback. > We'll also do the "vigorous testing" part :-), and would be happy to > reintegrate the changes with 2.6.1 (or 2.7.0, if that becomes available > soon). -- Dr. Sai-Lai Lo | Research Scientist | E-mail: S.Lo@orl.co.uk | Olivetti & Oracle Research Lab | 24a Trumpington Street Tel: +44 223 343000 | Cambridge CB2 1QA Fax: +44 223 313542 | ENGLAND From dmorgen@alum.mit.edu Mon Jan 18 21:42:36 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Mon, 18 Jan 1999 21:42:36 GMT Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: <36a05c28.166031374@smtp.ne.mediaone.net> References: <366468EE.2615DB12@fairplay.no> <3or9uisp1n.fsf@neem.cam-orl.co.uk> <36a05c28.166031374@smtp.ne.mediaone.net> Message-ID: <36a6a90e.123601759@smtp.ne.mediaone.net> My email was down for awhile, and I lost some messages. If anybody = responded to my messages, I'd appreciate it if you re-send the messages. Thanks! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From mcfadden@dstc.edu.au Tue Jan 19 03:40:47 1999 From: mcfadden@dstc.edu.au (Ted McFadden) Date: Tue, 19 Jan 1999 13:40:47 +1000 (EST) Subject: [omniORB] 2.6.1 / error in code generated for unions... 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-33463914-916717247=:2710 Content-Type: TEXT/PLAIN; charset=US-ASCII (This bug did not turn up in a search of the archive, please disregard if it is a known problem) For unions like: union switch(long){ case 2: string aString; }; the generated code for getting/setting the discriminator is: CORBA::Long _d () const { return pd__d;} void _d(CORBA::Long _value) {} // EMPTY?? The union can still be set to 2 by calling aString(*) and the _default value but nothing else. Most of the copying and streaming code generated appears to be prepared to handle the other values if they could be set. There is an attached UnionTrouble.idl file that illustrates the problem with a few simple unions. One other thing, the legal: union bad switch(long){ case 1: case 2: string test; }; will not compile, complaining about redefinitions. Cheers, Ted. -- Ted McFadden http://www.dstc.edu.au/BDU/staff/ted-mcfadden.html DSTC Level 7, GPS Building 78, Staff House Road The University of Queensland St Lucia 4072 +61 7 3365-4310 ---559023410-33463914-916717247=:2710 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="UnionTrouble.idl" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="UnionTrouble.idl" DQptb2R1bGUgVW5pb25Ucm91YmxlICB7DQoNCiAgLy9maXJzdCB0ZXN0IGNh c2UgdGFrZW4gZnJvbSBidWcgcmVwb3J0ICMzNA0KDQoNCiAgLy8gZ2VuZXJh dGVkIF9kKENPUkJBOjpCb29sZWFuKSBpZ25vcmVzIGl0cyBhcmcsIGNhbid0 DQogIC8vIHNldCBkaXNjcmltaW5hdG9yLCBjYW4gb25seSBzZXQgdG8gRkFM U0UgYnkgY2FsbGluZw0KICAvLyBfZGVmYXVsdCgpDQoNCiAgdW5pb24gWCBz d2l0Y2ggKGJvb2xlYW4pIHsNCiAgICBjYXNlIFRSVUU6IHNob3J0IHM7DQog IH07DQoNCiAvLyBfZCBpZ25vcmVzIGFyZywgY2FuIG9ubHkgc2V0IGRpc2Ny aW1pbmF0b3IgdG8gLTIxNDc0ODM2NDcNCiAvLyB2aWEgX2RlZmF1bHQoKSBv ciAyIHZpYSAgc3RyaW5nX2Zvcl90d28oLi4uKS4NCg0KICB1bmlvbiBDaG9v c2VMb25nIHN3aXRjaChsb25nKXsNCiAgICBjYXNlIDI6IHN0cmluZyBzdHJp bmdfZm9yX3R3bzsNCiAgfTsNCg0KICBlbnVtIENob2ljZSB7IG9uZSwgdHdv LCB0aHJlZSwgZm91ciAgfTsNCiAgDQogIHVuaW9uIENob29zZU9uZSBzd2l0 Y2ggKCBDaG9pY2UgKSB7DQogICAgIGNhc2UgdHdvOiBzdHJpbmcgZm9yX3R3 bzsNCiAgfTsNCg0KLy8gIHdpbGwgbm90IGNvbXBpbGUgDQovLyAgdW5pb24g YmFkIHN3aXRjaChsb25nKXsNCi8vICAgICBjYXNlIDE6DQovLyAgICAgY2Fz ZSAyOiBzdHJpbmcgdGVzdDsNCi8vICB9Ow0KfTsNCg0K ---559023410-33463914-916717247=:2710-- From S.Lo@orl.co.uk Tue Jan 19 12:11:39 1999 From: S.Lo@orl.co.uk (Sai-Lai Lo) Date: 19 Jan 1999 12:11:39 +0000 Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: dmorgen@alum.mit.edu's message of "Thu, 14 Jan 1999 21:20:33 GMT" References: <366468EE.2615DB12@fairplay.no> <3or9uisp1n.fsf@neem.cam-orl.co.uk> <36a05c28.166031374@smtp.ne.mediaone.net> Message-ID: <3o90ezbgxw.fsf@neem.cam-orl.co.uk> David, I guess what you are trying to do is something like this in pure OMG IDL. // File S.IDL // OMG IDL struct X { string A; char B; }; // File MAIN.IDL #include "S.IDL" interface I { X op(); }; The complication is you want the definition of struct X to be done in a single source file for both COM and CORBA. 1. Remember, the IDL compiler handle all the #include files only as IDL files so any C++ specific constructs in the files would not be recognised. 2. I suppose it is a bug that the compiler translate something like this: interface I { #include "S.IDL" X op(); }; into #include "S.hh" class I { .... }; Hence relocate the #include out of the context it is used in the IDL. However, it is difficult to detect this and generate #include in the output at the right context. 3. I don't know if I have an answer to achieve what you want. One possibility may be to define a single IDL file with appropriate #if to separate OMG IDL specific and COM IDL specific part while sharing as much as possible. Regards, Sai-Lai >>>>> David Morgenlender writes: > I'm trying to #include a .H file into my .IDL file. But the IDL compiler is > having problems: > 1. If I do the #include within an interface, I get a "can't parse statement" > error & the compiler (omniidl2) crashes with a system exception. > 2. So, for testing purposes, I moved the #include outside any interface & tried > again. I preceded the #include with a typedef statement, defining a type used > by the .H file. This compiled without error, but generated incorrect code, e.g. > in the .HH file: > a. The #include statement is put at the front of the .HH file, while the > typedef is placed later, AFTER the #include, which requires it. > b. The #include is for x.HH, when it should be for x.H. > How can I get the IDL compiler to do what I need, which is handle a struct > defined within an interface, via a .H file, placing a typedef before the struct? > BTW, here's why I'm doing things this way ... I use the same struct in different > apps, some of which use CORBA, some of which use COM, & some of which use both. > The variables within the struct are carefully used so they generate compatible > data for both CORBA & COM, assuming the typedef mentioned above is defined > appropriately in both CORBA & COM .IDL files. I desperately want to avoid > having to define 2 different structs for CORBA & COM ... this is a very large > struct!!! > So I'm #include'ing one .H into both my CORBA & COM IDL files. I want to do > this within an interface, so the struct typedef is essentially given a different > name for CORBA than for COM, since one app will have both definitions. > If the CORBA IDL compiler cannot be made to work with this approach, can you > suggest something better??? > ======================================================= > Dave Morgenlender > e-mail: dmorgen@alum.mit.edu > ======================================================= -- Dr. Sai-Lai Lo | Research Scientist | E-mail: S.Lo@orl.co.uk | Olivetti & Oracle Research Lab | 24a Trumpington Street Tel: +44 223 343000 | Cambridge CB2 1QA Fax: +44 223 313542 | ENGLAND From kai@oxford.demon.co.uk Tue Jan 19 12:13:14 1999 From: kai@oxford.demon.co.uk (Kai Chen) Date: Tue, 19 Jan 1999 12:13:14 +0000 Subject: [omniORB] OmniOrb - ODBMS adaptors ??? Message-ID: <36A476DA.D6F8DBF8@oxford.demon.co.uk> Has anybody had any experience in using one of the Object Databases (e.g. O2, Objectivity and ObjectStore) with OmniORB? Any comments are appreciated. Thanks very much. Kai Chen Oxford Forecasting Services 58 St. Aldates Oxford OX1 1ST UK Tel: +44 (0) 1865 249002 Fax: +44 (0) 1865 200565 E-mail: kai@oxford.demon.co.uk From dmorgen@alum.mit.edu Tue Jan 19 13:59:20 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Tue, 19 Jan 1999 13:59:20 GMT Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: <3o90ezbgxw.fsf@neem.cam-orl.co.uk> References: <366468EE.2615DB12@fairplay.no> <3or9uisp1n.fsf@neem.cam-orl.co.uk> <36a05c28.166031374@smtp.ne.mediaone.net> <3o90ezbgxw.fsf@neem.cam-orl.co.uk> Message-ID: <36ab858c.180055749@smtp.ne.mediaone.net> Sai-Lai, >I guess what you are trying to do is something like this in pure OMG = IDL. > >// File S.IDL >// OMG IDL >struct X { > string A; > char B; >}; > > >// File MAIN.IDL >#include "S.IDL" > >interface I { > X op(); >}; Almost: 1. I'm doing: typedef struct ... But I could live with the way you have it. 2. The struct is being used as a parameter type, not a return value. >The complication is you want the definition of struct X to be done in a >single source file for both COM and CORBA. > >1. Remember, the IDL compiler handle all the #include files only as IDL > files so any C++ specific constructs in the files would not be > recognised. That's not a problem given the nature of this particular struct. Among = other things, all variables must be fixed length ... so no "string", = variable-length array, etc. >2. I suppose it is a bug that the compiler translate something like = this: > > interface I { > #include "S.IDL" > X op(); > }; > > into > #include "S.hh" > > class I { > .... > }; > > Hence relocate the #include out of the context it is used in the IDL. > However, it is difficult to detect this and generate #include in the > output at the right context. This bug is annoying, but not fatal. >3. I don't know if I have an answer to achieve what you want. > One possibility may be to define a single IDL file with appropriate > #if to separate OMG IDL specific and COM IDL specific part while > sharing as much as possible.=20 The difference between this & my solution is that in my solution, the differences are handled by using typedef (& possibly #if) in the invoking= source file, while your approach puts everything in the #include'd file, except = the #define's. However, both approaches have problems with the way the = compiler currently works: The compiler generated incorrect code, e.g. in the .HH file: a. The #include statement is put at the front of the .HH file, while = the typedef is placed later, AFTER the #include, which requires it. b. The #include is for x.HH, which is not generated by the compiler & = does not exist. =20 c. There is no #include for x.H. d. The struct definition does not exist for any source file created by= the compiler! It's not in any compiler output file. It's only in the = original .H file ... but this is not #include'd anywhere. So the compiler-produced = source files will not compile! Neither will any application source file, which #include's the compiler-produced header files. e. Any #define in the main .IDL file is lost! My playing around with = it, I was able to determine the compiler used it when processing x.H. However,= it's totally lost after the IDL compilation! f. The typedef in the main .IDL file is not lost. However, it is = placed in the main .HH file AFTER the #include of x.HH, where it doesn't do any = good. I can kludge around the problems both in my application source code & the compiler-generated sourse code. =20 a. I can create a dummy x.HH file, which is already #include'd by the compiler-generated files & will be #include'd by my app. b. The dummy x.HH file will redundantly have the relevant typedef's & #define's as are in the main .IDL file. c. The dummy x.HH file then #include's x.H. But even this still has a problem. There is now a redundant typedef: = the one I put in x.HH & the one the IDL compiler puts in the main .HH file in the = wrong place. I'm not sure if this will cause a C++ compiler error. I may be able to get tye typedef problem by using redundant #define's = instead. I think my approach covers everything else; but haven't tried it. IAE, = it's VERY kludgey. It requires redundant #define's, which I hate to do, since= it tends to lead to future errors. Do you think this will work? Do you have any better suggestions? ------------------------------------------------------------------------- I've thought of one other strategy, which avoids all the CORBA issues, = but is somewhat ugly. On the COM side, I really need to use the #include in the= .IDL file; this allows any COM client to use the struct, whether it be C++ or= VB, without any redundant struct definitions, such as in VB. In the CORBA = server application I also want to use the same .H file for cleanliness & = avoiding future errors. =20 However, I can take a different approach when handling the struct between= COM server & client. I can pass the struct as a fixed-length array of bytes.= I can layer functions, such that the COM server application code never sees the= kludge ... it will #include x.H & just see structs as calling parameters. The = IDL file never sees a definition of the struct. My interface code on the COM = server can at least insure the size of the array matches the expected size of the = struct to reduce, but not eliminate, the chances of use of inconsistent struct definitions, etc. Opinions? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From djr@orl.co.uk Tue Jan 19 17:45:25 1999 From: djr@orl.co.uk (David Riddoch) Date: Tue, 19 Jan 1999 17:45:25 +0000 (GMT) Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: <36ab858c.180055749@smtp.ne.mediaone.net> Message-ID: David, The IDL compiler treats #includes in a special way because it assumes that what you are including will be IDL, and also that you will compile this IDL separately. If you want #includes to work the way you expect them to then you could try running the C pre-processor over your IDL file separately. You will then need to remove the information that the C pre-processor adds before running it through the IDL compiler. The C pre-processor adds lines that start with a # and contain info about what file and line number it is currently at. The advantage of this approach is that the IDL compiler will see a single pure IDL file, and will define your structure in C++ for you. All you have to do is write a script to automate it! I hope this solution works for you. Cheers, David From c1040@azfms.com Tue Jan 19 18:49:58 1999 From: c1040@azfms.com (Rusty Carruth) Date: Tue, 19 Jan 1999 11:49:58 -0700 Subject: [omniORB] #include in .IDL file works incorrectly!!! Message-ID: <9901191849.AA02706@fmsserv99.azfms.com> > > The advantage of this approach is that the IDL compiler will see a single > pure IDL file, and will define your structure in C++ for you. All you have > to do is write a script to automate it! > and it can be done automatically in the makefile (you ARE using make files, right?). If I were doing it, I'd run the c preprocessor on a file, do some diffs, and make a sed or awk or grep or perl script to remove the new stuff added to the file, then stick that into the makefile... rusty From dmorgen@alum.mit.edu Tue Jan 19 21:17:08 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Tue, 19 Jan 1999 21:17:08 GMT Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: References: Message-ID: <36a4f5d6.12845476@smtp.ne.mediaone.net> David, >The IDL compiler treats #includes in a special way because it assumes = that >what you are including will be IDL, and also that you will compile this >IDL separately. > >If you want #includes to work the way you expect them to then you could >try running the C pre-processor over your IDL file separately. You will >then need to remove the information that the C pre-processor adds before >running it through the IDL compiler. The C pre-processor adds lines that >start with a # and contain info about what file and line number it is >currently at. > >The advantage of this approach is that the IDL compiler will see a = single >pure IDL file, and will define your structure in C++ for you. All you = have >to do is write a script to automate it! > >I hope this solution works for you. Thanks for the suggestion. That sounds like it should work. But it will= take more time than I have to spend on it now. So for now I'm going to use = the kludge of treating the struct as an array of bytes as far as CORBA is = concerned. I'll write some low level code to hide this from the app, which will only= deal with the struct. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From dmorgen@alum.mit.edu Tue Jan 19 21:21:15 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Tue, 19 Jan 1999 21:21:15 GMT Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: <9901191849.AA02706@fmsserv99.azfms.com> References: <9901191849.AA02706@fmsserv99.azfms.com> Message-ID: <36a5f662.12985742@smtp.ne.mediaone.net> Rusty, =20 >> The advantage of this approach is that the IDL compiler will see a = single >> pure IDL file, and will define your structure in C++ for you. All you = have >> to do is write a script to automate it! >>=20 > >and it can be done automatically in the makefile (you ARE using >make files, right?). If I were doing it, I'd run the c preprocessor >on a file, do some diffs, and make a sed or awk or grep or perl=20 >script to remove the new stuff added to the file, then stick that >into the makefile... I'm only using makefiles indirectly. I'm using the Visual C++ 5 IDE. So= I'd have to figure out how to customize the build in the IDE to do this; but= I believe that is readily doable. However, I don't have time to deal with this approach now, especially = writing the script (& having to learn awk, or whatever). So I'm going to take = the Q&D approach of treating the struct as an array of bytes at the low level & = for CORBA. The higher level app code will still deal with it as a struct. Thanks for the suggestion. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From c1040@azfms.com Tue Jan 19 21:29:08 1999 From: c1040@azfms.com (Rusty Carruth) Date: Tue, 19 Jan 1999 14:29:08 -0700 Subject: [omniORB] #include in .IDL file works incorrectly!!! Message-ID: <9901192129.AA05762@fmsserv99.azfms.com> > However, I don't have time to deal with this approach now, especially writing > the script (& having to learn awk, or whatever). So I'm going to take the Q&D well, its not THAT hard to make a script: if the lines you want to remove look like this: ----begin file---- good stuff...; #line 2 /* the bad stuff */ #debuginfo foo /* more bad stuff */ some good stuff; #hellothere now /* the last bad thing */ ----end of file------ then you could just use a grep (grep is available for windows as well as unix - go get gnugrep) like this: cat thefile.c | grep -v '^#(line)|(debuginfo)|(hellothere) ' > theoutputfile.cpp in fact, you don't really have to put it into your make file if you don't mind making it manually... (just have theoutputfile.cpp rely on your original file - the one you pre process with the c preprocessor to get 'thefile.c' - but don't tell it how to make it and you'll get forcefully reminded to update the file when needed ;-) Or, use m4 instead of the c preprocessor... rusty From dmorgen@alum.mit.edu Tue Jan 19 21:44:57 1999 From: dmorgen@alum.mit.edu (David Morgenlender) Date: Tue, 19 Jan 1999 21:44:57 GMT Subject: [omniORB] #include in .IDL file works incorrectly!!! In-Reply-To: <9901192129.AA05762@fmsserv99.azfms.com> References: <9901192129.AA05762@fmsserv99.azfms.com> Message-ID: <36a7fc6b.14530386@smtp.ne.mediaone.net> Rusty, >then you could just use a grep (grep is available for windows as >well as unix - go get gnugrep) like this: > >cat thefile.c | grep -v '^#(line)|(debuginfo)|(hellothere) ' > = theoutputfile.cpp Thanks. I didn't realize grep could do such things ... the DOS greps = I've used could not. There's no 'cat' in Windows or DOS; but that's easy to = workaround. >Or, use m4 instead of the c preprocessor... What's m4? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Dave Morgenlender e-mail: dmorgen@alum.mit.edu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D From c1040@azfms.com Tue Jan 19 22:20:01 1999 From: c1040@azfms.com (Rusty Carruth) Date: Tue, 19 Jan 1999 15:20:01 -0700 Subject: [omniORB] #include in .IDL file works incorrectly!!! Message-ID: <9901192220.AA06287@fmsserv99.azfms.com> > Thanks. I didn't realize grep could do such things ... the DOS greps I've used > could not. There's no 'cat' in Windows or DOS; but that's easy to workaround. Its either grep or egrep that has the '-v' (invert) flag. REALLY handy... > >Or, use m4 instead of the c preprocessor... > > What's m4? > m4 is a macro processor program. Its used a lot by folks doing sendmail configuration (and possibly smail, I don't know). (Used for reasons I won't bore anyone with ;-). Anyway, its a macro processor. Here's part of the man page on my Solaris machine: m4(1) User Commands m4(1) NAME m4 - macro processor SYNOPSIS /usr/ccs/bin/m4 [ -e ] [ -s ] [ -B int ] [ -H int ] [ -S int ] [ -T int ] [ -Dname [=val] ] ... [ -U name ] ... [ file ... ] /usr/xpg4/bin/m4 [ -e ] [ -s ] [ -B int ] [ -H int ] [ -S int ] [ -T int ] [ -Dname [=val] ] ... [ -U name ] ... [ file ... ] AVAILABILITY /usr/ccs/bin/m4 SUNWcsu /usr/xpg4/bin/m4 SUNWxcu4 DESCRIPTION The m4 command is a macro processor intended as a front end for C, assembler, and other languages. Each of the argument files is processed in order; if there are no files, or if a file is -, the standard input is read. The processed text is written on the standard output. Macro Syntax Macro calls have the form: name(arg1,arg2, ..., argn) The ( must immediately follow the name of the macro. If the name of a defined macro is not followed by a (, it is deemed to be a call of that macro with no arguments. Potential macro names consist of alphanumeric characters and under- score (_), where the first character is not a digit. Leading unquoted blanks, TABs, and NEWLINEs are ignored while collecting arguments. Left and right single quotes are used to quote strings. The value of a quoted string is the string stripped of the quotes. ...LOTS of stuff deleted.... Anyway, its probably easier to just run your stuff through the c pre processor, since that's what you're doing anyway... rusty. From storm@ifad.dk Wed Jan 20 14:45:55 1999 From: storm@ifad.dk (Ole Storm) Date: Wed, 20 Jan 1999 15:45:55 +0100 Subject: [omniORB] Condition Variables on NT and Linux Message-ID: <36A5EC23.F7D52E4F@ifad.dk> Greetings all, I am using omniORB 2.6.1 on Windows NT 4.0 and on Linux. I am experiencing some troubles with condition variables which I am using in the following way: Client applications and my server application synchronize at certain points using a condition variable. I.e. if some data (a list of events in this case) is not available at the time of request, the client thread is set to wait by a call to wait() on a global omni_condition variable held by the server. When the server provides the data all waiting clients are awakened by calling broadcast() on the condition variable. It should be noted that the client and server are running in separate processes. Problem 1: On WindowsNT the client threads are apparently never awakened by the call to broadcast(). On Linux things works OK - waiting clients are actually awakened. In the mailing list-archive I have seen this problem described in articles: http://www.orl.co.uk:80/omniORB/archives/1998-07/0076.html http://www.orl.co.uk:80/omniORB/archives/1998-04/0116.html however, I thought that this problem was already fixed in omniORB 2.6.1 Problem 2: On Linux I experience a minor problem too. If, at some point in time, two clients have been waiting on the same condition variable, and then at a later point in time one of the two clients terminate execution (it is terminated nicely, i.e. it is not interrupted while waiting!), then later calls to broadcast() fails to awaken the remaining client. The client is not awakened until a second client thread is started and set to wait on the condition variable. It seems that broadcast() can not handle if the number of clients using a condition variable is decreased at some point in time. It should be noted that I have compiled omniORB 2.6.1 with egcs1.1.1 Any ideas as to what I may be doing wrong??? Best regards, Ole. --------------------------------------------------------------- Ole Storm The Institute of Applied Computer Science (IFAD) Forskerparken 10, DK-5230 Odense M, Denmark Phone: +45 6315 7134, Fax: +45 6593 2999, Email: storm@ifad.dk WWW: http://www.ifad.dk --------------------------------------------------------------- From zeynep@top.cis.syr.edu Wed Jan 20 19:52:50 1999 From: zeynep@top.cis.syr.edu (Zeynep Ozdemir) Date: Wed, 20 Jan 1999 14:52:50 -0500 (EST) Subject: [omniORB] omniORB2.6.1 on irix6.3/4/5 Message-ID: Hi, does anybody use omniorb on sgi machine say irix 6.3/5? I compiled it on irix6.5 with mipsPro cc version 7.2.1.1m when I tried eg1/eg2 or nameclt but during runtime, I am getting Error: unresolvable symbol in /u/zeynep/omniORB_2.6.1/lib/mips_irix_6.5_n32/libomniORB2.so: allowFile__10gateKeeper Error: unresolvable symbol in /u/zeynep/omniORB_2.6.1/lib/mips_irix_6.5_n32/libomniORB2.so: denyFile__10gateKeeper rld: Fatal Error: this executable has unresolvable symbols can anybody help me to solve this? regards, Zeynep Odcikin-Ozdemir Syracuse University From andrew.king@mocom.co.nz Thu Jan 21 04:36:36 1999 From: andrew.king@mocom.co.nz (Andrew King) Date: Thu, 21 Jan 1999 17:36:36 +1300 Subject: [omniORB] Omniorb and Java Message-ID: <36A6AED4.908FD436@mocom.co.nz> Hi, How do I go about using OmniOrb with Java objects?. I understand (from looking at the documentation) that Omniorb only provides an IDL to C++ generator. If Java (or infact any language) can be used how much effort is required. Please excuse my ignorance as I'm totally new to CORBA/OmniOrb etc. Cheers Andrew. -- _______________________________________________________________________ Andrew King Phone: (+64 4) 473 1480 OO Developer Fax: (+64 4) 473 1515 Mocom Corporation (NZ) Ltd, 10 Brandon Street, Wellington. email: andrew.king@mocom.co.nz PO Box 10-278, Wellington. *********************************************************************** This communication is confidential to MOCOM and is intended for use only by the addressee. MOCOM does not represent that this communication (including any files attached) is free from computer viruses or other faults or defects. MOCOM accepts no responsibility or liability for information, errors or omissions in this communication or use or misuse thereof or any act done or omitted to be done in connection with same. It is the responsibility of any person opening files attached to this communication to scan those files for computer viruses. *********************************************************************** From storm@ifad.dk Thu Jan 21 10:16:24 1999 From: storm@ifad.dk (Ole Storm) Date: Thu, 21 Jan 1999 11:16:24 +0100 Subject: [omniORB] Condition varaibles - follow up... Message-ID: <36A6FE78.ECE2C9E2@ifad.dk> This is a multi-part message in MIME format. --------------C4213DF93B80E2AAEF4EF518 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, Yesterday I mentioned a problem with condition variables on Windows NT. To clarify my problems I have made a small example, a simple bounded buffer that can be accessed from one or more producer and consumer processes. The code is attached to this mail. When the buffer process is run on Linux everything works OK. Producers are set to wait if the buffer is full and consumers are set to wait if the buffer is empty. Waiting threads _are_ awakened when the state of the buffer changes. On Windows NT 4.0, however, a process that has been set to wait is never awakened!!! Why is that?? Could someone _please_ try out my example and explain to me why this does not work om WindowsNT. Best regards, Ole. --------------------------------------------------------------- Ole Storm The Institute of Applied Computer Science (IFAD) Forskerparken 10, DK-5230 Odense M, Denmark Phone: +45 6315 7134, Fax: +45 6593 2999, Email: storm@ifad.dk WWW: http://www.ifad.dk --------------------------------------------------------------- --------------C4213DF93B80E2AAEF4EF518 Content-Type: text/plain; charset=us-ascii; name="buffer.idl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="buffer.idl" typedef short BufferItem; interface Buffer { BufferItem GetItem(); void PutItem(in BufferItem item); }; --------------C4213DF93B80E2AAEF4EF518 Content-Type: text/plain; charset=us-ascii; name="buffer.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="buffer.cc" #include "buffer.hh" #include "omnithread.h" #include #define BUF_SIZE 10 // Declaration of condition variables: static omni_mutex cond_mutex; static omni_condition empty_buf(&cond_mutex); static omni_condition full_buf(&cond_mutex); static omni_mutex mutex_region; class Buffer_i : public virtual _sk_Buffer // // Implementation of the Buffer interface // { public: Buffer_i() : index(0) {} BufferItem GetItem ( ); void PutItem ( BufferItem ); private: // The fixed size buffer: BufferItem TheBuffer[BUF_SIZE]; int index; }; BufferItem Buffer_i::GetItem() { while(!index){ // No items awailable. Wait on the condition varaible empty_buf: empty_buf.wait(); } mutex_region.lock(); BufferItem itm = TheBuffer[--index]; cout << "Returned item: " << itm << "\n" << flush; // Signal one of the possible waiting threads on PutItem() full_buf.signal(); mutex_region.unlock(); return itm; } void Buffer_i::PutItem(BufferItem it) { while(index >= BUF_SIZE){ cout << "PutItem() waiting to put an item..."; full_buf.wait(); if(index < BUF_SIZE) cout << "OK\n"; else cout << "Retry\n"; } mutex_region.lock(); // OK to put an item now: TheBuffer[index++] = it; cout << "Got item: " << it << "\n"; // Signal one of the possible waiting threads on GetItem() empty_buf.signal(); mutex_region.unlock(); } CORBA::ORB_var _the_orb; CORBA::BOA_var _the_boa; main(int argc, char *argv[]) { _the_orb = CORBA::ORB_init(argc, argv, "omniORB2"); _the_boa = _the_orb->BOA_init(argc, argv, "omniORB2_BOA"); Buffer_i *theBuffer = new Buffer_i(); theBuffer->_obj_is_ready(_the_boa); Buffer_var buf_ref = theBuffer->_this(); CORBA::String_var pp = _the_orb->object_to_string(buf_ref); cerr << pp << "\n" << flush; _the_boa->impl_is_ready(0); // // Create a file for the object reference: // ofstream newfile; // newfile.open("object.string"); // if(newfile.good()) { // newfile << (char *)pp << endl; // } // else{ // err = "Could not create file object.string\n"; // } // newfile.close(); return 0; } --------------C4213DF93B80E2AAEF4EF518 Content-Type: text/plain; charset=us-ascii; name="consumer.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="consumer.cc" #ifdef _MSC_VER #define SLEEP(n) Sleep(n) #else #include // For usleep() #define SLEEP(n) usleep(1000*n) #endif #include #include "buffer.hh" CORBA::ORB_var _the_orb; CORBA::BOA_var _the_boa; main(int argc, char *argv[]) { _the_orb = CORBA::ORB_init(argc, argv, "omniORB2"); _the_boa = _the_orb->BOA_init(argc, argv, "omniORB2_BOA"); if (argc < 2) { cerr << "usage: consumer