From fredrik.jonsson@sea.ericsson.se Wed May 21 18:00:46 1997 Return-Path: Received: from glacier.wise.edt.ericsson.se by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA28180; Wed, 21 May 1997 18:00:42 +0100 Received: from sea.ericsson.se (mira.sea.ericsson.se [193.186.193.9]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id TAA28720 for ; Wed, 21 May 1997 19:00:34 +0200 (MET DST) Received: from stpc139.sea.ericsson.se by sea.ericsson.se with SMTP (1.40.112.8/16.2) id AA227784029; Wed, 21 May 1997 19:00:29 +0200 Received: by stpc139.sea.ericsson.se with Microsoft Mail id <01BC6618.17B1AE60@stpc139.sea.ericsson.se>; Wed, 21 May 1997 18:52:12 +0200 Message-Id: <01BC6618.17B1AE60@stpc139.sea.ericsson.se> From: Fredrik Jonsson To: "'omniORB2'" Subject: Port available for VxWorks? Date: Wed, 21 May 1997 18:52:09 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 389 Status: OR Is there anyone who have tried porting omniORB2 for VxWorks? (Seems like a few POSIX interfaces are missing in order to build successfully...) --- Fredrik Jonsson, mailto:fredrik.jonsson@sea.ericsson.se T.E.-WG21 V.M.-X3J16 94-97, OO SW Specialist Ericsson Ericsson Austria AG, Pottendorfer Strasse 25-27, A-1121 Vienna Austria Telephone +43 (1) 81100 5345, Facsimile +43 (1) 81100 4686 From S.Lo@orl.co.uk Wed May 21 18:16:54 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA28338; Wed, 21 May 1997 18:16:39 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id SAA26727; Wed, 21 May 1997 18:16:35 +0100 Date: Wed, 21 May 1997 18:16:35 +0100 Message-Id: <199705211716.SAA26727@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Port available for VxWorks? In-Reply-To: <01BC6618.17B1AE60@stpc139.sea.ericsson.se> References: <01BC6618.17B1AE60@stpc139.sea.ericsson.se> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 852 Status: OR >>>>> Fredrik Jonsson writes: > Is there anyone who have tried porting omniORB2 for VxWorks? (Seems > like a few POSIX interfaces are missing in order to build successfully...) Interesting. Can you give me a list of what is missing? Other people have expressed an interest in this port. We don't have access to VxWork but we have ported omniORB2 to our own embedded kernel. Drop us a message if you need any help. By the way, if you are currently doing a port, please drop us a line. This is the kind of information I would like to put into a FAQ. Regards, Sai-Lai Lo -- 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 brian.burton@burton-computer.com Wed May 21 18:40:43 1997 Return-Path: Received: from bcc01.burton-computer.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA28544; Wed, 21 May 1997 18:40:29 +0100 Received: from bcc01.burton-computer.com (localhost [127.0.0.1]) by bcc01.burton-computer.com (8.8.5/8.8.5) with SMTP id NAA07588; Wed, 21 May 1997 13:40:20 -0400 Sender: brian@bcc01.burton-computer.com Message-ID: <33833384.762074EB@burton-computer.com> Date: Wed, 21 May 1997 13:40:20 -0400 From: Brian Burton Organization: Burton Computer Corporation X-Mailer: Mozilla 3.01Gold (X11; U; Linux 2.0.27 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk CC: Jake Hamby Subject: Re: Port available for VxWorks? References: <01BC6618.17B1AE60@stpc139.sea.ericsson.se> <199705211716.SAA26727@santaka.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 524 Status: OR Sai-Lai Lo wrote: > > By the way, if you are currently doing a port, please drop us a line. This > is the kind of information I would like to put into a FAQ. > Jake Hamby and I (mostly Jake at the moment) are porting omniORB to BeOS DR9 (http://www.be.com). We are currently being delayed by C++ compiler bugs. ++Brian -- Brian Burton Custom Software Development Burton Computer Corporation Java, C++, Orbix, Tuxedo brian.burton@burton-computer.com OO Consulting and Mentoring From brian.burton@burton-computer.com Tue May 27 14:40:39 1997 Return-Path: Received: from bcc01.burton-computer.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA01167; Tue, 27 May 1997 14:33:34 +0100 Received: from bcc01.burton-computer.com (localhost [127.0.0.1]) by bcc01.burton-computer.com (8.8.5/8.8.5) with SMTP id JAA05069 for ; Tue, 27 May 1997 09:33:23 -0400 Sender: brian@bcc01.burton-computer.com Message-ID: <338AE2A3.6E52F374@burton-computer.com> Date: Tue, 27 May 1997 09:33:23 -0400 From: Brian Burton Organization: Burton Computer Corporation X-Mailer: Mozilla 3.01Gold (X11; U; Linux 2.0.27 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omnithread.h and exceptions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1936 Status: OR I noticed that omnithread does not use exceptions to report errors. Is this a deliberate design decision? If not, I'd like to propose that the classes be modified to report errors using exceptions. I think this would greatly improve the interface. For example, omni_condition::timed_wait() could simply return a bool (TRUE if signalled, FALSE if timed out) and throw an exception if some error prevented completion of the call. try { omni_mutex_lock lock(mutex); ... do something ... while (!condition.timed_wait(...)) { ... some periodic task before trying again ... } ... condition satisfied ... } catch (omni_mutex_error) { ... mutex operation failed ... } catch (omni_condition_error) { ... condition operation failed ... } This is easier to read and (with a good C++ compiler) faster than adding additional error checking after every call. It seems to me (please tell me if I'm wrong) that errors on these calls should be very rare and most likely would require fairly drastic measures to compensate for. If so, using exceptions makes even more sense since we can keep the main code path uncluttered and allow exceptions to propogate fairly high in the call chain before being handled (i.e. most code would not need a try block). Many other functions could be declared void since they logically don't need to return anything (wait, signal, lock, unlock, etc). I realize that this would require some modification to the core of omniORB that uses the monithread library. But I think it would be well worth the effort in the long run by producing cleaner code. I would be happy to offer a revised omnithread.h and an exception heirarchy if the authors are interested. All the best, ++Brian -- Brian Burton Custom Software Development Burton Computer Corporation Java, C++, Orbix, Tuxedo brian.burton@burton-computer.com OO Consulting and Mentoring From brian.burton@burton-computer.com Tue May 27 14:40:39 1997 Return-Path: Received: from bcc01.burton-computer.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA01138; Tue, 27 May 1997 14:32:15 +0100 Received: from bcc01.burton-computer.com (localhost [127.0.0.1]) by bcc01.burton-computer.com (8.8.5/8.8.5) with SMTP id JAA05055 for ; Tue, 27 May 1997 09:31:46 -0400 Sender: brian@bcc01.burton-computer.com Message-ID: <338AE242.54FB0B9F@burton-computer.com> Date: Tue, 27 May 1997 09:31:46 -0400 From: Brian Burton Organization: Burton Computer Corporation X-Mailer: Mozilla 3.01Gold (X11; U; Linux 2.0.27 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omnithread library Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1539 Status: OR I'm porting the omnithread library to BeOS (http://www.be.com) and noticied that there are no classes in the omnithread.h file for acquiring and releasing mutexes and semaphores. These really should be added since they would be far more convenient and less error prone than calling lock()/unlock() directly. For example: class omni_mutex_lock { public: omni_mutex_lock(omni_mutex *mutex) : _mutex(mutex) { _mutex->lock(); } ~omni_mutex_lock() { _mutex->unlock(); } private: omni_mutex *_mutex; }; A similar class could be added for semaphores (possibly with an overloaded constructor for doing a try_wait). With a class such as this, a mutex lock can be acquired and released by simply defining a variable of the omni_mutex_lock class: omni_mutex mutex; ... int some_class::some_function() { omni_mutex_lock lock(&mutex); if (some_flag) return -1; do_something_that_might_throw_exception(); return 0; } The lock object's destructor would automatically unlock the mutex when the return statements are executed and when an exception is encountered. Are there already helper classes like this specified in another header? If not, then they should probably be added to omnithread.h to provide a standard version. All the best, ++Brian -- Brian Burton Custom Software Development Burton Computer Corporation Java, C++, Orbix, Tuxedo brian.burton@burton-computer.com OO Consulting and Mentoring From Edward.Scott@prismtech.co.uk Fri May 23 12:37:40 1997 Return-Path: Received: from alpha3.prismtech.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA21030; Fri, 23 May 1997 12:32:23 +0100 Received: from alpha3 (localhost.prismtech.co.uk [127.0.0.1]) by alpha3.prismtech.co.uk (8.6.9/8.6.9) with SMTP id MAA02227 for ; Fri, 23 May 1997 12:38:05 +0100 Sender: eas@prismtech.co.uk Message-ID: <3385819C.167E@prismtech.co.uk> Date: Fri, 23 May 1997 12:38:04 +0100 From: Edward Scott Organization: Prism Technologies Ltd X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: OmniORB list Subject: Problem linking with VC++ 4.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1383 Status: OR Firstly, thanks for placing omniORB under GPL. I beleive it will increase the take up of CORBA. I have been trying to build a test server under omniORB2 - a simple implementation of the Name Service. I have renamed the module to XCosName to try and avoid name clashes and I am using a copy of Naming_NT.hh (also modified to XCosNaming and with a different #define at the start). Unfortunately, the build fails during linking with unresolved refrences to two function defined internally to omniORB. Has anyone encountered this problem before? Any suggestions for a fix would be welcomed. Thanks, Edward Scott Output from build (VC++ 4.2, Windows 95, Dynamic Libraries): Linking... nameSK.obj : error LNK2001: unresolved external symbol "private: void __thiscall MemBufferedStream::grow(unsigned int)"(?grow@MemBufferedStream@@AAEXI@Z) nameSK.obj : error LNK2001: unresolved external symbol "private: void * __thiscall MemBufferedStream::overrun_error(void)"(?overrun_error@MemBufferedStream@@AAEPAXXZ) Debug/opn.exe : fatal error LNK1120: 2 unresolved externals Error executing link.exe. -- ----------------------------------------------------------------------- Edward Scott Prism Technologies Ltd., Kingfisher House, Kingsway, Tyne & Wear, NE11 0JQ, England Edward.Scott@prismtech.co.uk Tel +44(0)1914913983 Fax +44(0)1914913973 From tjr@orl.co.uk Tue May 27 15:06:07 1997 Return-Path: Received: from kirkstone.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA01641; Tue, 27 May 1997 15:04:28 +0100 Received: from kirkstone.cam-orl.co.uk by kirkstone.cam-orl.co.uk with ESMTP (8.8.4//ident-1.0) id PAA03064; Tue, 27 May 1997 15:02:05 +0100 Message-Id: <199705271402.PAA03064@kirkstone.cam-orl.co.uk> To: Brian Burton cc: tjr@orl.co.uk, omniorb-list@orl.co.uk Subject: Re: Omnithread Date: Tue, 27 May 1997 15:02:05 +0100 From: Tristan Richardson Content-Length: 2301 Status: OR Hi Brian, Thanks for your comments regarding the OMNI thread library. > > I'm porting the omnithread library to BeOS (http://www.be.com) and > noticied that there are no classes in the omnithread.h file for > acquiring and releasing mutexes and semaphores. These really should be > added since they would be far more convenient and less error prone than > calling lock()/unlock() directly. > You're right that classes like these would be useful. The reason they're not included is simply that the omnithread library was one of the first pieces of C++ code I ever wrote (this was several years ago!). If you look at the omniNames source in "ReadersWritersLock.h" you'll see I use the same trick that you suggest. > > I noticed that omnithread does not use exceptions to report errors. Is > this a deliberate design decision? If not, I'd like to propose that the > classes be modified to report errors using exceptions. > > I think this would greatly improve the interface. For example, > omni_condition::timed_wait() could simply return a bool (TRUE if > signalled, FALSE if timed out) and throw an exception if some error > prevented completion of the call. > Again this is because omnithread was written quite a while ago, before exceptions were commonplace, and we wanted it to be as widely portable as possible. However, given that omniORB2 requires that the C++ compiler supports exceptions it would indeed improve the omnithread interface to make use of this fact. We will almost certainly add these features in the next release of omniORB2. However, we must of course be careful about changing fundamental APIs like this which may potentially break existing code. Thanks again for your comments. Tristan +--------------------------------------------------------------------+ | Tristan Richardson Email: tjr@orl.co.uk | | ORL Tel: +44 1223 343000 | | 24a Trumpington Street Fax: +44 1223 313542 | | Cambridge, CB2 1QA, UK WWW: http://www.orl.co.uk/ | +--------------------------------------------------------------------+ | ORL - The Olivetti & Oracle Research Laboratory | +--------------------------------------------------------------------+ From weicong@caip.rutgers.edu Tue May 27 15:35:51 1997 Return-Path: Received: from caipfs.rutgers.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA02044; Tue, 27 May 1997 15:30:55 +0100 Received: from caip.rutgers.edu (caip.rutgers.edu [128.6.91.2]) by caipfs.rutgers.edu (8.8.5/8.8.5) with ESMTP id KAA27424; Tue, 27 May 1997 10:30:50 -0400 (EDT) Received: from hadar (hadar.rutgers.edu [128.6.37.32]) by caip.rutgers.edu (8.7.6/8.6.9) with ESMTP id KAA12152; Tue, 27 May 1997 10:30:50 -0400 (EDT) Message-ID: <338AFE6A.CBFFFDEA@caip.rutgers.edu> Date: Tue, 27 May 1997 10:31:54 -0500 From: Weicong Wang Organization: CAIP Center, Rutgers University X-Mailer: Mozilla 4.0b4 [en] (WinNT; I) MIME-Version: 1.0 To: Brian Burton CC: omniorb-list@orl.co.uk Subject: Re: omnithread library X-Priority: 3 (Normal) References: <338AE242.54FB0B9F@burton-computer.com> Content-Type: text/plain; charset=iso-8859-1 Content-Length: 2283 Status: OR I think you could look into the Fresco thread library, it seems that they have some similar ideas. The fresco could be found in http://www.caip.rutgers.edu/multimedia/Fresco/ =================== Brian Burton wrote: > I'm porting the omnithread library to BeOS (http://www.be.com) and > noticied that there are no classes in the omnithread.h file for > acquiring and releasing mutexes and semaphores. These really should > be > added since they would be far more convenient and less error prone > than > calling lock()/unlock() directly. For example: > > class omni_mutex_lock > { > public: > omni_mutex_lock(omni_mutex *mutex) > : _mutex(mutex) > { > _mutex->lock(); > } > ~omni_mutex_lock() > { > _mutex->unlock(); > } > private: > omni_mutex *_mutex; > }; > > A similar class could be added for semaphores (possibly with an > overloaded constructor for doing a try_wait). > > With a class such as this, a mutex lock can be acquired and released > by > simply defining a variable of the omni_mutex_lock class: > > omni_mutex mutex; > > ... > > int some_class::some_function() > { > omni_mutex_lock lock(&mutex); > if (some_flag) > return -1; > do_something_that_might_throw_exception(); > return 0; > } > > The lock object's destructor would automatically unlock the mutex when > > the return statements are executed and when an exception is > encountered. > > Are there already helper classes like this specified in another > header? > If not, then they should probably be added to omnithread.h to provide > a > standard version. > > All the best, > ++Brian > > -- > Brian Burton Custom Software Development > Burton Computer Corporation Java, C++, Orbix, Tuxedo > brian.burton@burton-computer.com OO Consulting and Mentoring -- ====================================================== Wang Weicong Rutgers, the State Univ. of New Jersey ------------------------------------------------------ CAIP Center, PO Box 1390 Piscataway , NJ 08855-1390 ------------------------------------------------------ Tel: (O) 908-445-0659/0660 (H) 908-878-2734 http://www.caip.rutgers.edu/~weicong ------------------------------------------------------ From mattf@cst.com.au Wed May 28 00:40:38 1997 Return-Path: Received: from skeg.cst.com.au by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id AAA07757; Wed, 28 May 1997 00:38:00 +0100 Received: from test4 (test4.cst.com.au [203.61.252.184]) by skeg.cst.com.au (8.6.12/8.6.11) with ESMTP id JAA07164 for ; Wed, 28 May 1997 09:37:56 +1000 Message-ID: <338B7098.18FA4D34@cst.com.au> Date: Wed, 28 May 1997 09:39:04 +1000 From: Matt Field X-Mailer: Mozilla 4.0b4 [en] (WinNT; I) MIME-Version: 1.0 To: "omniorb-list@orl.co.uk" Subject: IOR X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Length: 233 Status: OR I have found the Visibroker for Java from Visigenic has problems parsing the Omniorb IOR's. I am using the IOR output from the eg2_impl example. Has anyone else tried this or had similar problems with IOR's? Regards, Matt Field. From S.Lo@orl.co.uk Wed May 28 12:18:41 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA14513; Wed, 28 May 1997 12:16:36 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id MAA08823; Wed, 28 May 1997 12:16:22 +0100 Date: Wed, 28 May 1997 12:16:22 +0100 Message-Id: <199705281116.MAA08823@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: ORB Interoperability (Re: IOR) In-Reply-To: <199705281102.MAA08618@santaka.cam-orl.co.uk> References: <338B7098.18FA4D34@cst.com.au> <199705281102.MAA08618@santaka.cam-orl.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 433 Status: OR >>>>> Sai-Lai Lo writes: > 2. Orbix 2.1 generates stub that produces a wrong repository ID on the wire > (IDL:CosNaming_NamingContext:1.0 instead of IDL:CosNaming/NamingContext:1.0). Oops! Got it wrong. Orbix 2.1 generates IORs containing the correct Repository ID, but, when narrowing IORs it receives, it expects the identifiers to be seperated by '_' characters. Again, the problem may have been fixed in Orbix 2.2. Sai-Lai From S.Lo@orl.co.uk Wed May 28 12:07:43 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA14341; Wed, 28 May 1997 12:03:00 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id MAA08618; Wed, 28 May 1997 12:02:46 +0100 Date: Wed, 28 May 1997 12:02:46 +0100 Message-Id: <199705281102.MAA08618@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: ORB Interoperability (Re: IOR) In-Reply-To: <338B7098.18FA4D34@cst.com.au> References: <338B7098.18FA4D34@cst.com.au> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: Matt Field Content-Length: 2010 Status: OR >>>>> Matt Field writes: > I have found the Visibroker for Java from Visigenic has problems parsing > the Omniorb IOR's. I am using the IOR output from the eg2_impl example. > Has anyone else tried this or had similar problems with IOR's? Can you give me more details about the problem you are having? Although we have not used Visibroker for Java, we have use eg2_impl to test for interoperability with OrbixWeb 2.0.1. In fact, we have a deployed application that uses OrbixWeb, omniORB2 and omniNames. On a related issue, if you want to have clients running on another ORB to talk to omniNames, there are several points to note: 1. The COS Naming IDL we use comes from ftp.omg.org and *DOES NOT* have the #pragma prefix "omg.org". The recent ORB Portability submission has mandated that all OMG IDLs should have the omg.org prefix pragma. AFAIK, HP's ORB plus has got this pragma in all the OMG IDLs they supply. If you want to have a HP ORBplus client talking to omniNames, you either have to comment out the pragma or to add the pragma to the IDL used by omniORB and recompile the distribution. Notice that the modified omniNames would not be able to read the data file produced by the original omniNames. We will move on to use omg.org prefix in future releases and will provide a conversion utility to translate the data file of omniNames. 2. Orbix 2.1 generates stub that produces a wrong repository ID on the wire (IDL:CosNaming_NamingContext:1.0 instead of IDL:CosNaming/NamingContext:1.0). You have to patch the stub header in order to interoperate with omniNames. Orbix 2.2 may have fixed the problem but I cannot verify that until our update arrives. Regards, Sai-Lai Lo -- 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 omniorb@orl.co.uk Thu May 22 17:05:54 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA10809; Thu, 22 May 1997 17:02:58 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id RAA04204; Thu, 22 May 1997 17:02:52 +0100 Date: Thu, 22 May 1997 17:02:52 +0100 Message-Id: <199705221602.RAA04204@santaka.cam-orl.co.uk> To: omniorb-list@orl.co.uk Subject: omniORB - INFO #1 From: omniorb@orl.co.uk Content-Length: 460 Status: OR In the 2.2.0 distribution, the makefiles for building shared libraries on Unix platforms contain some extraneous $ Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA10771; Thu, 22 May 1997 17:00:31 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id RAA04164; Thu, 22 May 1997 17:00:25 +0100 Date: Thu, 22 May 1997 17:00:25 +0100 Message-Id: <199705221600.RAA04164@santaka.cam-orl.co.uk> To: omniorb-list@orl.co.uk Subject: PATCH #2 From: omniorb@orl.co.uk Content-Length: 1989 Status: OR The following is a patch against the 2.2.0 distribution. **** This patch is only necessary if you have experienced problems in compiling the source on Linux. ***** -------------- cut here -------------------------- *** src/lib/omnithread/posix.cc Tue May 6 16:58:40 1997 --- ../latest/src/lib/omnithread/posix.cc Thu May 22 13:36:05 1997 *************** *** 50,56 **** #include #include "omnithread.h" ! #ifdef __linux__ #include #endif --- 50,56 ---- #include #include "omnithread.h" ! #if defined(__linux__) && defined(_MIT_POSIX_THREADS) #include #endif -------------- end ------------------------------- Typo in /usr/include/sched.h ---------------------------- In some linux distributions, e.g. RedHat 4.1, there is a typo in /usr/include/sched.h which would cause an error when compiling omniORB2. If you see this error, apply the following patch: *** sched.h Thu May 22 13:49:34 1997 --- sched.h.patched Thu May 22 13:49:47 1997 *************** *** 33,39 **** extern int sched_getscheduler __P((pid_t __pid)); extern int sched_yield __P((void)); extern int sched_get_priority_max __P((int __policy)); ! extern int sched_get_priority_min _P((int __policy)); extern int sched_rr_get_interval __P((pid_t __pid, struct timespec *interval)); --- 33,39 ---- extern int sched_getscheduler __P((pid_t __pid)); extern int sched_yield __P((void)); extern int sched_get_priority_max __P((int __policy)); ! extern int sched_get_priority_min __P((int __policy)); extern int sched_rr_get_interval __P((pid_t __pid, struct timespec *interval)); -- 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 omniorb@orl.co.uk Thu May 22 17:03:57 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA10726; Thu, 22 May 1997 16:59:29 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id QAA04145; Thu, 22 May 1997 16:59:24 +0100 Date: Thu, 22 May 1997 16:59:24 +0100 Message-Id: <199705221559.QAA04145@santaka.cam-orl.co.uk> To: omniorb-list@orl.co.uk Subject: PATCH #1 From: omniorb@orl.co.uk Content-Length: 1000 Status: OR The following is a patch against the 2.2.0 distribution. This patch adds a missing typedef for CORBA::ObjectRef in CORBA.h. This data type is needed to support the following IDL declaration: typedef Object Factory; There is no need to recompile the distribution after this patch is applied. -------------- cut here -------------------------- *** include/omniORB2/CORBA.h Tue May 6 17:04:49 1997 --- ../latest/include/omniORB2/CORBA.h Thu May 22 15:52:07 1997 *************** *** 728,733 **** --- 728,734 ---- class Object; typedef Object *Object_ptr; + typedef Object_ptr ObjectRef; typedef _CORBA_Unbounded_Sequence_Octet ReferenceData; ------------- End -------------------------------- -- 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 S.Lo@orl.co.uk Thu May 22 17:36:42 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA11101; Thu, 22 May 1997 17:34:37 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id RAA04689; Thu, 22 May 1997 17:34:31 +0100 Date: Thu, 22 May 1997 17:34:31 +0100 Message-Id: <199705221634.RAA04689@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: security in OmniOrb... In-Reply-To: <199705221612.JAA09464@skat.usc.edu> References: <199705221612.JAA09464@skat.usc.edu> X-Mailer: VM 6.23 under Emacs 19.34.2 CC: taweil From: Sai-Lai Lo Content-Length: 997 Status: OR >>>>> taweil writes: > Hi, > First of all, thanks for releasing omniOrb. It's great. I am > wondering if there is any plan in implementing CORBA security service > for omniORB. Thanks. Thanks for your message. We have not started working on the security service for omniORB. In the medium term, we would like to have at least the authentication functions in place. However, this is currently at the bottom of the list of things to do. If anyone is interested in helping out with the implementation, please drop us a line. At the moment, we are working on the support for the Any types, GIOP over native ATM and making the ORB QoS aware. Anyone interested in CORBA over ATM? Regards, Sai-Lai -- 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 S.Lo@orl.co.uk Wed May 28 12:07:43 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA14341; Wed, 28 May 1997 12:03:00 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id MAA08618; Wed, 28 May 1997 12:02:46 +0100 Date: Wed, 28 May 1997 12:02:46 +0100 Message-Id: <199705281102.MAA08618@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: ORB Interoperability (Re: IOR) In-Reply-To: <338B7098.18FA4D34@cst.com.au> References: <338B7098.18FA4D34@cst.com.au> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: Matt Field Content-Length: 2010 Status: OR >>>>> Matt Field writes: > I have found the Visibroker for Java from Visigenic has problems parsing > the Omniorb IOR's. I am using the IOR output from the eg2_impl example. > Has anyone else tried this or had similar problems with IOR's? Can you give me more details about the problem you are having? Although we have not used Visibroker for Java, we have use eg2_impl to test for interoperability with OrbixWeb 2.0.1. In fact, we have a deployed application that uses OrbixWeb, omniORB2 and omniNames. On a related issue, if you want to have clients running on another ORB to talk to omniNames, there are several points to note: 1. The COS Naming IDL we use comes from ftp.omg.org and *DOES NOT* have the #pragma prefix "omg.org". The recent ORB Portability submission has mandated that all OMG IDLs should have the omg.org prefix pragma. AFAIK, HP's ORB plus has got this pragma in all the OMG IDLs they supply. If you want to have a HP ORBplus client talking to omniNames, you either have to comment out the pragma or to add the pragma to the IDL used by omniORB and recompile the distribution. Notice that the modified omniNames would not be able to read the data file produced by the original omniNames. We will move on to use omg.org prefix in future releases and will provide a conversion utility to translate the data file of omniNames. 2. Orbix 2.1 generates stub that produces a wrong repository ID on the wire (IDL:CosNaming_NamingContext:1.0 instead of IDL:CosNaming/NamingContext:1.0). You have to patch the stub header in order to interoperate with omniNames. Orbix 2.2 may have fixed the problem but I cannot verify that until our update arrives. Regards, Sai-Lai Lo -- 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 brian.burton@burton-computer.com Wed May 28 13:39:00 1997 Return-Path: Received: from bcc01.burton-computer.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA15492; Wed, 28 May 1997 13:38:53 +0100 Received: from bcc01.burton-computer.com (localhost [127.0.0.1]) by bcc01.burton-computer.com (8.8.5/8.8.5) with SMTP id IAA10077 for ; Wed, 28 May 1997 08:38:37 -0400 Sender: brian@bcc01.burton-computer.com Message-ID: <338C274D.A7E099F@burton-computer.com> Date: Wed, 28 May 1997 08:38:37 -0400 From: Brian Burton Organization: Burton Computer Corporation X-Mailer: Mozilla 3.01Gold (X11; U; Linux 2.0.27 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Re: Omnithread References: <199705271402.PAA03064@kirkstone.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2111 Status: OR Tristan Richardson wrote: > > > > > I'm porting the omnithread library to BeOS (http://www.be.com) and > > noticied that there are no classes in the omnithread.h file for > > acquiring and releasing mutexes and semaphores. These really should be > > added since they would be far more convenient and less error prone than > > calling lock()/unlock() directly. > > > > You're right that classes like these would be useful. The reason they're not > included is simply that the omnithread library was one of the first pieces of > C++ code I ever wrote (this was several years ago!). If you look at the > omniNames source in "ReadersWritersLock.h" you'll see I use the same trick > that you suggest. > It is amazing how much the language has changed in just a few years! I like the omnithread classes. They offer a small set of very useful features rather than trying to be the ultimate threads library. I'd just like to give them a bit more polish. > > Again this is because omnithread was written quite a while ago, before > exceptions were commonplace, and we wanted it to be as widely portable as > possible. However, given that omniORB2 requires that the C++ compiler > supports exceptions it would indeed improve the omnithread interface to make > use of this fact. > > We will almost certainly add these features in the next release of omniORB2. > However, we must of course be careful about changing fundamental APIs like > this which may potentially break existing code. > Yes. It may be wise to keep the old classes unchanged and replace them with a more modern set of classes. Then old code could continue to function normally while new code could use the new classes. If the interfaces of the new classes are very similar tol those of the old (same signatures except for return types plus exceptions) then converting to the new classes could be fairly simple. All the best, ++Brian -- Brian Burton Custom Software Development Burton Computer Corporation Java, C++, Orbix, Tuxedo brian.burton@burton-computer.com OO Consulting and Mentoring From brian.burton@burton-computer.com Wed May 28 13:38:02 1997 Return-Path: Received: from bcc01.burton-computer.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA15398; Wed, 28 May 1997 13:30:49 +0100 Received: from bcc01.burton-computer.com (localhost [127.0.0.1]) by bcc01.burton-computer.com (8.8.5/8.8.5) with SMTP id IAA10042 for ; Wed, 28 May 1997 08:29:58 -0400 Sender: brian@bcc01.burton-computer.com Message-ID: <338C2546.65A312DE@burton-computer.com> Date: Wed, 28 May 1997 08:29:58 -0400 From: Brian Burton Organization: Burton Computer Corporation X-Mailer: Mozilla 3.01Gold (X11; U; Linux 2.0.27 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Re: omnithread library References: <338AE242.54FB0B9F@burton-computer.com> <199705280828.JAA27997@darkstar.lpac.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1388 Status: OR Adriaan Joubert wrote: > > As Brian said, a class for locking/unlocking mutexes would be nice, and the > incorporation of exceptions into the library is essential to make it > generally useful. > > While we appreciate Tristan's reservations about changing any APIs at this > stage, we would strongly support the development of an updated threads > library. If it would be possible to agree on an API that would be amenable > to the omniORB developers, an omniThread library would attract a lot of > support from the users, i.e. we would definitely be prepared to put some > development effort into the library if this would help. > I would also be willing to assist in modifying omniORB to properly catch exceptions generated by the omnithread library. As an alternative to a "big bang" conversion, perhaps we could develop a new set of omnithread classes that internally use the old classes and generate exceptions when errors are detected. If the new classes could be constructed using the old classes and had necessary type conversion operators, they could be plugged in to old code fairly easily. This might allow us to change over to using exceptions more gradually. ++Brian -- Brian Burton Custom Software Development Burton Computer Corporation Java, C++, Orbix, Tuxedo brian.burton@burton-computer.com OO Consulting and Mentoring From omniorb@orl.co.uk Thu May 29 12:02:57 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA28100; Thu, 29 May 1997 11:18:40 +0100 Received: from localhost by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id LAA02926; Thu, 29 May 1997 11:18:40 +0100 Message-Id: <199705291018.LAA02926@casabel.cam-orl.co.uk> To: omniorb-list@orl.co.uk Subject: test From: omniorb@orl.co.uk Date: Thu, 29 May 1997 11:18:40 +0100 Sender: ewc@orl.co.uk Content-Length: 2421 Status: OR The following is a patch for the 2.2.0 distribution. *** This patch only affects users of the Win32 distribution *** Note that binaries with the patches installed are available from http://www.orl.co.uk/omniORB/bugs/4.html . Platforms: Win32 (Windows NT, Windows '95) Description: Link errors involving MemBufferedStream may show up when linking to either the static or dynamic (DLL) libraries: error LNK2001: unresolved external symbol "private: void __thiscall MemBufferedStream::grow(unsigned int)"(?grow@MemBufferedStream@@AAEXI@Z) error LNK2001: unresolved external symbol "private: void *__thiscall MemBufferedStream::overrun_error(void)"(?overrun_error@MemBufferedStream@@AAEPAXXZ) Workaround: (PATCH #3) Two files need to be patched. You can download copies of the (patched) files from: ftp://ftp.orl.co.uk/pub/omniORB/patch3/MAKEFILE ftp://ftp.orl.co.uk/pub/omniORB/patch3/omniORB2.def Put MAKEFILE in the directory build_win32 . Put omniORB2.def in the directory src\lib\omniORB2 . Re-compile both the static and dynamic libraries. Copy the new DLL to a directory that is searched by the system's loader. Finally, link your code to the new (static or import) library. Alternatively, you can apply the patch yourself: Add the following lines to \build-win32\MAKEFILE : At line 319: -@erase "$(INTDIR)\mbufferedStream.obj" At line 353: "$(INTDIR)\mbufferedStream.obj" \ Add the following lines to the end of the file \src\lib\omniORB2\omniORB2.def : (At line 1036 - i.e. at the end of the file): ??0MemBufferedStream@@QAE@ABV0@@Z ??0MemBufferedStream@@QAE@I@Z ??1MemBufferedStream@@QAE@XZ ??2@YAPAXI@Z ??3@YAXPAX@Z ??4MemBufferedStream@@QAEAAV0@ABV0@@Z ??_C@_0CD@EBLJ@MemBufferedStream?3?3overrun_error@ ?copy@MemBufferedStream@@AAEXABV1@@Z ?get_char_array@MemBufferedStream@@QAEXPAEH@Z ?grow@MemBufferedStream@@AAEXI@Z ?overrun_error@MemBufferedStream@@AAEPAXXZ ?pd_inline_buf_size@MemBufferedStream@@0HB ?put_char_array@MemBufferedStream@@QAEXPBEH@Z ?rewind_in_mkr@MemBufferedStream@@QAEXXZ ?rewind_inout_mkr@MemBufferedStream@@QAEXXZ ?size@MemBufferedStream@@AAEIXZ ?skip@MemBufferedStream@@QAEXK@Z ?startofstream@MemBufferedStream@@ABEPAXXZ Re-compile both the static and dynamic libraries. Copy the new DLL to a directory that is searched by the system's loader. Finally, link your code to the new (static or import) library. From ewc@orl.co.uk Thu May 29 12:46:56 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA29260; Thu, 29 May 1997 12:13:40 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id MAA03190; Thu, 29 May 1997 12:13:40 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199705291113.MAA03190@casabel.cam-orl.co.uk> Subject: Patch #3 (was RE: test) To: omniorb-list@orl.co.uk Date: Thu, 29 May 1997 12:13:39 +0100 (BST) In-Reply-To: <199705291018.LAA02926@casabel.cam-orl.co.uk> from "omniorb@orl.co.uk" at May 29, 97 11:18:40 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 136 Status: OR Whoops! Sorry about the subject "test". See the previous message for details about an ** important ** patch for Win32 platforms. Eoin. From assini@kamus.it Sun Jun 1 14:03:14 1997 Return-Path: Received: from kamus.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA07333; Sun, 1 Jun 1997 13:54:43 +0100 Received: from kamus (root@localhost [127.0.0.1]) by kamus.it (8.8.5/8.8.5) with SMTP id OAA04468 for ; Sun, 1 Jun 1997 14:59:29 +0200 Sender: root@kamus.it Message-ID: <33917230.35EE3573@kamus.it> Date: Sun, 01 Jun 1997 14:59:28 +0200 From: "Pasqualino \"Titto\" Assini" Organization: Kamus - Internet Consulting X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.29 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Help: troubles running the examples Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1079 Status: OR Hi, I'm a new user of OmniORB and I'm trying to get it to work under Linux. I use Slackware 3.2 (kernel 2.0.29, gcc 2.7.2.1) and installed linuxthreads 0.6 (NOT 0.5) OmniORB compiles fine (apart a lot of warnings) and so I proceeded to compile the "echo" example. The eg1 examples (client and server in the same process) works correctly, eg2 and eg3 fail. When I pass to eg2_clt the stringified IOR produced by eg3 I get a system exception. I removed the try/catch code and rerun eg2_clt under gdb. Gdb tells me that __throw took place in ../include/omnithread.h:414 I also tried the examples/thread programs and they seems to work right (as far as I understand them). Any suggestion ? As I'm to it I would also like to ask if someone has tested OmniORB with the ORB client in the new Netscape browsers. Many thanks in advance. -- Pasqualino Assini --- Kamus Internet Consulting Via Nazioni Unite, 47 --- 50126 Firenze Italy Tel: +39 584 79.11.31 --- Tel/Fax: +39 55 68.58.07 Tel-Fax: +39 55 48.29.29 Email: assini@kamus.it --- Web: http://www.kamus.it/ From S.Lo@orl.co.uk Mon Jun 2 20:07:39 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA27119; Mon, 2 Jun 1997 19:57:40 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id TAA31548; Mon, 2 Jun 1997 19:57:33 +0100 Date: Mon, 2 Jun 1997 19:57:33 +0100 Message-Id: <199706021857.TAA31548@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Help: troubles running the examples In-Reply-To: <33917230.35EE3573@kamus.it> References: <33917230.35EE3573@kamus.it> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: "Pasqualino Assini" Content-Length: 737 Status: OR >>>>> Pasqualino \"Titto\" Assini writes: > I use Slackware 3.2 (kernel 2.0.29, gcc 2.7.2.1) and installed > linuxthreads 0.6 (NOT 0.5) Hi! I've tested omniORB on a box that has been upgraded to use linuxthreads 0.6 and cannot reproduce your problem. All our boxes run the Redhat 4.1 distribution, not slackware. Can you give me more information, such as the versions of libraries you are using? Try: ldd eg2_clt ldd eg2_impl Regards, Sai-Lai Lo -- 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 Immanuel_Litzroth@i2.com Tue Jun 3 12:20:50 1997 Return-Path: Received: from uu9.psi.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA06332; Tue, 3 Jun 1997 12:16:03 +0100 Received: by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA27785 for ; Tue, 3 Jun 97 07:14:21 -0400 Received: by mojo.i2.com (4.1) id AA25056 (for Omniorb-list@orl.co.uk); Tue, 3 Jun 97 05:51:21 CDT Message-Id: <9706031051.AA25056@mojo.i2.com> Received: by i2Tech (Lotus Notes Mail Gateway for SMTP V1.0) id 230DD5FED91FC5B1862564AA005300E8; Tue, 3 Jun 97 05:51:20 EDT To: Omniorb-list From: Immanuel Litzroth/i2Tech Date: 2 Jun 97 10:27:07 EDT Subject: Linux trouble Mime-Version: 1.0 Content-Type: Text/Plain Content-Length: 442 Status: OR I tried to install the precompiled version of omniorb for linux but when I try to run Omninames -start xxxxx it tells me it cannot use this tcp port with the message BOA_init failed: cannot use port xxx to accept incoming IIOP calls I run this example as root. Do I need to have certain networking options (tunneling or dummy netdriver ...) compiled in my kernel? Could anyone give me some pointers on this problem? Thanks Immanuel Litzroth From S.Lo@orl.co.uk Tue Jun 3 12:29:27 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA06444; Tue, 3 Jun 1997 12:26:04 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id MAA14208; Tue, 3 Jun 1997 12:25:57 +0100 Date: Tue, 3 Jun 1997 12:25:57 +0100 Message-Id: <199706031125.MAA14208@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Linux trouble In-Reply-To: <9706031051.AA25056@mojo.i2.com> References: <9706031051.AA25056@mojo.i2.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: Immanuel Litzroth/i2Tech Content-Length: 494 Status: OR >>>>> Immanuel Litzroth/i2Tech writes: > I tried to install the precompiled version of omniorb for linux but when > I try to run Omninames -start xxxxx it tells me it cannot use this tcp > port with the message BOA_init failed: cannot use port xxx to accept > incoming IIOP calls I run this example as root. It means the port is in use. Choose another one. You don't need to run omniNames as root. In fact, we advise you not to because of the security implication. Regards, Sai-Lai Lo From jrc@art.co.uk Tue Jun 3 14:29:31 1997 Return-Path: Received: from punt-2.mail.demon.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA08006; Tue, 3 Jun 1997 14:25:09 +0100 Received: from threebti.demon.co.uk ([158.152.73.32]) by punt-2.mail.demon.net id aa1126956; 3 Jun 97 13:11 BST Received: (qmail 391 invoked from smtpd); 3 Jun 1997 12:11:08 -0000 Received: from bragg.art.co.uk (root@192.168.1.129) by stefan.art.co.uk with SMTP; 3 Jun 1997 12:11:08 -0000 Received: from perot (perot.art.co.uk [192.168.1.194]) by bragg.art.co.uk (8.8.5/8.7.3) with SMTP id NAA18087; Tue, 3 Jun 1997 13:13:54 +0100 Sender: jrc@art.co.uk Message-ID: <33940A82.46AE89F6@art.co.uk> Date: Tue, 03 Jun 1997 13:13:54 +0100 From: John Connett Organization: Advanced Rendering Technology X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: omniorb-list@orl.co.uk CC: jrc@art.co.uk Subject: RPM spec file for omniORB2? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 225 Status: OR Out of interest, has anyone produced an RPM spec file for omniORB2? I'm using the RedHat Linux 4.2 Intel release. If nobody else has produced one yet I'll try writing one myself ... Regards -- John Connett (jrc@art.co.uk) From S.Lo@orl.co.uk Tue Jun 3 14:41:49 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA08182; Tue, 3 Jun 1997 14:38:41 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id OAA19588; Tue, 3 Jun 1997 14:38:33 +0100 Date: Tue, 3 Jun 1997 14:38:33 +0100 Message-Id: <199706031338.OAA19588@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: RPM spec file for omniORB2? In-Reply-To: <33940A82.46AE89F6@art.co.uk> References: <33940A82.46AE89F6@art.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: John Connett Content-Length: 595 Status: OR >>>>> John Connett writes: > Out of interest, has anyone produced an RPM spec file for omniORB2? > I'm using the RedHat Linux 4.2 Intel release. If nobody else has > produced one yet I'll try writing one myself ... You are very welcomed to produce one and send it to us to be included in the next release. Sai-Lai -- 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 Johannes.Gutleber@cern.ch Tue Jun 3 16:56:53 1997 Return-Path: Received: from dxmint.cern.ch by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA10174; Tue, 3 Jun 1997 16:42:27 +0100 Received: from cmsmail.cern.ch (cmsmail.cern.ch [137.138.81.187]) by dxmint.cern.ch with SMTP id RAA01469 for ; Tue, 3 Jun 1997 17:42:26 +0200 (MET DST) Received: from suncms42.cern.ch by cmsmail.cern.ch (SMI-8.6/SMI-SVR4) id RAA02325; Tue, 3 Jun 1997 17:42:25 +0200 Received: from suncms42 by suncms42.cern.ch (SMI-8.6/SMI-SVR4) id RAA04283; Tue, 3 Jun 1997 17:42:24 +0200 Sender: gutleber@cern.ch Message-ID: <33943B60.71BE@cern.ch> Date: Tue, 03 Jun 1997 17:42:24 +0200 From: Johannes Gutleber Organization: CERN. European Lab. for Particle Physics X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Context problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1249 Status: OR Hello! I experienced problems binding an object with a context path longer than one item, e.g. /root/level1/level2/object I wanted to bind the following: contextName.length(2); contextName[0].id (const char*) "cluster"; contextName[0].kind (const char*) "CMS_context"; contextName[1].id (const char*) "node1"; contextName[1].kind (const char*) "CMS_context"; (...) objectName.length(1); objectName[0].id = (const char*) "CPU"; objectName[0].kind = (const char*) "Object"; (...) The result is that the binding simply is not done. The context does not exist. If I shorten the context length to 1 and throw away the lines contextName[1] then it works fine? Has enyone experienced a similar problem? Greetings Hannes. +--------------------------------------------------------------+ | Johannes Gutleber | | CERN, European Laboratory for Particle Physics | | Division ECP, Compact Muon Solenoid experiment | | CH-1211 Geneva 23, Switzerland | | e-mail: Johannes.Gutleber@cern.ch | | FAX: +41 (22) 767 89 40 | +--------------------------------------------------------------+ From tjr@orl.co.uk Tue Jun 3 17:07:32 1997 Return-Path: Received: from pumpkin.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA10584; Tue, 3 Jun 1997 17:07:03 +0100 Received: from localhost by pumpkin.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id RAA19501; Tue, 3 Jun 1997 17:07:03 +0100 Message-Id: <199706031607.RAA19501@pumpkin.cam-orl.co.uk> To: omniorb-list@orl.co.uk cc: tjr@orl.co.uk, Johannes Gutleber Subject: Re: Context problem In-reply-to: Your message of "Tue, 03 Jun 1997 17:42:24 +0200." <33943B60.71BE@cern.ch> Date: Tue, 03 Jun 1997 17:07:02 +0100 From: Tristan Richardson Content-Length: 1733 Status: OR >>>>> Johannes Gutleber writes: > > I experienced problems binding an object with a context path > longer than one item, e.g. /root/level1/level2/object > > I wanted to bind the following: > contextName.length(2); > contextName[0].id (const char*) "cluster"; > contextName[0].kind (const char*) "CMS_context"; > contextName[1].id (const char*) "node1"; > contextName[1].kind (const char*) "CMS_context"; > > (...) > > objectName.length(1); > objectName[0].id = (const char*) "CPU"; > objectName[0].kind = (const char*) "Object"; > > (...) > > The result is that the binding simply is not done. The context > does not exist. If I shorten the context length to 1 and throw > away the lines contextName[1] then it works fine? > The "bind" operation will not create a context - if you are attempting to bind a compound name then the context (i.e. the components of the name up to but not including the final one) must already exist. You can use "nameclt bind_new_context" to create contexts, e.g.: % nameclt bind_new_context cluster CMS_context ... % nameclt bind_new_context cluster CMS_context node1 CMS_context ... Tristan +--------------------------------------------------------------------+ | Tristan Richardson Email: tjr@orl.co.uk | | ORL Tel: +44 1223 343000 | | 24a Trumpington Street Fax: +44 1223 313542 | | Cambridge, CB2 1QA, UK WWW: http://www.orl.co.uk/ | +--------------------------------------------------------------------+ | ORL - The Olivetti & Oracle Research Laboratory | +--------------------------------------------------------------------+ From w.pitt@mail.cryst.bbk.ac.uk Wed Jun 4 16:09:51 1997 Return-Path: Received: from iona.cryst.bbk.ac.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA25557; Wed, 4 Jun 1997 16:05:45 +0100 Received: from localhost by iona.cryst.bbk.ac.uk; (5.65v3.2/2.1/09Sep96-1332PM) with SMTP id <9706041506.AA23779@iona.cryst.bbk.ac.uk>; Wed, 4 Jun 1997 16:06:51 +0100 Date: Wed, 4 Jun 1997 16:06:51 +0100 (BST) From: William Pitt X-Sender: ubcg08l@iona.cryst.bbk.ac.uk To: omniorb-list@orl.co.uk Subject: port to IRIX Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 550 Status: OR Dear all, I'm new to this list. If the following question has been asked before, I apologize. Has anyone attempted to port omniORB to IRIX 6.x as it is pthreads compliant? If you have, I would be grateful if you could pass on your experiences. Cheers, Will ____________________________________________________________ Will Pitt Tel: 44-171-6316851 Crystallography Department, Fax: 44-171-6316803 Birkbeck College, w.pitt@mail.cryst.bbk.ac.uk Malet Street, http://www.cryst.bbk.ac.uk/~ubcg08l/ London WC1E 7HX U.K. From ulbrich@hexmac.com Thu Jun 5 09:07:12 1997 Return-Path: Received: from hexbase.hexmac.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA04802; Thu, 5 Jun 1997 08:56:42 +0100 Received: from [134.60.219.13] (dyn14.ulm.netsurf.de [195.180.108.77]) by hexbase.hexmac.de (8.6.11/8.6.9) with SMTP id JAA09132 for ; Sat, 31 May 1997 09:52:43 +0200 Message-Id: <199705310752.JAA09132@hexbase.hexmac.de> Subject: Re: omniORB on Linux Date: Thu, 5 Jun 97 09:53:57 +0200 x-sender: ulbrich@hexbase.hexmac.de x-mailer: Claris Emailer 1.1 From: Jan Ulbrich To: "OmniORB Mailinglist" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Length: 646 Status: OR Hi Amit Joshi, >After I compiled it I could not get the eg3 example in the echo >directory to work. the eg3_impl method core dumps as soon as it starts. >I do have the name server up. It sounds like you didn't start the Nameserver - read the README to learn on how to start "omniNames" and setup the environment variables. If this is not the problem: Sorry to give you this simple advice... Have a nice day, Jan -- /// Jan Ulbrich - flynn (remember tron?) o-o Margarethe von Wrangellweg 1, 89075 Ulm, Germany L Phone +49731552806, Fax +4973159334, Mobil +491727429683, - WWW http://www.hexmac.de/~ulbrich, eMail ulbrich@hexmac.com From ulbrich@hexmac.com Thu Jun 5 09:06:03 1997 Return-Path: Received: from hexbase.hexmac.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA04778; Thu, 5 Jun 1997 08:53:59 +0100 Received: from [134.60.219.13] (dyn14.ulm.netsurf.de [195.180.108.77]) by hexbase.hexmac.de (8.6.11/8.6.9) with SMTP id JAA09129 for ; Sat, 31 May 1997 09:52:42 +0200 Message-Id: <199705310752.JAA09129@hexbase.hexmac.de> Subject: Re: Hirarchy of Naming Services Date: Thu, 5 Jun 97 09:53:56 +0200 x-sender: ulbrich@hexbase.hexmac.de x-mailer: Claris Emailer 1.1 From: Jan Ulbrich To: "OmniORB Mailinglist" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Length: 993 Status: OR Hi Malte, >I would like to construct a tree of name servers, but i can't find any >hint how that could be done. (I must admit, that I didn't read the >whole bunch of OMG's CORBA related documents). >I understood, that the Naming service itself is (just) another CORBA >component, so I guess it shouldn't be difficult to interconnect them. Just use the Nameserver client "nameclt" to bind the remote server to the local one: "nameclt bind MALTESREMOTENAMESERVERNAME Object IOR:OBJECTSTRINGYOULIKETOLINK". Try the following to see if the Nameserver will return your object: "nameclt resolve MaltesRemoteNameserver Object". You could also create a new context with "nameclt bind_new_context MALTESNEWCONTEXT Context". Hope this helps. Have a nice day, Jan -- /// Jan Ulbrich - flynn (remember tron?) o-o Margarethe von Wrangellweg 1, 89075 Ulm, Germany L Phone +49731552806, Fax +4973159334, Mobil +491727429683, - WWW http://www.hexmac.de/~ulbrich, eMail ulbrich@hexmac.com From Hans.Huebner@Berlin.IRS.DE Wed Jun 4 22:15:40 1997 Return-Path: Received: from unlisys.unlisys.NET by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id WAA29167; Wed, 4 Jun 1997 22:05:25 +0100 Received: by unlisys.unlisys.NET (Smail3.2) from Berlin.IRS.DE (194.42.83.2) with smtp id ; Wed, 4 Jun 1997 23:05:24 +0200 (MET DST) Received: by Berlin.IRS.DE (Smail3.1.29.1 #5) id m0wZNFz-0007EhC; Wed, 4 Jun 97 23:06 MET DST Date: Wed, 4 Jun 1997 23:06:11 +0200 (MET DST) From: Hans.Huebner@Berlin.IRS.DE (Hans Huebner) To: omniorb-list@orl.co.uk Subject: Reusing object references - omniORB connection management Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 3992 Status: OR Hello there, I am currently faced with the problem that our application processes keep object references to CORBA objects in memory. This requires that objects reuse the same object reference when the server process is restarted. I figured out how to re-create an object using a key argument which is passed to the server skeleton. Now the servers are fine, and the objects they serve can be restarted on the same object reference they used to have in their previous lifes. (I'd like to have an enhancement here, though: omniBroker implements a proprietary make_inet_object (or some such), which, given a host, port and key triple creates an object reference which can be used both to (re-)start a server and get a reference to an object from a descriptive name. We'd need such a thing in omniORB2) But what about the clients? If a server process is restarted, the client object reference is invalidated because it is tied to an open connection, which is of course closed when the server restarts. It is my understanding of CORBA that object references are not tied to a connection, so I would expect that the ORB handles the reconnection if a server restarts. I have been tracing through the ORB a bit, and found out that actually the client does not (can not?) recognize that the server is no longer listening. This is due to the fact that, the active socket is not notified if the passive socket (on the server) is shut down. According to the CORBA specification, the server of an GIOP connection should send a CloseConnection message if it no longer wants to serve requests on a connection, but it also states that certain protocols, like TCP/IP, need additional handshake mechanisms to ensure that this last message is received by the client before the connection is finally run down. As the spec does not give advice how this handshake should be performed in IIOP, I'd suggest that the server does not close a connection after it has sent the CloseConnection message to the client, but rather continues reading requests until it receives an error by ::recv(). This strategy has the drawback that the server ORB must stay alive until all clients have disconnected their connections, which may or may not be acceptable depending on the application and context. In any case, omniORB does need a mechanism to orderly shut down a server ORB, and in the shutdown process, the CloseConnection message must be sent to all clients currently connected. This is a prerequesite for transparent reconnections of clients, which in turn is a must-have in most real-world applications (in which crashing servers are common). One of the big problems with implementing orderly ORB shutdown in omniORB2 is class omni:: with it's bunch of static data members. It would be much better to use the Singleton pattern for omni::, and create a single ORB object with a destructor. The destructor would be responsible for cleaning up client connections, freeing allocated memory and all this. I'd suggest to use reference counted pointers to the omni:: instance, and to have the instance() method call the destructor if the reference count becomes zero. As ORL seems to be willing to accept patches to omniORB2, but such a change would be a major structural modifications, I'm not sure whether I should take the challenge and do it myself. It would be very interesting to know what kind of work ORL currently does wrt omniORB2, and what resources are allocated to the project. Please let us know. I'm really pro GPLed software, but I'd rather try to keep enhancements coordinated, especially if they involve major changes which would make merging different branches of development difficult or impossible. Thanks - Hans -- Hans Huebner, IRS Berlin GmbH Phone : +49-30-2096 2158 Fax : +49-30-2096 2157 Hans.Huebner@Berlin.IRS.DE Mobile: +49-177-512 1024 From amitj@tts.dowjones.com Wed Jun 4 21:43:37 1997 Return-Path: Received: from relay.go.dowjones.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id VAA28806; Wed, 4 Jun 1997 21:32:49 +0100 Received: (from uucp@localhost) by relay.go.dowjones.com (8.7.3/8.7.3) id QAA08154 for ; Wed, 4 Jun 1997 16:32:44 -0400 (EDT) Received: from jupiter.tts.dowjones.com(198.3.43.1) by bigbird.go.dowjones.com via smap (3.2) id xma008137; Wed, 4 Jun 97 16:32:30 -0400 Received: from amitpc3 (amitpc3.tts.dowjones.com) by tts.dowjones.com (4.1/SMI-4.1) id AA01403; Wed, 4 Jun 97 16:32:14 EDT Message-Id: <3395D060.19BE3FFD@tts.dowjones.com> Date: Wed, 04 Jun 1997 16:30:24 -0400 From: Amit Joshi Reply-To: amitj@tts.dowjones.com Organization: Dow Jones Markets X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) Mime-Version: 1.0 To: OmniORB List Subject: omniORB on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 506 Status: OR Hello, I have installed and tried omniORB on Linux. I applied the patches needed and it compiled. However I have run into some problems: 1) After I compiled it I could not get the eg3 example in the echo directory to work. the eg3_impl method core dumps as soon as it starts. I do have the name server up. 2) I tried building shared libraries. The libraries built but all teh examples core dump. It appears as if there are some initializers that are not getting called. Anybody tried this ? Amit Joshi From jody@sccsi.com Wed Jun 4 18:09:06 1997 Return-Path: Received: from friday.sccsi.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA26825; Wed, 4 Jun 1997 17:46:52 +0100 Received: (from jody@localhost) by friday.sccsi.com (8.6.9/8.6.9) id LAA09175; Wed, 4 Jun 1997 11:39:44 -0500 Date: Wed, 4 Jun 1997 11:39:44 -0500 Message-Id: <199706041639.LAA09175@friday.sccsi.com> From: Jody Winston To: w.pitt@iona.cryst.bbk.ac.uk CC: omniorb-list@orl.co.uk In-reply-to: (message from William Pitt on Wed, 4 Jun 1997 16:06:51 +0100 (BST)) Subject: Re: port to IRIX Content-Length: 503 Status: OR I've started on a port, but the examples still do not work. I'll be happy to send anyone the changes to the code. Jody Winston xprt Computer Consulting, Inc. 731 Voyager Houston, TX 77062 (281) 480 8649, jody@sccsi.com Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From saintlou@tumbleweed.com Wed Jun 4 20:40:29 1997 Return-Path: Received: from tumbleweed1.tumbleweed.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id UAA28308; Wed, 4 Jun 1997 20:27:33 +0100 Received: from dev1 ([207.220.220.201]) by tumbleweed1.tumbleweed.com (post.office MTA v2.0 0813 ID# 0-11773) with SMTP id AAA101; Wed, 4 Jun 1997 12:25:52 -0700 Message-ID: <3395C192.1529@tumbleweed.com> Date: Wed, 04 Jun 1997 12:27:14 -0700 From: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Organization: Tumbleweed Software Corp. X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: Malte Mueller CC: omniorb-list@orl.co.uk Subject: Re: Hirarchy of Naming Services References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 605 Status: OR Hello Malte, While I have not tried with OmniORB this is possible with any compliant Naming Service. Namely you can federate any number of naming services you want because any object of a Naming Service (i.e. Context or Object) is also CORBA object, which can be bound in any other naming Service (even from a different vendor if they all 'speak' IIOP). QED. -- Emmanuel R. Saint-Loubert saintlou@tumbleweed.com Tumbleweed Software Corp. http://www.tumbleweed.com 2010 Broadway Tel 415-569-3676 Redwood City, CA 94063 Fax 415-369-7197 From mamue@fbti.et-inf.fho-emden.de Wed Jun 4 18:47:42 1997 Return-Path: Received: from fbti.et-inf.fho-emden.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA27300; Wed, 4 Jun 1997 18:25:40 +0100 Received: by fbti.et-inf.fho-emden.de id (Debian /\oo/\ Smail3.1.29.1 #29.36); Wed, 4 Jun 97 19:25 MET DST Message-Id: From: mamue@fbti.et-inf.fho-emden.de (Malte Mueller) Subject: Hirarchy of Naming Services To: omniorb-list@orl.co.uk Date: Wed, 4 Jun 1997 19:25:25 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 447 Status: OR Hello, I would like to construct a tree of name servers, but i can't find any hint how that could be done. (I must admit, that I didn't read the whole bunch of OMG's CORBA related documents). I understood, that the Naming service itself is (just) another CORBA component, so I guess it shouldn't be difficult to interconnect them. Thanks in advance for any suggestions. Best regards, Malte Mueller FHO - Emden mamue@server.et-inf.fho-emden.de From Edward.Scott@prismtech.co.uk Thu Jun 5 10:40:26 1997 Return-Path: Received: from alpha3.prismtech.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA06226; Thu, 5 Jun 1997 10:37:20 +0100 Received: from alpha3 (localhost.prismtech.co.uk [127.0.0.1]) by alpha3.prismtech.co.uk (8.6.9/8.6.9) with SMTP id KAA01560 for ; Thu, 5 Jun 1997 10:43:29 +0100 Sender: eas@prismtech.co.uk Message-ID: <33968A40.41C6@prismtech.co.uk> Date: Thu, 05 Jun 1997 10:43:28 +0100 From: Edward Scott Organization: Prism Technologies Ltd X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: OmniORB list Subject: Persistent Objects Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 521 Status: OR Hello, Does anyone have an example of creating persistent objects using omniOrb? The ability to do this is mention in section 2.8.4 of the manual. I guess I am looking for the equivalent of object Loaders in Orbix. Regards, Edward ----------------------------------------------------------------------- Edward Scott Prism Technologies Ltd., Kingfisher House, Kingsway, Tyne & Wear, NE11 0JQ, England Edward.Scott@prismtech.co.uk Tel +44(0)1914913983 Fax +44(0)1914913973 From jrc@art.co.uk Thu Jun 5 11:04:41 1997 Return-Path: Received: from punt-2.mail.demon.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA06620; Thu, 5 Jun 1997 11:01:28 +0100 Received: from threebti.demon.co.uk ([158.152.73.32]) by punt-2.mail.demon.net id aa0629641; 5 Jun 97 11:01 BST Received: (qmail 13732 invoked from smtpd); 5 Jun 1997 10:01:14 -0000 Received: from bragg.art.co.uk (root@192.168.1.129) by stefan.art.co.uk with SMTP; 5 Jun 1997 10:01:14 -0000 Received: from perot (perot.art.co.uk [192.168.1.194]) by bragg.art.co.uk (8.8.5/8.7.3) with SMTP id LAA32567; Thu, 5 Jun 1997 11:04:14 +0100 Sender: jrc@art.co.uk Message-ID: <33968F1E.678CBACE@art.co.uk> Date: Thu, 05 Jun 1997 11:04:14 +0100 From: John Connett Organization: Advanced Rendering Technology X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: omniorb-list@orl.co.uk CC: jrc@bragg.art.co.uk Subject: Port to Solaris 2.5/ GNU C++ compiler version 2.7.2.1? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 143 Status: OR Has anyone ported omniORB2 to Solaris 2.5 using the GNU compilers rather than the Sun SparcCompilers? Regards -- John Connett (jrc@art.co.uk) From qma@gcal.ac.uk Thu Jun 5 12:50:33 1997 Return-Path: Received: from scooter.gcal.ac.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA08138; Thu, 5 Jun 1997 12:46:52 +0100 Received: from barra [193.62.240.43] by scooter.gcal.ac.uk with smtp (EXIM-1.61 CONTACT-postmaster@gcal.ac.uk) id 0wZb04-0004rM-00; Thu, 5 Jun 1997 12:46:40 +0100 Message-ID: <3396A73E.142D@gcal.ac.uk> Date: Thu, 05 Jun 1997 12:47:10 +0100 From: Quentin Mair Reply-To: qma@gcal.ac.uk Organization: Glasgow Caledonian University X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: HP-UX 9/10 port? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 302 Status: OR Does anyone know if there's a port to HP-UX 9 or 10 for use with HP's C++ compiler? Thanks, Q -- Quentin Mair Lecturer Department of Computer Studies City Campus Glasgow Caledonian University Glasgow G4 0BA Scotland Tel: +44 141 331 3283 Fax: +44 141 331 3277 URL: http://www.cos.gcal.ac.uk/~mair From stubben@server.et-inf.fho-emden.de Thu Jun 5 13:45:17 1997 Return-Path: Received: from server.et-inf.fho-emden.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA08947; Thu, 5 Jun 1997 13:42:41 +0100 Received: from sunnyboy.et-inf.fho-emden.de (sunnyboy.et-inf.fho-emden.de [192.129.16.225]) by server.et-inf.fho-emden.de (8.8.5/8.7.3) with SMTP id OAA13539 for ; Thu, 5 Jun 1997 14:40:21 +0200 Received: from sunnyboy by sunnyboy.et-inf.fho-emden.de (SMI-8.6/SMI-SVR4) id OAA03597; Thu, 5 Jun 1997 14:37:49 +0200 Sender: stubben@server.et-inf.fho-emden.de Message-ID: <3396B31D.5B0@server.et-inf.fho-emden.de> Date: Thu, 05 Jun 1997 14:37:49 +0200 From: stefan ubben Organization: Fachhochschule Ostfriesland X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Re: Port to Solaris 2.5/ GNU C++ compiler version 2.7.2.1? References: <33968F1E.678CBACE@art.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 933 Status: OR John Connett wrote: > > Has anyone ported omniORB2 to Solaris 2.5 using the GNU compilers rather > than the Sun SparcCompilers? > yes i am using solaris 2.5.1 and the gcc2.7.2. i selected the sun4_sosV_5.5.mk configuration file. the compilerflag must contain the "-fhandle-exceptions" flag (remember not using the "-O2"-flag with the "-fhandle-exceptions"-flag) before compiling the source you must delete the following lines in file /src/appl/omniNames/log.cc: // a bug on Solaris means that the fd doesn't get closed. #if defined(__sunos__) && (__OSVERSION__ == 5) if (close(fd) < 0) throw IOError(); #endif now you can compile the source. good luck stefan -- Dipl. Inf. (FH) Stefan Ubben Fachhochschule Ostfriesland, Constantiaplatz 4, 26723 Emden (Germany) Tel.: (+49)(4921) 807-209, E-Mail: stubben@et-inf.fho-emden.de FAX: (+49)(4921) 807-530, WWW: http://sunnyboy.et-inf.fho-emden.de From tjr@orl.co.uk Thu Jun 5 14:36:28 1997 Return-Path: Received: from pumpkin.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA09668; Thu, 5 Jun 1997 14:35:17 +0100 Received: from localhost by pumpkin.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id OAA13566; Thu, 5 Jun 1997 14:35:17 +0100 Message-Id: <199706051335.OAA13566@pumpkin.cam-orl.co.uk> To: omniorb-list@orl.co.uk cc: tjr@orl.co.uk Subject: Re: Hirarchy of Naming Services In-reply-to: Your message of "Thu, 05 Jun 1997 09:53:56 +0200." <199705310752.JAA09129@hexbase.hexmac.de> Date: Thu, 05 Jun 1997 14:35:16 +0100 From: Tristan Richardson Content-Length: 1770 Status: OR >>>>>> Jan Ulbrich writes: > > Just use the Nameserver client "nameclt" to bind the remote server to the > local one: "nameclt bind MALTESREMOTENAMESERVERNAME Object > IOR:OBJECTSTRINGYOULIKETOLINK". > It is worth noting here that there is a subtle difference between using the "bind" operation and the "bind_context" operation for federating name servers. Using "bind" will bind another nameserver as an object (BindingType = nobject), whereas "bind_context" will result in a binding as a context (BindingType = ncontext). Only in this second case may a compound name which refers to an object in the second nameserver be resolved in a single call to the first nameserver. For example say nameserver 2 is bound as a context with name "/a/b" inside nameserver 1. An object bound as "/c/d" inside nameserver 2 can be accessed from nameserver 1 by the name "/a/b/c/d". If on the other hand, nameserver 2 is bound as an object, then two calls are necessary. A client must first resolve "/a/b" to get an object reference for nameserver 2, and then use this to resolve "/c/d" inside nameserver 2. Note also that "bind_context" is only available with the "-advanced" option to nameclt. Tristan +--------------------------------------------------------------------+ | Tristan Richardson Email: tjr@orl.co.uk | | ORL Tel: +44 1223 343000 | | 24a Trumpington Street Fax: +44 1223 313542 | | Cambridge, CB2 1QA, UK WWW: http://www.orl.co.uk/ | +--------------------------------------------------------------------+ | ORL - The Olivetti & Oracle Research Laboratory | +--------------------------------------------------------------------+ From S.Lo@orl.co.uk Thu Jun 5 14:36:41 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA09626; Thu, 5 Jun 1997 14:33:22 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id OAA13202; Thu, 5 Jun 1997 14:33:19 +0100 Date: Thu, 5 Jun 1997 14:33:19 +0100 Message-Id: <199706051333.OAA13202@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Persistent Objects In-Reply-To: <33968A40.41C6@prismtech.co.uk> References: <33968A40.41C6@prismtech.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 1619 Status: OR >>>>> Edward Scott writes: > Does anyone have an example of creating persistent objects using > omniOrb? The ability to do this is mention in section 2.8.4 of the > manual. I guess I am looking for the equivalent of object Loaders in > Orbix. omniNames uses the feature to create "persistent" objects. These objects can be contacted using the same IOR when they are instantiated in different program runs. Basically, there are two things you need to do: 1. Make sure that the BOA uses the same port to accept incoming IIOP connections. This is done by passing the -BOAiiop_port to BOA::init(). See section 3.1 of the user guide and the ORB initialisation chapter of the CORBA spec for details. 2. Make sure that the same object key is used to identify the object implementation. omniORB provides a ctor in the implementation skeleton class that takes an object key as an argument and uses that to identify the object (section 2.4.2 of the user guide). The object key is an opaque type but can be converted to and from a sequence of octets using the utility functions described in section 3.3 of the user guide. As an example, have a look at omniNames. I suggest you starts with void log::getCreate(istream& file) (line 648, src/appl/omniNames/log.cc). Have fun. Sai-Lai Lo -- 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 jrc@art.co.uk Thu Jun 5 15:48:01 1997 Return-Path: Received: from punt-2.mail.demon.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA10775; Thu, 5 Jun 1997 15:44:21 +0100 Received: from threebti.demon.co.uk ([158.152.73.32]) by punt-2.mail.demon.net id aa1105233; 5 Jun 97 15:41 BST Received: (qmail 15457 invoked from smtpd); 5 Jun 1997 14:34:59 -0000 Received: from bragg.art.co.uk (root@192.168.1.129) by stefan.art.co.uk with SMTP; 5 Jun 1997 14:34:59 -0000 Received: from perot (perot.art.co.uk [192.168.1.194]) by bragg.art.co.uk (8.8.5/8.7.3) with SMTP id PAA01588; Thu, 5 Jun 1997 15:38:08 +0100 Sender: jrc@art.co.uk Message-ID: <3396CF4F.22FB2C18@art.co.uk> Date: Thu, 05 Jun 1997 15:38:07 +0100 From: John Connett Organization: Advanced Rendering Technology X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: omniorb-list@orl.co.uk CC: jrc@bragg.art.co.uk Subject: Bug or feature? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 841 Status: OR The following IDL file generates a skeleton file which gcc is unwilling to compile ... typedef float RtFloat; typedef RtFloat RtColor[3]; typedef sequence RtColorSeq; interface Ri { void Dummy(in RtColorSeq colors); }; gcc -c -fhandle-exceptions -Wall -Wno-unused -I. -D__OMNIORB2__ -I../../../include -D_REENTRANT -D__linux__ -D__i86__ -D__OSVERSION__=2 -o RiSK.o RiSK.cc ../../../include/omniORB2/bufferedStream.h: In method `void _CORBA_Sequence::operator <<=(class MemBufferedStream &)': In file included from RiSK.cc:1: ../../../include/omniORB2/bufferedStream.h:609: bad argument 1 for function `void operator <<=(unsigned char &, class NetBufferedStream &)' (type was float[3]) ... Is the problem with my attempt to write IDL? Is there a work around? -- John Connett (jrc@art.co.uk) From chafey@ecst.csuchico.edu Thu Jun 5 17:59:02 1997 Return-Path: Received: from guzzler.ecst.csuchico.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA12784; Thu, 5 Jun 1997 17:54:13 +0100 Received: (from chafey@localhost) by guzzler.ecst.csuchico.edu (8.8.5/8.8.5) id JAA18495; Thu, 5 Jun 1997 09:54:06 -0700 (PDT) From: Chris Hafey Message-Id: <199706051654.JAA18495@guzzler.ecst.csuchico.edu> Subject: Re: Persistent Objects To: S.Lo@orl.co.uk (Sai-Lai Lo) Date: Thu, 5 Jun 1997 09:54:06 -0700 (PDT) Cc: omniorb-list@orl.co.uk In-Reply-To: <199706051333.OAA13202@santaka.cam-orl.co.uk> from "Sai-Lai Lo" at Jun 5, 97 02:33:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1734 Status: OR > 2. Make sure that the same object key is used to identify the object > implementation. omniORB provides a ctor in the implementation skeleton > class that takes an object key as an argument and uses that to identify > the object (section 2.4.2 of the user guide). The object key is an > opaque type but can be converted to and from a sequence of octets > using the utility functions described in section 3.3 of the user guide. I would really like to see support for user defined keys. The ability to use the same object key in the database and the ORB has significant advantages. Ideally this would be implemented as an octet sequence. Proxy object key are already maintained this way but I haven't spent enough time in the code to see how this applies to local objects. Thoughts? On another note, I would really like to know what ORL's plans are for OmniORB's development. I believe in the future of CORBA and expect to see a GPLd COBRA implementation at least as popular as Linux is today. To achieve this, we need to develop a complete CORBA solution. We need someone to manage the growth and development of omniORB (like Linus did for Linux). Could someone at ORL answer the following questions: a) Which features are currently under development and when can they be expected? (I know about DII/DSI/Type Any, but when are they due?) b) What is ORL's position in regard to future omniORB development? Is ORL getting out of ORB development or will resources be allocated? Major development projects include: 1) Interface Repository 2) POA support (it would be nice to be the first ORB to support the POA) 3) Implement the Security service 4) Implement the Transaction service Chris Hafey From S.Lo@orl.co.uk Thu Jun 5 18:39:10 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA13257; Thu, 5 Jun 1997 18:35:21 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id SAA16884; Thu, 5 Jun 1997 18:35:18 +0100 Date: Thu, 5 Jun 1997 18:35:18 +0100 Message-Id: <199706051735.SAA16884@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Bug or feature? In-Reply-To: <3396CF4F.22FB2C18@art.co.uk> References: <3396CF4F.22FB2C18@art.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 8215 Status: OR >>>>> John Connett writes: > The following IDL file generates a skeleton file which gcc is unwilling > to compile ... > typedef float RtFloat; > typedef RtFloat RtColor[3]; > typedef sequence RtColorSeq; > interface Ri { > void Dummy(in RtColorSeq colors); > }; You've found a bug! The C++ template code for sequences does not handle array correctly. I'll fix it properly later. In the mean time, at the end of this message is a patch to apply to Ri.hh that will fix the problem. Regards, Sai-Lai --------- cut here ----------------------- *** Ri.hh Thu Jun 5 18:20:00 1997 --- Ri.hh.patched Thu Jun 5 18:19:50 1997 *************** *** 21,28 **** typedef _CORBA_Array_Var RtColor_var; typedef _CORBA_Array_Forany RtColor_forany; ! typedef _CORBA_Unbounded_Sequence RtColorSeq; typedef _CORBA_Sequence_Var RtColorSeq_var; #ifndef __Ri__ #define __Ri__ --- 21,278 ---- typedef _CORBA_Array_Var RtColor_var; typedef _CORBA_Array_Forany RtColor_forany; ! ! class _CORBA_Sequence { ! public: ! inline _CORBA_Sequence() : pd_max(0), pd_len(0), pd_rel(1), pd_buf(0) { } ! inline _CORBA_Sequence(_CORBA_ULong max) : ! pd_max(max), pd_len(0), pd_rel(1) ! { ! if (!(pd_buf = allocbuf(max))) { ! _CORBA_new_operator_return_null(); ! // never reach here ! } ! return; ! } ! ! inline _CORBA_Sequence(_CORBA_ULong max, ! _CORBA_ULong length, ! RtColor *value, ! _CORBA_Boolean release = 0) ! : pd_max(max), ! pd_len(length), ! pd_rel(release), ! pd_buf(value) ! { ! if (length > max) { ! _CORBA_bound_check_error(); ! // never reach here ! } ! return; ! } ! ! inline _CORBA_Sequence(const _CORBA_Sequence& s) ! : pd_max(s.pd_max), ! pd_len(s.pd_len), ! pd_rel(1) ! { ! if (!(pd_buf = allocbuf(s.pd_len))) { ! _CORBA_new_operator_return_null(); ! // never reach here ! } ! for (_CORBA_ULong i=0; i < s.pd_len; i++) { ! for (unsigned long i2=0; i2 < 3; i2++) { ! pd_buf[i][i2] = s.pd_buf[i][i2]; ! } ! } ! } ! ! inline ~_CORBA_Sequence() { ! if (pd_rel && pd_buf) freebuf(pd_buf); ! pd_buf = 0; ! return; ! } ! inline _CORBA_Sequence &operator= (const _CORBA_Sequence &s) ! { ! if (pd_max < s.pd_max) ! { ! RtColor *newbuf = allocbuf(s.pd_max); ! if (!newbuf) { ! _CORBA_new_operator_return_null(); ! // never reach here ! } ! pd_max = s.pd_max; ! if (pd_rel && pd_buf) { ! freebuf(pd_buf); ! } ! else { ! pd_rel = 1; ! } ! pd_buf = newbuf; ! } ! pd_len = s.pd_len; ! for (unsigned long i=0; i < pd_len; i++) { ! for (unsigned long i2=0; i2 < 3; i2++) { ! pd_buf[i][i2] = s.pd_buf[i][i2]; ! } ! } ! return *this; ! } ! ! inline _CORBA_ULong maximum() const { return pd_max; } ! inline _CORBA_ULong length() const { return pd_len; } ! inline void length(_CORBA_ULong length) ! { ! if (length > pd_max) ! { ! RtColor *newbuf = allocbuf(length); ! if (!newbuf) { ! _CORBA_new_operator_return_null(); ! // never reach here ! } ! for (unsigned long i=0; i < pd_len; i++) { ! for (unsigned long i2=0; i2<3; i2++) { ! newbuf[i][i2] = pd_buf[i][i2]; ! } ! } ! pd_max = length; ! if (pd_rel && pd_buf) { ! freebuf(pd_buf); ! } ! else { ! pd_rel = 1; ! } ! pd_buf = newbuf; ! } ! pd_len = length; ! return; ! } ! inline RtColor &operator[] (_CORBA_ULong index) ! { ! if (index >= length()) { ! _CORBA_bound_check_error(); ! } ! return pd_buf[index]; ! } ! inline const RtColor &operator[] (_CORBA_ULong index) const ! { ! if (index >= length()) { ! _CORBA_bound_check_error(); ! } ! return pd_buf[index]; ! } ! static inline RtColor* allocbuf(_CORBA_ULong nelems) ! { ! return new RtColor[nelems]; ! } ! static inline void freebuf(RtColor * b) ! { ! if (b) delete [] b; ! return; ! } ! // omniORB2 extensions ! inline RtColor *NP_data() const { return pd_buf; } ! inline void operator>>= (NetBufferedStream &s) const; ! inline void operator<<= (NetBufferedStream &s); ! inline void operator>>= (MemBufferedStream &s) const; ! inline void operator<<= (MemBufferedStream &s); ! ! private: ! _CORBA_ULong pd_max; ! _CORBA_ULong pd_len; ! _CORBA_Boolean pd_rel; ! RtColor *pd_buf; ! }; ! ! inline ! void ! _CORBA_Sequence::operator>>= (NetBufferedStream &s) const ! { ! _CORBA_ULong l = length(); ! l >>= s; ! if (l==0) return; ! s.put_char_array((_CORBA_Char*)NP_data(),(int)l*4*3); ! } ! ! inline ! void ! _CORBA_Sequence::operator<<= (NetBufferedStream &s) ! { ! _CORBA_ULong l; ! l <<= s; ! if (l*4*3 > s.RdMessageUnRead()) { ! _CORBA_marshal_error(); ! // never reach here ! } ! length(l); ! if (l==0) return; ! s.get_char_array((_CORBA_Char*)NP_data(),(int)l*4*3); ! if (s.RdMessageByteOrder() != omni::myByteOrder) { ! for (_CORBA_ULong i=0; i> 24) | ! (((t) & 0x00ff0000) >> 8) | ! (((t) & 0x0000ff00) << 8) | ! (((t) & 0x000000ff) << 24)); ! } ! } ! } ! ! inline ! void ! _CORBA_Sequence::operator>>= (MemBufferedStream &s) const ! { ! _CORBA_ULong l = length(); ! l >>= s; ! if (l==0) return; ! s.put_char_array((_CORBA_Char*)NP_data(),(int)l*4*3); ! } ! ! inline ! void ! _CORBA_Sequence::operator<<= (MemBufferedStream &s) ! { ! _CORBA_ULong l; ! l <<= s; ! if (l*4*3 > s.unRead()) { ! _CORBA_marshal_error(); ! // never reach here ! } ! length(l); ! if (l==0) return; ! s.get_char_array((_CORBA_Char*)NP_data(),(int)l*4*3); ! if (s.byteOrder() != omni::myByteOrder) { ! for (_CORBA_ULong i=0; i> 24) | ! (((t) & 0x00ff0000) >> 8) | ! (((t) & 0x0000ff00) << 8) | ! (((t) & 0x000000ff) << 24)); ! } ! } ! } ! ! class _CORBA_Unbounded_Sequence : public _CORBA_Sequence { ! public: ! inline _CORBA_Unbounded_Sequence() {} ! inline _CORBA_Unbounded_Sequence(_CORBA_ULong max) : _CORBA_Sequence(max) {} ! inline _CORBA_Unbounded_Sequence(_CORBA_ULong max, ! _CORBA_ULong length, ! RtColor *value, ! _CORBA_Boolean release = 0) ! : _CORBA_Sequence(max,length,value,release) {} ! inline _CORBA_Unbounded_Sequence(const _CORBA_Unbounded_Sequence& s) ! : _CORBA_Sequence(s) {} ! inline ~_CORBA_Unbounded_Sequence() {} ! inline _CORBA_Unbounded_Sequence &operator= (const _CORBA_Unbounded_Sequence &s) { ! _CORBA_Sequence::operator= (s); ! return *this; ! } ! inline size_t NP_alignedSize(size_t initialoffset) const { ! size_t alignedsize = ((initialoffset+3) & ~((int)3))+sizeof(_CORBA_ULong); ! if (length()) { ! alignedsize = ((alignedsize+(3)) & ~(3)); ! alignedsize += length() * 4 * 3; ! } ! return alignedsize; ! } ! inline void operator>>= (NetBufferedStream &s) const { ! _CORBA_Sequence::operator>>=(s); ! } ! inline void operator<<= (NetBufferedStream &s) { ! _CORBA_Sequence::operator<<=(s); ! } ! inline void operator>>= (MemBufferedStream &s) const { ! _CORBA_Sequence::operator>>=(s); ! } ! inline void operator<<= (MemBufferedStream &s) { ! _CORBA_Sequence::operator<<=(s); ! } ! }; ! ! typedef _CORBA_Unbounded_Sequence RtColorSeq; typedef _CORBA_Sequence_Var RtColorSeq_var; + #ifndef __Ri__ #define __Ri__ --------- end ---------------------------- From S.Lo@orl.co.uk Fri Jun 6 10:56:20 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA21807; Fri, 6 Jun 1997 10:48:25 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id KAA20689; Fri, 6 Jun 1997 10:48:21 +0100 Date: Fri, 6 Jun 1997 10:48:21 +0100 Message-Id: <199706060948.KAA20689@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Persistent Objects In-Reply-To: <3397D58E.41C6@prismtech.co.uk> References: <33968A40.41C6@prismtech.co.uk> <199706051333.OAA13202@santaka.cam-orl.co.uk> <3397D58E.41C6@prismtech.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: Edward Scott Content-Length: 4688 Status: OR >>>>> Edward Scott writes: > If I wanted to do a demand driven style of persistent loading e.g. an > object is only retrived from persistent store when an operation is > performed on it will I need to modify omniOrb e.g. in > GIOP_S::HandleRequest or omni::locateObject and add a mechanism to > define how a particular type of object is loaded? A more elegant solution is to use LOCATION_FORWARDING. When the first operation is performed on the object, the object is retrived from persistent store and instantiated. The object reference to this newly instantiated object, which is different from the original object, is then returned in a LOCATION_FORWARD message. All the hooks necessary to do this sort of trick is already in the ORB. We have a design in the pipeline to allow applications to do these things properly. Stay tuned. In the meantime, see if this piece of example code helps. This program takes an object reference as a command line argument, instantiated a redirect object which stores the object ref internally. Any requests comes in for the redirect object will receive a LOCATION_FORWARD message that points to the first object. I think it is possible to adapt this example to do what you want. Regards, Sai-Lai Lo --------------------------- reDirect.h -------------------- #ifndef __REDIRECT_H__ #define __REDIRECT_H__ #include class reDirect : public virtual omniObject, public virtual CORBA::Object { public: reDirect(CORBA::Object_ptr fwdref); reDirect(CORBA::Object_ptr fwdref,const omniORB::objectKey& mykey); virtual ~reDirect() {} CORBA::Object_ptr forwardReference() const; CORBA::Object_ptr _this(); void _obj_is_ready(CORBA::BOA_ptr boa); CORBA::BOA_ptr _boa(); void _dispose(); omniORB::objectKey _key(); virtual CORBA::Boolean dispatch(GIOP_S &s, const char *,CORBA::Boolean); private: CORBA::Object_var pd_fwdref; reDirect(); }; -------------------------------- end ---------------------- --------------------------- reDirect.cc ------------------- #include reDirect::reDirect(CORBA::Object_ptr fwdref) : pd_fwdref(fwdref) { if (CORBA::is_nil(fwdref)) throw CORBA::BAD_PARAM(0,CORBA::COMPLETED_NO); omniObject::PR_IRRepositoryId(fwdref->PR_getobj()->NP_IRRepositoryId()); this->PR_setobj(this); } reDirect::reDirect(CORBA::Object_ptr fwdref, const omniORB::objectKey& mykey) : pd_fwdref(fwdref) { if (CORBA::is_nil(fwdref)) throw CORBA::BAD_PARAM(0,CORBA::COMPLETED_NO); omniObject::PR_IRRepositoryId(fwdref->PR_getobj()->NP_IRRepositoryId()); this->PR_setobj(this); omniRopeAndKey l(0,(CORBA::Octet*)&mykey,(CORBA::ULong)sizeof(mykey)); setRopeAndKey(l,0); } CORBA::Object_ptr reDirect::forwardReference() const { return CORBA::Object::_duplicate(pd_fwdref); } CORBA::Object_ptr reDirect::_this() { return CORBA::Object::_duplicate(this); } void reDirect::_obj_is_ready(CORBA::BOA_ptr boa) { boa->obj_is_ready(this); } CORBA::BOA_ptr reDirect::_boa() { return CORBA::BOA::getBOA(); } void reDirect::_dispose() { _boa()->dispose(this); } omniORB::objectKey reDirect::_key() { omniRopeAndKey l; getRopeAndKey(l); return (*((omniORB::objectKey*)l.key())); } CORBA::Boolean reDirect::dispatch(GIOP_S &s, const char *,CORBA::Boolean response) { s.RequestReceived(1); if (!response) { // a one-way call, not allowed to give a reply // silently dump the request. s.ReplyCompleted(); return 1; } size_t msgsize = (size_t) GIOP_S::ReplyHeaderSize(); msgsize = CORBA::Object::NP_alignedSize(pd_fwdref,msgsize); s.InitialiseReply(GIOP::LOCATION_FORWARD,(CORBA::ULong)msgsize); CORBA::Object::marshalObjRef(pd_fwdref,s); s.ReplyCompleted(); return 1; } -------------------------- end ------------------------------ -------------------------- tombstone.cc --------------------- #include int main(int argc, char** argv) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"omniORB2"); CORBA::BOA_ptr boa = orb->BOA_init(argc,argv,"omniORB2_BOA"); if (argc < 2) { cerr << "usage: tombstone " << endl; return -1; } CORBA::Object_ptr obj = orb->string_to_object(argv[1]); if (CORBA::is_nil(obj)) { cerr << "Can't forward to a nil object." << endl; return -1; } reDirect* tombstone = new reDirect(obj); tombstone->_obj_is_ready(boa); { CORBA::Object_var objref = tombstone->_this(); CORBA::String_var objstr = orb->object_to_string(objref); cerr << "'" << (char*)objstr << "'" << endl; } boa->impl_is_ready(); return 0; } ------------------------- end ----------------------- From Edward.Scott@prismtech.co.uk Fri Jun 6 11:27:34 1997 Return-Path: Received: from alpha3.prismtech.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA22330; Fri, 6 Jun 1997 11:26:14 +0100 Received: from alpha3 (localhost.prismtech.co.uk [127.0.0.1]) by alpha3.prismtech.co.uk (8.6.9/8.6.9) with SMTP id LAA15130; Fri, 6 Jun 1997 11:32:20 +0100 Sender: eas@prismtech.co.uk Message-ID: <3397E734.41C6@prismtech.co.uk> Date: Fri, 06 Jun 1997 11:32:20 +0100 From: Edward Scott Organization: Prism Technologies Ltd X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: Sai-Lai Lo CC: omniorb-list@orl.co.uk Subject: Re: Persistent Objects References: <33968A40.41C6@prismtech.co.uk> <199706051333.OAA13202@santaka.cam-orl.co.uk> <3397D58E.41C6@prismtech.co.uk> <199706060948.KAA20689@santaka.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1250 Status: OR Sai-Lai Lo wrote: > > >>>>> Edward Scott writes: > > > If I wanted to do a demand driven style of persistent loading e.g. an > > object is only retrived from persistent store when an operation is > > performed on it will I need to modify omniOrb e.g. in > > GIOP_S::HandleRequest or omni::locateObject and add a mechanism to > > define how a particular type of object is loaded? > > A more elegant solution is to use LOCATION_FORWARDING. When the first > operation is performed on the object, the object is retrived from > persistent store and instantiated. The object reference to this newly > instantiated object, which is different from the original object, is then > returned in a LOCATION_FORWARD message. > The LOCATION_FORWARDING solution is obviously a good idea but is it an addition to what I was suggesting rather than an alternative? I still need to detect when the first operation is performed on a unrestored perstent object... Regards Edward ----------------------------------------------------------------------- Edward Scott ................Prism Technologies Ltd., Kingfisher House, http://www.prismtech.co.uk ..Kingsway, Tyne & Wear, NE11 0JQ, England Edward.Scott@prismtech.co.uk Tel +44(0)1914913983 Fax +44(0)1914913973 From S.Lo@orl.co.uk Fri Jun 6 12:16:28 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA23249; Fri, 6 Jun 1997 12:15:13 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id MAA22163; Fri, 6 Jun 1997 12:15:08 +0100 Date: Fri, 6 Jun 1997 12:15:08 +0100 Message-Id: <199706061115.MAA22163@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Scott Subject: Re: Persistent Objects In-Reply-To: <3397E734.41C6@prismtech.co.uk> References: <33968A40.41C6@prismtech.co.uk> <199706051333.OAA13202@santaka.cam-orl.co.uk> <3397D58E.41C6@prismtech.co.uk> <199706060948.KAA20689@santaka.cam-orl.co.uk> <3397E734.41C6@prismtech.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: omniorb-list@orl.co.uk Content-Length: 1940 Status: OR >>>>> Edward Scott writes: > The LOCATION_FORWARDING solution is obviously a good idea but is it an > addition to what I was suggesting rather than an alternative? I still > need to detect when the first operation is performed on a unrestored > perstent object... The redirect object in the example is the equivalent of a daemon or an object loader. It is this object that detects the first operation that is performed on an unrestored persistent object. The redirect object does not need to be type-related to the persistent object, it just need to call a factory that can instantiate the persistent object. By the way, the term "persistent object" may be a bit confusing. I use it here to mean an object that has states stored in a persistent store. In the previous messages, I use the term "persistent object" to mean an object that a program instantiate with the same IOR in different runs. In the example, the redirect object is the one that has to have the same IOR in different runs. Now what if we don't have any redirect object at all. Instead, if an incoming request is directed towards an object that the ORB has no knowledge of, the ORB calls into an application installed "loader" to find and locate the object. This method of loading object is not supported by omniORB. This approach has the disadvantage that requests send to invalid or non-existing objects can not be rejected by the ORB but has to go pass the application level "loader" just in case it is one that the loader can instantiate. There is also concurrency issues that need to be addressed. My gut feeling is this may be a can of worms that we better avoid. Regards, Sai-Lai -- 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 cobrien@access.digex.net Fri Jun 6 13:37:32 1997 Return-Path: Received: from access4.digex.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA24258; Fri, 6 Jun 1997 13:32:22 +0100 Received: (from cobrien@localhost) by access4.digex.net (8.8.4/8.8.4) id IAA21253; Fri, 6 Jun 1997 08:32:02 -0400 (EDT) From: "Cary B. O'Brien" Message-Id: <199706061232.IAA21253@access4.digex.net> Subject: Re: HP-UX 9/10 port? To: qma@gcal.ac.uk Date: Fri, 6 Jun 1997 08:32:02 -0400 (EDT) Cc: omniorb-list@orl.co.uk In-Reply-To: <3396A73E.142D@gcal.ac.uk> from Quentin Mair at "Jun 5, 97 12:47:10 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 722 Status: OR > Does anyone know if there's a port to HP-UX 9 or 10 for use > with HP's C++ compiler? > > Thanks, > I don't know about the port, but I do have access to a HP-UX w/ HP C++ all patched up to work right with threads and exceptions (a long story..). So I suppose I could test someones port. Or if someone gave me some hints actually try it myself. (why do I do this to myself?). BTW - Does anyone have the nameservice demo programs running under Linux? -- cary cobrien@access.digex.net > Quentin Mair > Lecturer > Department of Computer Studies > City Campus > Glasgow Caledonian University > Glasgow > G4 0BA > Scotland > > Tel: +44 141 331 3283 > Fax: +44 141 331 3277 > URL: http://www.cos.gcal.ac.uk/~mair > From saintlou@tumbleweed.com Fri Jun 6 18:21:17 1997 Return-Path: Received: from tumbleweed1.tumbleweed.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA27932; Fri, 6 Jun 1997 18:18:20 +0100 Received: from dev1 ([207.220.220.201]) by tumbleweed1.tumbleweed.com (post.office MTA v2.0 0813 ID# 0-11773) with SMTP id AAA211 for ; Fri, 6 Jun 1997 10:16:46 -0700 Message-ID: <3398464F.40C1@tumbleweed.com> Date: Fri, 06 Jun 1997 10:18:07 -0700 From: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Organization: Tumbleweed Software Corp. X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Java bindings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 393 Status: OR Hello, Does anyone knows if OmniOrb2 is planned to have Java bindings anytime soon ? And in general what are the future plans with Java ? Thanks, -- Emmanuel R. Saint-Loubert saintlou@tumbleweed.com Tumbleweed Software Corp. http://www.tumbleweed.com 2010 Broadway Tel 415-569-3676 Redwood City, CA 94063 Fax 415-369-7197 From S.Lo@orl.co.uk Fri Jun 6 18:28:13 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA28037; Fri, 6 Jun 1997 18:28:07 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id SAA27725; Fri, 6 Jun 1997 18:28:03 +0100 Date: Fri, 6 Jun 1997 18:28:03 +0100 Message-Id: <199706061728.SAA27725@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: omniORB development X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 2319 Status: OR >>>>> Chris Hafey writes: > > Could someone at ORL answer the following questions: > > a) Which features are currently under development and when can they be > expected? (I know about DII/DSI/Type Any, but when are they due?) > b) What is ORL's position in regard to future omniORB development? Is ORL > getting out of ORB development or will resources be allocated? omniORB is under active development at ORL: 1. We are using it in the system software of our radio ATM system; in sensor systems and resources monitors that aim to provide systems support for advanced personalisation; and in building a large scale multimedia information retrieval system etc. 2. We want our ORB to handle continuous media efficently. We are developing a GIOP over native ATM transport. Soon, we'll start on a shared memory transport and a SCI transport. To support these "special" transports, we are investigating an explicit binding model that allows applications to tell the ORB what to do by specifying the requirements as quality of service parameters. It is our objective to implement most, if not all, of the functionalities specified in the CORBA core. We do not intend to develop in-house the full taxomony of the COS services except those that are essential to our research work and cannot be purchased from other vendors. On the other hand, we very much welcome others to develop more COS services and make them available for free under GPL. To this end, we'll provide the necessary hooks in the ORB to facilitate the development of these services. (Personally, I hope someone can take up the baton and implements the security service.) Timetable ? - Give us three months to deliver Any and TypeCode. - Expect no further BOA development as it is going to be superseded by POA. - Proper ORB shutdown and better connection management soon. - Support for LifeCycle service soon. - Not sure when we can start working on POA. Authentication support comes higher on the list. Regards, Sai-Lai Lo -- 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 bcalves@slac.com Sat Jun 7 19:48:28 1997 Return-Path: Received: from gnosis.slac.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA09691; Sat, 7 Jun 1997 19:45:44 +0100 Received: (from bcalves@localhost) by gnosis.slac.com (8.8.5/8.6.9) id OAA21833 for omniorb-list@orl.co.uk; Sat, 7 Jun 1997 14:49:41 -0400 Date: Sat, 7 Jun 1997 14:49:41 -0400 From: Brian Calves Message-Id: <199706071849.OAA21833@gnosis.slac.com> To: omniorb-list@orl.co.uk Subject: Q: Server activation policy Content-Length: 778 Status: OR Hello, Yet another CORBA newbie here. I was just attempting to write my first CORBA app. It involves creating a factory class and adding it to the name service. Clients can then connect to the name service, get a reference to the factory, and request that the factory instantiate a server object for the client. When the factory returns the dynamically created server object, and the client invokes a method on it, I get a system exception. (The factory successfully invokes methods on the server object before returning it). After a lot of attempted debugging, it occured to me that this is due to the limitation that "The BOA only supports the persistent server activation policy." Is this my problem, or is there just a bug running amok in my code? Regards, Brian From saintlou@tumbleweed.com Mon Jun 9 18:22:15 1997 Return-Path: Received: from tumbleweed1.tumbleweed.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA02849; Mon, 9 Jun 1997 18:16:22 +0100 Received: from dev1 ([207.220.220.201]) by tumbleweed1.tumbleweed.com (post.office MTA v2.0 0813 ID# 0-11773) with SMTP id AAA211; Mon, 9 Jun 1997 10:14:41 -0700 Message-ID: <339C3A54.52E0@tumbleweed.com> Date: Mon, 09 Jun 1997 10:16:04 -0700 From: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Organization: Tumbleweed Software Corp. X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: John Connett CC: omniorb-list@orl.co.uk, jrc@bragg.art.co.uk Subject: Re: "Efficiency" of omniORB, ORBs in general? References: <339BFEFA.797E6845@art.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2063 Status: OR Hello John, Our application is currently using RPC and we are thinking of using an ORB. I ran some performance tests to compare native Windows NT 4.0 RPC to OmniORB2 (see below). I was very happy with the results. As you will see OmniOrb2 has very little overhead. However these findings apply only to OmniORB2, whereas other vendors'ORB which often makes several calls to the Interface Repository and to the Typdecode interpreter can be much slower. I have been involved in the writing of an ORB and Services at another company and yes ORB can be inefficient, there are several potential problems which are the **flip side** of how much dynamic behaviour you (+ the ORB) use. Here is what I found, by modifying one of our existing applications: + My test involved making a call with 1 in/out struct, 2 in sequences, 1 in struct and in string. All sequences had at least 1 element of average size 15 bytes + I performed each call 10,000 times and averaged 3 runs + Timing was measured round-trip (from the client) the server implementation was changed to return immediately. Time mesurement does not include start-up time, etc... only the remote call was measured. + Tests were conducted on NT 4.0 with Pentium Pro 180Mhz The remote calls where measured between 2 of the same NT systems sitting on the same LAN. RPC CORBA (omni2) --------------------------------------------------------------- IPC (local) 159 micro-secs n/a TCP/IP (local) 515 micro-secs 595 micro-secs TCP/IP (remote) 1098 micro-secs 1100 micro-secs ------------------------------------------------------------------------- I hope that helps... -- Emmanuel R. Saint-Loubert saintlou@tumbleweed.com Tumbleweed Software Corp. http://www.tumbleweed.com 2010 Broadway Tel 415-569-3676 Redwood City, CA 94063 Fax 415-369-7197 From jody@sccsi.com Mon Jun 9 17:53:43 1997 Return-Path: Received: from friday.sccsi.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA02351; Mon, 9 Jun 1997 17:35:46 +0100 Received: (from jody@localhost) by friday.sccsi.com (8.6.9/8.6.9) id KAA09388; Mon, 9 Jun 1997 10:48:27 -0500 Date: Mon, 9 Jun 1997 10:48:27 -0500 Message-Id: <199706091548.KAA09388@friday.sccsi.com> From: Jody Winston To: jrc@art.co.uk CC: omniorb-list@orl.co.uk, jrc@bragg.art.co.uk In-reply-to: <339BFEFA.797E6845@art.co.uk> (message from John Connett on Mon, 09 Jun 1997 14:02:50 +0100) Subject: Re: "Efficiency" of omniORB, ORBs in general? Content-Length: 902 Status: OR See the the following papers "Design and Performance of an Object-Oriented Framework for High Speed Electronic Medical Engineering," Irfan Pyarali, Timothy H. Harrision, and Douglas C. Schimdt, Nov/Dec Computing Systems Journal, Vol. 9, No. 3. "Measuring the Performance of Communication Middleware on High-Speed Networks", Aniruddha Gokhale and Douglas C. Schmidt, Proceedings of the SIGCOMM Conference, 1996, Stanford University. These and other papers can be found at http://www.cs.wustl.edu/~schmidt/new.html Jody Winston xprt Computer Consulting, Inc. 731 Voyager Houston, TX 77062 (281) 480 8649, jody@sccsi.com Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jrc@art.co.uk Mon Jun 9 15:38:24 1997 Return-Path: Received: from punt-2.mail.demon.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA00796; Mon, 9 Jun 1997 15:18:25 +0100 Received: from threebti.demon.co.uk ([158.152.73.32]) by punt-2.mail.demon.net id aa1327043; 9 Jun 97 13:59 BST Received: (qmail 3769 invoked from smtpd); 9 Jun 1997 12:59:41 -0000 Received: from bragg.art.co.uk (root@192.168.1.129) by stefan.art.co.uk with SMTP; 9 Jun 1997 12:59:41 -0000 Received: from perot (perot.art.co.uk [192.168.1.194]) by bragg.art.co.uk (8.8.5/8.7.3) with SMTP id OAA29848; Mon, 9 Jun 1997 14:02:50 +0100 Sender: jrc@art.co.uk Message-ID: <339BFEFA.797E6845@art.co.uk> Date: Mon, 09 Jun 1997 14:02:50 +0100 From: John Connett Organization: Advanced Rendering Technology X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: omniorb-list@orl.co.uk CC: jrc@bragg.art.co.uk Subject: "Efficiency" of omniORB, ORBs in general? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 825 Status: OR I've suggested to colleagues that I might use omniORB to prototype a remote call interface to a library defined by a C language interface. There are around 140 calls of varying complexity. The reaction is that "ORBs are inefficient" and that it would be better to use a socket based interface with hand written marshalling / unmarshalling code ... I'm very new to the CORBA approach and lack the experience to either confirm or refute their suggestion. However, I have found IDL a useful means of specifying an interface and the mechanically generated marshalling / unmarshalling code also seems very useful! Any one on this list care to comment? Can you point me to any references or other information on the efficiency or otherwise of ORBs v. hand crafted code? Thanks in anticipation -- John Connett (jrc@art.co.uk) From jrc@art.co.uk Fri Jun 13 10:42:28 1997 Return-Path: Received: from punt-2.mail.demon.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA00284; Fri, 13 Jun 1997 10:40:19 +0100 Received: from threebti.demon.co.uk ([158.152.73.32]) by punt-2.mail.demon.net id aa0505730; 13 Jun 97 10:21 BST Received: (qmail 30686 invoked from smtpd); 13 Jun 1997 09:20:47 -0000 Received: from bragg.art.co.uk (root@192.168.1.129) by stefan.art.co.uk with SMTP; 13 Jun 1997 09:20:47 -0000 Received: from perot (perot.art.co.uk [192.168.1.194]) by bragg.art.co.uk (8.8.5/8.7.3) with SMTP id KAA01807; Fri, 13 Jun 1997 10:25:20 +0100 Sender: jrc@art.co.uk Message-ID: <33A11200.7E8D290D@art.co.uk> Date: Fri, 13 Jun 1997 10:25:20 +0100 From: John Connett Organization: Advanced Rendering Technology X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: OmniORB List CC: jrc@art.co.uk Subject: C language clients with omniORB? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 762 Status: OR Has anyone tried any ORBs with C language mappings operating as clients to an omniORB server? I am particularly interested in freely available ORBs that can be persuaded to run under Linux (eg. ILU, Flick, ...). Rather than trying to build and test them myself I would be keen to receive recommendations for ORBs that are known to interoperate with omniORB ... Details of commercial ORBs available on a "free" trail basis would also be of interest (I have access to SPARC/Solaris, Alpha/Digital UNIX, and SGI/IRIX systems as well as Pentium/Linux). For the task I am considering I only require static IDL with no use of the 'any' type. I might want to be able to use object reference parameters. Many thanks in anticipation -- John Connett (jrc@art.co.uk) From amitj@tts.dowjones.com Thu Jun 12 14:26:53 1997 Return-Path: Received: from relay.go.dowjones.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA14903; Thu, 12 Jun 1997 13:59:56 +0100 Received: (from uucp@localhost) by relay.go.dowjones.com (8.7.3/8.7.3) id IAA27567 for ; Thu, 12 Jun 1997 08:59:39 -0400 (EDT) Received: from jupiter.tts.dowjones.com(198.3.43.1) by bigbird.go.dowjones.com via smap (3.2) id xma027504; Thu, 12 Jun 97 08:59:25 -0400 Received: from amitpc3 (amitpc3.tts.dowjones.com) by tts.dowjones.com (4.1/SMI-4.1) id AA11772; Thu, 12 Jun 97 08:59:25 EDT Message-Id: <339FF22B.21D5AA91@tts.dowjones.com> Date: Thu, 12 Jun 1997 08:57:15 -0400 From: Amit Joshi Reply-To: amitj@tts.dowjones.com Organization: Dow Jones Markets X-Mailer: Mozilla 4.0 [en] (WinNT; I) Mime-Version: 1.0 To: OmniORB List Subject: OmniORB, Pentium GCC, Linux and race conditions X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1584 Status: OR Hello, I have been playing with omniORB on Linux with the Pentium GCC (pgcc) compiler. - Everything compiles after changing the omni_thread::wrapper function to a C++ binding, creating a ::wrapper2 function with C binding and changing references for wrapper to wrapper2. - There are however a plethora of warnings. Most seem to fall into two categories: - switch statements without all the possible cases and no default: case. Some of these, in "ast_expression.cc", I fixed. - Some warning about initializations being re-ordered. Have to investigate this further. Any thought are welcome. - However the first example "eg1" fails with a segmentation. However if I run the example in the debugger (gdb), let SIGUSR1 be handled with no interruptions, then it sometimes dies and sometime runs cleanly. It seems to depend on how much I step through the code. This probably means that there is a race condition where depending on which thread manages to get to some point first. Seems to happen during the init routines. Any thoughts ? This does not occur with the regular gcc compiler. The pgcc compiler produces faster code etc. My comments are: - The code needs a lot of tightening up - the warnings are indicators. - There are some race conditions. - In order to understand the code I would need some internals documentation. This is not to say that omniORB is bad or flame anybody or anything but some thoughts. I think that it is a good idea and a good product - I would not be spending time otherwise on it. Thank you Amit Joshi From tjr@orl.co.uk Mon Jun 16 13:11:35 1997 Return-Path: Received: from pumpkin.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA23805; Mon, 16 Jun 1997 13:00:18 +0100 Received: from localhost by pumpkin.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id NAA09410; Mon, 16 Jun 1997 13:00:18 +0100 Message-Id: <199706161200.NAA09410@pumpkin.cam-orl.co.uk> To: omniorb-list@orl.co.uk cc: tjr@orl.co.uk Subject: New omnithread library Date: Mon, 16 Jun 1997 13:00:18 +0100 From: Tristan Richardson Content-Length: 2746 Status: OR In response to overwhelming demand (:-)) there is a new version of the omnithread library with several improvements. The new library will be included with the next release of omniORB2, scheduled for early next week. For those who are interested, the changes are as follows: * Exceptions are now used everywhere. Most functions which previously returned an error number now return void. Nearly all such errors were unrecoverable and it was never really practical to test the return code anyway. In the new interface functions throw a "fatal" exception when they get an underlying system error, or throw an "invalid" exception when invoked with invalid arguments. * The only such functions which do not return void are the condition variable timedwait and semaphore trywait. As well as potentially throwing the above exceptions, these functions now return true on success, false on failure. Because there is no change in function signature, the names of the functions have been changed by removing the underscore. This causes existing code which uses them to fail to compile, thus ensuring that it be updated to the new interface. The new names are also more similar to the equivalent posix functions. * There are new "lock" classes for acquiring mutexes and semaphores. These can be used to safely grab a lock until the end of a function, releasing it automatically even in the event of exceptions being thrown. * The implementation "wrapper" functions have been fixed so that they should now work properly on all compilers. * Some historical baggage has been removed. The omniORB library recompiles with the new omnithread interface without modification. A very minor change is needed to omniNames. The only changes likely to be needed to other existing code is where omni_condition::timed_wait and omni_semaphore::try_wait are used. Use of exceptions and the new lock classes actually makes the source for the implementations of omnithread about 30-40% smaller - always a good sign! Thanks are due to Brian Burton for suggesting most of these changes. Happy threading! Tristan +--------------------------------------------------------------------+ | Tristan Richardson Email: tjr@orl.co.uk | | ORL Tel: +44 1223 343000 | | 24a Trumpington Street Fax: +44 1223 313542 | | Cambridge, CB2 1QA, UK WWW: http://www.orl.co.uk/ | +--------------------------------------------------------------------+ | ORL - The Olivetti & Oracle Research Laboratory | +--------------------------------------------------------------------+ From renzo.tomaselli@tecnotp.inet.it Mon Jun 16 14:52:02 1997 Return-Path: Received: from venere.inet.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA25016; Mon, 16 Jun 1997 14:47:30 +0100 Received: (from trusted@localhost) by venere.inet.it (8.6.10/8.6.10) id PAA37346 for ; Mon, 16 Jun 1997 15:47:22 +0200 Message-Id: <199706161347.PAA37346@venere.inet.it> Received: from tecnotp.inet.it(194.20.15.148) by venere.inet.it via I-SMTP id queue/s-194.20.15.148-3k9Qyb; Mon Jun 16 15:47:22 1997 From: "Renzo Tomaselli" To: Subject: why providing a .def file Date: Mon, 16 Jun 1997 15:50:50 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 1381 Status: OR Hi folks, I'm quite new to this list. I installed OmniORB2 on Win95; its runs fine. I run into troubles when trying to recompile it for the debug version under MSVC 5.0; the provided .def file doesn't match all compiled symbols, so I had to exclude a lot of symbols from it (I believe they are really unnecessary outside). I had similar problems when trying first to compile the standard version under MSVC 4.0, since Microsoft changed the mangling rules after 4.0. So here is the big question: why not putting _OMNIORB_NTDLL_ in front of all really exported classes and forgetting about providing a .def file ? As far as I know this is the standard way for Win32. I even tried that way, however all ORB/BOA stuff is not marked as exported along their class definitions, so examples don't link. A further question: why not providing the workspace (or project) files for MSVC under Win32 ? They provide helpful support when debugging, and the released makefiles seem generated from that source anyway. Thanks, Renzo Tomaselli --------------------------------------------------------------------------- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 461 773164 Fax. +39 461 773180 e-mail: renzo.tomaselli@tecnotp.inet.it --------------------------------------------------------------------------- From ewc@orl.co.uk Mon Jun 16 15:30:16 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA25410; Mon, 16 Jun 1997 15:13:56 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id PAA27344; Mon, 16 Jun 1997 15:13:55 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199706161413.PAA27344@casabel.cam-orl.co.uk> Subject: Re: why providing a .def file To: renzo.tomaselli@tecnotp.inet.it (Renzo Tomaselli) Date: Mon, 16 Jun 1997 15:13:55 +0100 (BST) Cc: omniorb-list@orl.co.uk In-Reply-To: <199706161347.PAA37346@venere.inet.it> from "Renzo Tomaselli" at Jun 16, 97 03:50:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1521 Status: OR > I'm quite new to this list. I installed OmniORB2 on Win95; its runs fine. > I run into troubles when trying to recompile it for the debug version under > MSVC 5.0; the provided .def file doesn't match all compiled symbols, so I > had to exclude a lot of symbols from it (I believe they are really > unnecessary outside). I had similar problems when trying first to compile > the standard version under MSVC 4.0, since Microsoft changed the mangling > rules after 4.0. That's correct - the symbols for the debug version differ from those in the release version. You could try using the static library for debugging. > So here is the big question: why not putting _OMNIORB_NTDLL_ in front of > all really exported classes and forgetting about providing a .def file ? As > far as I know this is the standard way for Win32. I even tried that way, > however all ORB/BOA stuff is not marked as exported along their class > definitions, so examples don't link. The reason for this is that there doesn't seem to be a way to export templates using the macros ( under MSVC++ 4.2 - and I don't think this has been added in MSVC++ 5.0 ). So, a .DEF file must be used (at least for the templates). If there is a way, we'd be interested to hear. > A further question: why not providing the workspace (or project) files for > MSVC under Win32 ? They provide helpful support when debugging, and the > released makefiles seem generated from that source anyway. Seems like a good idea. We'll put them in our next release. Eoin. From S.Lo@orl.co.uk Mon Jun 16 18:15:31 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA27825; Mon, 16 Jun 1997 18:13:20 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id SAA07920; Mon, 16 Jun 1997 18:13:04 +0100 Date: Mon, 16 Jun 1997 18:13:04 +0100 Message-Id: <199706161713.SAA07920@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: OmniORB, Pentium GCC, Linux and race conditions In-Reply-To: <339FF22B.21D5AA91@tts.dowjones.com> References: <339FF22B.21D5AA91@tts.dowjones.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 3775 Status: OR Thanks for your message. 1. We have not used the Pentium GCC (pgcc) compiler and is unsure about the quality of its support for exceptions and templates. The current version of gcc (2.7.2) *cannot* use optimisation and exception handling together. I don't know if pgcc is more advanced in this respect or if it just generates the wrong code if exception handling and optimisation are used together. Please fill us in with more info on pgcc, preferably by direct email in order to keep the volume of traffic on this mailing list reasonably low. 2. We are tracking the development of gcc and will make sure that omniORB2 will work with 2.8.0 when it comes out. In fact, we have tested our current development source with the latest development snapshot of gcc on Sparc Solaris. 3. An improved omnithread library will come with the next release. The omni_thread::wrapper has been changed to use a simpler mechanism. 4. The compiler warnings you reported come almost entirely from SUN's CFE IDL compiler frontend that we use in omniidl2. Some of these warnings can be removed by a general cleanup of SUN's CFE source. Some of them are warnings on the lex and yacc outputs that we do not want to touch. I'm confident that the warnings are quite harmless and hence are of low priority in fixing. 5. I'm not sure the problem you have in running "eg1" is the manifestation of a race condition. My gut feeling is that the compiler may be the one to blame. FYI, one of our development machine is a 7-processor Sun Enterprise Server and we regularly load test omniORB2 on it. It seems to me any race condition is more likely to show up on the big iron than a linux box :-) 6. I have received a number of requests for some documentation on how the code works. This will come some time in the future but don't hold your breath for it. In the mean time, it is best to start by looking at the stub code and works your way down. The header files in include/omniORB2 contains a lot more comments on the code than the source in lib/omniORB2. Regards, Sai-Lai Lo >>>>> Amit Joshi writes: > Hello, > I have been playing with omniORB on Linux with the Pentium GCC (pgcc) > compiler. > - Everything compiles after changing the omni_thread::wrapper function > to a C++ binding, creating a ::wrapper2 function with C binding and > changing references for wrapper to wrapper2. > - There are however a plethora of warnings. Most seem to fall into two > categories: > - switch statements without all the possible cases and no default: > case. Some of these, in "ast_expression.cc", I fixed. > - Some warning about initializations being re-ordered. Have to > investigate this further. Any thought are welcome. > - However the first example "eg1" fails with a segmentation. However if > I run the example in the debugger (gdb), let SIGUSR1 be handled with > no interruptions, then it sometimes dies and sometime runs cleanly. It > seems to depend on how much I step through the code. This probably > means that there is a race condition where depending on which thread > manages to get to some point first. Seems to happen during the > init routines. Any thoughts ? This does not occur with the regular > gcc compiler. The pgcc compiler produces faster code etc. > My comments are: > - The code needs a lot of tightening up - the warnings are indicators. > - There are some race conditions. > - In order to understand the code I would need some internals > documentation. > This is not to say that omniORB is bad or flame anybody or anything but > some thoughts. I think that it is a good idea and a good product - I > would not be spending time otherwise on it. From S.Lo@orl.co.uk Mon Jun 16 19:11:09 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA28285; Mon, 16 Jun 1997 19:04:24 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id TAA08678; Mon, 16 Jun 1997 19:04:08 +0100 Date: Mon, 16 Jun 1997 19:04:08 +0100 Message-Id: <199706161804.TAA08678@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: GNU g++ with omniORB2 under Solaris 2.5 In-Reply-To: <9706130832.AA11656@bambi.unibe.ch> References: <9706130832.AA11656@bambi.unibe.ch> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 1958 Status: OR >>>>> Thomas Wenger writes: > So I have to build the omniORB binaries with gnu g++. But there is a > problem when linking posix.o. CC was used to link posix.o into a shared library. It doesn't work because the object file was compiled by g++. > Does anybody know how to use omniORB with g++ under Solaris? I don't know about g++ under Solaris but with g++ 2.7.2 under x86 Linux, C++ shared libraries that have exceptions enabled *do not work*. Your option at the moment is to use static libraries only. To compile omniORB using gcc 2.7.2 ---------------------------------- - Edit the make configuration file mk/sun4_sosV_5.5.mk Change the following make variables: CXX = g++ CXXDEBUGFLAGS = CXXOPTIONS = -fhandle-exceptions -Wall -Wno-unused CXXLINK = g++ #OMNITHREAD_STATIC_LIB = -Wl,-Bstatic -lomnithread -Wl,-Bdynamic -lthread -lposix4 OMNITHREAD_STATIC_LIB = -Wl,-Bstatic -lomnithread -Wl,-Bdynamic -lpthread -lposix4 OMNIORB_STATIC_LIB = -Wl,-Bstatic -lomniORB2 -Wl,-Bdynamic $(OMNITHREAD_STATIC_LIB) \ -lsocket -lnsl - Do not build the shared libraries. This is achieved by replacing the entire content of ./src/lib/omnithread/sharedlib/sun4_sosV_5.5.mk and ./src/lib/omniORB2/sharedlib/sun4_sosV_5.5.mk with these two lines: .DEFAULT: @echo done - Change the lines in file src/appl/omniNames/log.cc to the following: // a bug in the Solaris runtime means that the fd doesn't get closed. #if defined(__sunos__) && defined(__SUNPRO_CC) if (close(fd) < 0) throw IOError(); #endif Thanks to Stefan Ubben for pointing this out. Regards, Sai-Lai Lo -- 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 thomas.kullmann@mainz.netsurf.de Wed Jun 18 07:33:20 1997 Return-Path: Received: from wiesbaden.netsurf.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id HAA18212; Wed, 18 Jun 1997 07:30:25 +0100 From: thomas.kullmann@mainz.netsurf.de Received: from King by wiesbaden.netsurf.de with smtp (Smail3.1.28.1 #10) id m0weFDb-001loSC; Wed, 18 Jun 97 09:31 MET DST Sender: tom@mainz.netsurf.de Message-ID: <33A72093.76DB0075@mainz.netsurf.de> Date: Tue, 17 Jun 1997 23:41:07 +0000 X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.25 i586) MIME-Version: 1.0 To: omniorb mailing list Subject: Java Language Mapping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 155 Status: OR Hi there - does anyone know about a Java Language Mapping for the omniORB - I havent found anything bout it in the Documentation. TIA, Thomas Kullmann From S.Lo@orl.co.uk Wed Jun 18 09:30:44 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id JAA19407; Wed, 18 Jun 1997 09:29:33 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id JAA31783; Wed, 18 Jun 1997 09:29:31 +0100 Date: Wed, 18 Jun 1997 09:29:31 +0100 Message-Id: <199706180829.JAA31783@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Java Language Mapping In-Reply-To: <33A72093.76DB0075@mainz.netsurf.de> References: <33A72093.76DB0075@mainz.netsurf.de> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 573 Status: OR >>>>> thomas kullmann writes: > Hi there - does anyone know about a Java Language > Mapping for the omniORB - I havent found anything > bout it in the Documentation. This probably should go into FAQ. No, there is no java mapping for omniORB and there is no plan for one. Regards, Sai-Lai Lo -- 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 israel@his.com Wed Jun 18 17:22:40 1997 Return-Path: Received: from ers.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA25196; Wed, 18 Jun 1997 17:17:47 +0100 Received: from desoto.ers.com ([192.168.0.21]) by gateway.ers.com with SMTP id <27777-1>; Wed, 18 Jun 1997 12:00:40 -0400 Received: by desoto.ers.com (SMI-8.6/SMI-SVR4) id MAA26677; Wed, 18 Jun 1997 12:04:12 -0400 Date: Wed, 18 Jun 1997 12:04:12 -0400 Message-Id: <199706181604.MAA26677@desoto.ers.com> From: Bruce Israel To: omniorb-list@orl.co.uk Subject: threading under omniORB. Content-Length: 670 Status: OR Well, I hate sending mail to a mailing list before I've been reading it for a while, but I'm under time pressure here. My apologies if this question has been discussed previously or answered somewhere else that I haven't seen. We're building a system which is going a server running multiple agents, each in it's own thread. We'd like to have a client (in Java, using OrbixWeb) also mult-threaded, with each thread connecting to one of the server agents. Is it possible in omniORB to implement a thread-per-object server model so that different objects aren't blocked when requests come in? Bruce -- Bruce Israel ExpLore Reasoning Systems, Inc. israel@his.com From huaji@extreme.indiana.edu Wed Jun 18 20:54:38 1997 Return-Path: Received: from olympus.extreme.indiana.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id UAA27273; Wed, 18 Jun 1997 20:54:01 +0100 Received: by olympus.extreme.indiana.edu (8.8.5/IUCS.1.77) id OAA23633; Wed, 18 Jun 1997 14:53:55 -0500 (EST) Date: Wed, 18 Jun 1997 14:53:55 -0500 (EST) From: "Hua Ji" Message-Id: <199706181953.OAA23633@olympus.extreme.indiana.edu> To: omniorb-list@orl.co.uk Subject: Hi,there Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: hbNezknp9UEenN3LhLCENA== Content-Length: 212 Status: OR Hi, there, I got a question. Can omniORB/iiop interoperate with DCE/ciop? In other words, Is there a (half) bridge between iiop and ciop? I am looking for your reply! Thanks for your attention! Hua Ji From S.Lo@orl.co.uk Thu Jun 19 10:37:20 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA03520; Thu, 19 Jun 1997 10:30:11 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id KAA12576; Thu, 19 Jun 1997 10:30:08 +0100 Date: Thu, 19 Jun 1997 10:30:08 +0100 Message-Id: <199706190930.KAA12576@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Hi,there In-Reply-To: <199706181953.OAA23633@olympus.extreme.indiana.edu> References: <199706181953.OAA23633@olympus.extreme.indiana.edu> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 970 Status: OR >>>>> Hua Ji writes: > Can omniORB/iiop interoperate with DCE/ciop? In other words, Is there a > (half) bridge between iiop and ciop? No, I'm not aware of any bridge implementation to link IIOP with DCE CIOP. Given that all CORBA 2 compliant ORBs must support IIOP, it seems to me that DCE CIOP is only useful for connecting back to existing DCE services. On the otherhand, if you are looking for a bridge because the ORB you are using on one of your platforms only support DCE CIOP (e.g. ObjectBroker on OpenVMS), it may worth your while to simply port omniORB to the platform. If you need more information, please follow-up by sending email to omniorb@orl.co.uk. Regards, Sai-Lai Lo -- 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 ulbrich@hexmac.com Wed Jun 18 18:42:29 1997 Return-Path: Received: from hexbase.hexmac.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA26147; Wed, 18 Jun 1997 18:41:00 +0100 Received: from [134.60.219.13] (dyn19.ulm.netsurf.de [195.180.108.82]) by hexbase.hexmac.de (8.6.11/8.6.9) with SMTP id TAA05458 for ; Wed, 18 Jun 1997 19:40:15 +0200 Message-Id: <199706181740.TAA05458@hexbase.hexmac.de> Subject: Re: Java Language Mapping Date: Wed, 18 Jun 97 19:41:21 +0200 x-sender: ulbrich@hexbase.hexmac.de x-mailer: Claris Emailer 1.1 From: Jan Ulbrich To: "OmniORB Mailinglist" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Length: 693 Status: OR Hi Thomas, >Hi there - does anyone know about a Java Language >Mapping for the omniORB - I havent found anything >bout it in the Documentation. I'm using the JavaIDL ORB from JavaSoft - works fine with omniORB. Only problem is the Nameserver: omniORB implements a CosNaming server but JavaIDL uses different Repository IDs - I just used a newly generated copy and used it instead of the CosNaming module of the JavaIDL package. Have a nice day, Jan Ulbrich -- /// Jan Ulbrich - flynn (remember tron?) o-o Margarethe von Wrangellweg 1, 89075 Ulm, Germany L Phone +49731552806, Fax +4973159334, Mobil +491727429683, - WWW http://www.hexmac.de/~ulbrich, eMail ulbrich@hexmac.com From S.Lo@orl.co.uk Wed Jun 18 20:33:48 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id UAA27085; Wed, 18 Jun 1997 20:31:39 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id UAA09736; Wed, 18 Jun 1997 20:31:37 +0100 Date: Wed, 18 Jun 1997 20:31:37 +0100 Message-Id: <199706181931.UAA09736@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: threading under omniORB. In-Reply-To: <199706181604.MAA26677@desoto.ers.com> References: <199706181604.MAA26677@desoto.ers.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 4750 Status: OR The threading model in omniORB is one thing that I'll definitely add to the documentation. >>>>> Bruce Israel writes: > We're building a system which is going a server running multiple agents, > each in it's own thread. We'd like to have a client (in Java, using > OrbixWeb) also mult-threaded, with each thread connecting to one of the > server agents. Is it possible in omniORB to implement a > thread-per-object server model so that different objects aren't blocked > when requests come in? The GIOP protocol is asymmetric. For each network connection, one end always acts as the client and the other end always acts as the server. Only the client end can initiate and only the server end can receive GIOP requests. To drive the GIOP protocol, omniORB is designed to achieve high performance by removing unnecessary thread switching/multiplexing. At the same time, maximum level of concurrency is provided by dynamically create one or more connections to the same remote address space. Here is an outline: At the server end ----------------- For *each* network connection, a thread blocks waiting for incoming requests. When a request message arrives, the thread partially unmarshal the request to the extend that it can identify which object the request is targeted. It then performs an upcall to the stub-level dispatch routine specific to the object. The dispatch routine further unmarshals the request and invokes on the specified operation. The dispatch routine then marshals the results and sends back the reply. On return from the dispatch routine, the cycle begins again with the thread blocks waiting for another incoming request. When the thread is in the upcall, any requests arriving at that network connection *will not* be processed. Notice that requests coming in from other network connections are handled by other threads dedicated to these connections concurrently. These requests may be directed to the same object and hence more than one upcall may be dispatched to the same object at the same time. At the client end ----------------- A thread calls on an operation of an object in a remote address space. This is routed to the proxy object in the local address space. Through the proxy object, the thread obtains *exclusive* access to a network connection, marshals in the arguments, sends off the request, and blocks waiting for the reply. After the reply arrives and is unmarshalled, the thread *release* the network connection and the operation is completed. The network connection can then be used by the same or another thread to issue requests to the objects in the same remote address space. If during the time the thread holds exclusive access to the network connection another thread invokes on an object (which may or may not be the same object) that is in the same remote address space as the previous one, a new network connection will be created on-the-fly and will be used for delivering the new request. ---------------------------------------------------------------------- > Is it possible in omniORB to implement a thread-per-object server model > so that different objects aren't blocked when requests come in? If both ends are omniORB, a request will not be blocked by other requests, whether it is for the same or for different objects. If the client side is not omniORB and if concurrent requests are multiplexed by the client ORB onto the same connection, then the requests will be processed in FIFO order. Having said that, it is quite possible to enhance the current server end implementation to concurrently handle requests multiplexed onto one connection. For example, the server thread can spawn off a new thread to block waiting on the connection before it performs the upcall. Whether to spawn off a new thread can be decided on a per object basis. ------------------------------------------------------------------------- > We're building a system which is going a server running multiple agents, > each in it's own thread. We'd like to have a client (in Java, using > OrbixWeb) also mult-threaded, with each thread connecting to one of the > server agents. IMHO, it may be worth checking whether OrbixWeb does indeed send off requests from different threads concurrently, especially when the requests are all directed to the same remote address space. -------------------------------------------------------------------------- I hope this information is useful. Regards, Sai-Lai Lo -- 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 brian.burton@burton-computer.com Wed Jun 18 22:03:03 1997 Return-Path: Received: from bcc01.burton-computer.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id WAA27865; Wed, 18 Jun 1997 22:01:55 +0100 Received: from bcc01.burton-computer.com (localhost [127.0.0.1]) by bcc01.burton-computer.com (8.8.5/8.8.5) with SMTP id RAA06671 for ; Wed, 18 Jun 1997 17:01:53 -0400 Sender: brian@bcc01.burton-computer.com Message-ID: <33A84CC1.41A1F1E6@burton-computer.com> Date: Wed, 18 Jun 1997 17:01:53 -0400 From: Brian Burton Organization: Burton Computer Corporation X-Mailer: Mozilla 3.01Gold (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Re: New omnithread library References: <199706161200.NAA09410@pumpkin.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1613 Status: OR Tristan Richardson wrote: > > In response to overwhelming demand (:-)) there is a new version of the > omnithread library with several improvements. The new library will be > included with the next release of omniORB2, scheduled for early next week. > [ description of improvements snipped ] > > Use of exceptions and the new lock classes actually makes the source for > the implementations of omnithread about 30-40% smaller - always a good > sign! > > Thanks are due to Brian Burton for suggesting most of these changes. > Thanks for the many improvements! I am looking forward to using the new library! And thanks for mentioning my name. I guess the squeaky wheel gets the thanks :-) I do have a suggestion for an additional feature that you might want to consider. I have been developing another thread library with Adriaan Joubert. We have implemented a scheme for passing exceptions across thread boundaries. When a thread dies with an exception derived from a special base class (EasyThreadFailure in our library) we store a copy of the exception in the dead thread. When another thread calls join() to join with the dead thread, the exception is rethrown so that the joining thread can deal with it. This makes reporting errors in a multithreaded program via exceptions fairly simple. If you're interested in the details I'd be happy to provide them. Thanks again for omniORB! ++Brian -- Brian Burton Custom Software Development Burton Computer Corporation Java, C++, Orbix, Tuxedo brian.burton@burton-computer.com OO Consulting and Mentoring From renzo.tomaselli@tecnotp.inet.it Mon Jun 23 15:30:56 1997 Return-Path: Received: from venere.inet.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA06750; Mon, 23 Jun 1997 15:22:58 +0100 Received: (from trusted@localhost) by venere.inet.it (8.6.10/8.6.10) id QAA52094 for ; Mon, 23 Jun 1997 16:22:45 +0200 Message-Id: <199706231422.QAA52094@venere.inet.it> Received: from tecnotp.inet.it(194.20.15.148) by venere.inet.it via I-SMTP id queue/s-194.20.15.148-GroWMb; Mon Jun 23 16:22:38 1997 From: "Renzo Tomaselli" To: Subject: Win32 definitions Date: Mon, 23 Jun 1997 16:25:05 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 624 Status: OR Hi folks, just to make our life a little easier, what about putting the following defs in CORBA_sysdep.h, inside the _MSC_VER condition: #define __NT__ #define NTArchitecture #ifdef _M_IX86 #define _X86_ #endif #define _CORBA_MODULE namespace Thanks, Renzo Tomaselli --------------------------------------------------------------------------- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 461 773164 Fax. +39 461 773180 e-mail: renzo.tomaselli@tecnotp.inet.it --------------------------------------------------------------------------- From M.J.Reeve@city.ac.uk Tue Jun 24 00:42:55 1997 Return-Path: Received: from mailgate.city.ac.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id AAA11899; Tue, 24 Jun 1997 00:42:00 +0100 Received: from netmail.city.ac.uk [138.40.12.1] by mailgate.city.ac.uk with esmtp (City SMTP listener 1.62 #2) id 0wgIiD-0002kb-00; Tue, 24 Jun 1997 00:39:57 +0100 Received: from exeter.city.ac.uk (exeter.city.ac.uk [138.40.1.4]) by netmail.city.ac.uk (/City/2.1) with ESMTP id AAA05274 for ; Tue, 24 Jun 1997 00:41:59 +0100 Received: from localhost (ax511@localhost) by exeter.city.ac.uk (8.6.12/8.6.12) with SMTP id AAA10082 for ; Tue, 24 Jun 1997 00:41:58 +0100 X-Authentication-Warning: exeter.city.ac.uk: ax511 owned process doing -bs Date: Tue, 24 Jun 1997 00:41:53 +0100 (BST) From: Reeve MJ X-Sender: ax511@exeter To: omniorb-list@orl.co.uk Subject: Re: omniORB Server + Visibroker Client In-Reply-To: <199706231422.QAA52094@venere.inet.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 638 Status: OR Hi ! I'm trying to write an app on NT using an omniORB app as a server and Visibroker for Java apps as clients. Things seem to be generall okay - the client and server talk to each other with no problems - BUT when I'm bebugging the server I get a "First chance" exceptions when the client app terminates. Is this something to do with the fact that the client does not "release" the implementation object before terminating (the mapping used by visibroker for Java does not seem to include any equivalent of "release") or is it something completely different ??? Any assistance would be greatly appreciated. Thanks. Marcus Reeve. From wenger@iam.unibe.ch Tue Jun 24 16:09:17 1997 Return-Path: Received: from arwen.unibe.ch by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA21153; Tue, 24 Jun 1997 16:04:42 +0100 Received: from asterix (actually asterix.unibe.ch) by arwen with SMTP (PP); Tue, 24 Jun 1997 17:03:05 +0200 Received: from milou.unibe.ch by asterix (5.x/SMI-SVR4) id AA27344; Tue, 24 Jun 1997 17:03:35 +0200 Received: by milou.unibe.ch (5.x/SMI-SVR4) id AA07919; Tue, 24 Jun 1997 17:03:10 +0200 Date: Tue, 24 Jun 1997 17:03:10 +0200 From: wenger@iam.unibe.ch (Thomas Wenger) Message-Id: <9706241503.AA07919@milou.unibe.ch> To: omniorb-list@orl.co.uk Subject: Java ORB to omniORB? Cc: wenger@iam.unibe.ch X-Sun-Charset: US-ASCII Content-Length: 455 Status: OR Hello you "omniORBers" I am trying to connect JavaIDL ORB by JavaSoft to omniORB with its naming. But there is still a problem. My question: Are there any experiences how that works and how it can be done? Are there any hints or examples. Is there another free Java ORB that does better work with omniORB? Every hint or remark is very precious to me. Thank you. Thomas Wenger, wenger@iam.unibe.ch University of Berne, Institute for Computer Science From A.Lehmkuehler@imech.com Wed Jun 25 09:51:20 1997 Return-Path: Received: from imech.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id JAA00966; Wed, 25 Jun 1997 09:50:11 +0100 Received: from bohrarm (bohrarm.imech.uni-duisburg.de [134.91.124.62]) by imech.com with SMTP (8.7.5/8.7.3) id KAA20033 for ; Wed, 25 Jun 1997 10:50:08 +0200 (METDST) Message-ID: <33B0DBB6.2F58@imech.com> Date: Wed, 25 Jun 1997 10:49:58 +0200 From: Andreas Lehmuehler Reply-To: A.Lehmkuehler@imech.com Organization: Imech GmbH X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omniORB on HPUX10.20 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 391 Status: OR Has anyone succesfully build omniORB an HPUX 10.20 using hp's c++-compiler? I've tried it but I've got several internal problems with the compiler. Any hints or suggestions? Andreas -- ================================================ Andreas Lehmkuehler EMail: A.Lehmkuehler@imech.com Institut fuer Mechatronik Tel.: 02841/101-262 ================================================ From renzo.tomaselli@tecnotp.inet.it Wed Jun 25 11:53:46 1997 Return-Path: Received: from venere.inet.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA02599; Wed, 25 Jun 1997 11:53:01 +0100 Received: (from trusted@localhost) by venere.inet.it (8.6.10/8.6.10) id MAA105376 for ; Wed, 25 Jun 1997 12:52:53 +0200 Message-Id: <199706251052.MAA105376@venere.inet.it> Received: from tecnotp.inet.it(194.20.15.148) by venere.inet.it via I-SMTP id queue/s-194.20.15.148-nAMayb; Wed Jun 25 12:52:50 1997 From: "Renzo Tomaselli" To: Subject: Enums & namespaces Date: Wed, 25 Jun 1997 12:56:12 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 797 Status: OR Hi there, I'm trying to use namespaces on NT (_CORBA_MODULE="namespace"), and I got a problem when an enum is defined at module level of idl: the generated code contains a few operator functions with the "friend" prefix (see Naming_NT.hh, line 38). MSVC 5.0 complains about it (error C2255) since "a friend function can only be declared in a class"; off course no problems exist when nested classes are used instead. Thanks, Renzo Tomaselli --------------------------------------------------------------------------- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 461 773164 Fax. +39 461 773180 e-mail: renzo.tomaselli@tecnotp.inet.it --------------------------------------------------------------------------- From ewc@orl.co.uk Wed Jun 25 13:49:23 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA04005; Wed, 25 Jun 1997 13:47:53 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id NAA22869; Wed, 25 Jun 1997 13:47:53 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199706251247.NAA22869@casabel.cam-orl.co.uk> Subject: Re: Java ORB to omniORB? To: wenger@iam.unibe.ch (Thomas Wenger) Date: Wed, 25 Jun 1997 13:47:52 +0100 (BST) Cc: omniorb-list@orl.co.uk In-Reply-To: <9706241503.AA07919@milou.unibe.ch> from "Thomas Wenger" at Jun 24, 97 05:03:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1373 Status: OR > > Hello you "omniORBers" > > I am trying to connect JavaIDL ORB by JavaSoft to omniORB with its naming. > But there is still a problem. > > My question: > Are there any experiences how that works and how it can be done? > Are there any hints or examples. > > Is there another free Java ORB that does better work with omniORB? > > Every hint or remark is very precious to me. Thank you. Some ORBs (e.g. HP ORB+, JavaIDL) supply a COS Naming IDL that uses the #pragma prefix "omg.org" preprocessor directive. The COS Naming IDL used in omniORB doesn't contain this directive. To get omniNames to interoperate with these ORBs, add the following line to the beginning of the file /src/lib/omniORB2/Naming.idl : #pragma prefix "omg.org" and re-compile omniORB. Note that the new omniNames won't be able to read the data file produced by the original omniNames. In the Win32 version, it will also be necessary to add the workarounds for Visual C++ bugs to the stubs. The workarounds are documented in the file README.win32 . The stubs should also be renamed to Naming_NT.hh and NamingSK_NT.cc . A number of people have reported success in getting omniORB (including omniNames) and JavaIDL to interoperate. Eoin. -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Labs Cambridge, UK From lennart.holen@agresso.no Wed Jun 25 13:52:30 1997 Return-Path: Received: from agrwall.agresso.no by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA04082; Wed, 25 Jun 1997 13:51:59 +0100 Received: from [195.1.61.2] (HELO localhost) by agrwall.agresso.no (AltaVista Mail V1.0/1.0 BL18 listener) id 0000_004e_33b1_1417_1d63; Wed, 25 Jun 1997 14:50:31 +0200 Message-ID: From: Lennart Holen To: "'omniorb-list@orl.co.uk'" Subject: Distribute processing with omniorb2 Date: Wed, 25 Jun 1997 14:54:24 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 549 Status: OR Hi! I have just installed omniorb2 on NT and the examples works fine on one single machine. I would try to use COS nameservice and test client/server in network. To run the example eg3_clt on a client machine I do have to start a nameservice on the client machine too? How do I use the nameclt and how do I bind two machines together? This is not documented in omniorb or not given a straightforward example. When I look up in CORBA books their examples are done with other propitary services or with a pseudo nameservice. Regards, Lennart Holen From cobrien@access.digex.net Wed Jun 25 14:15:20 1997 Return-Path: Received: from access2.digex.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA04414; Wed, 25 Jun 1997 14:14:53 +0100 Received: (from cobrien@localhost) by access2.digex.net (8.8.4/8.8.4) id JAA00520; Wed, 25 Jun 1997 09:14:40 -0400 (EDT) From: "Cary B. O'Brien" Message-Id: <199706251314.JAA00520@access2.digex.net> Subject: Re: omniORB on HPUX10.20 To: A.Lehmkuehler@imech.com Date: Wed, 25 Jun 1997 09:14:40 -0400 (EDT) Cc: omniorb-list@orl.co.uk In-Reply-To: <33B0DBB6.2F58@imech.com> from Andreas Lehmuehler at "Jun 25, 97 10:49:58 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 486 Status: OR > Has anyone succesfully build omniORB an HPUX 10.20 using hp's > c++-compiler? > I've tried it but I've got several internal problems with the compiler. > > Any hints or suggestions? > Sure -- make sure you have all the patches for the C++ compiler. We had a _heck_ of a time getting threading and exceptions to work. Note that this was with HPUX 9.X, but it can't hurt to check, and was a different project. I have not tried omniORB on HPUX. -- cary cobrien@access.digex.net From ewc@orl.co.uk Wed Jun 25 14:28:41 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA04556; Wed, 25 Jun 1997 14:25:51 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id OAA23104; Wed, 25 Jun 1997 14:25:50 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199706251325.OAA23104@casabel.cam-orl.co.uk> Subject: Re: Distribute processing with omniorb2 To: lennart.holen@agresso.no (Lennart Holen) Date: Wed, 25 Jun 1997 14:25:50 +0100 (BST) Cc: omniorb-list@orl.co.uk In-Reply-To: from "Lennart Holen" at Jun 25, 97 02:54:24 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1706 Status: OR Hi, > I have just installed omniorb2 on NT and the examples works fine on one > single machine. I would try to use COS nameservice and test > client/server in network. To run the example eg3_clt on a client machine > I do have to start a nameservice on the client machine too? > How do I use the nameclt and how do I bind two machines together? > This is not documented in omniorb or not given a straightforward > example. > When I look up in CORBA books their examples are done with other > propitary services or with a pseudo nameservice. There is no need to run omniNames on the client machine as well. You only need to have omniNames running on one machine on your network. When you run omniNames, it outputs a stringified IOR. You should copy the IOR (including the IOR: prefix), and add it as the (string or REG_SZ) value NAMESERVICE under the key HKEY_LOCAL_MACHINE\SOFTWARE\ORL\omniORB\2.0 Use the tool REGEDT32.EXE (on NT 3.5) or REGEDIT.EXE (on NT 4) to do this. You must add the IOR to the registry of every machine upon which you want to run omniORB applications. When you have done this, you can run nameclt, eg3, etc. Note that you can use a configuration file instead of the registry. The steps for configuring the Naming Service on Win32 platforms are documented in README.win32 . It is also documented in the omniORB User's Guide ("Setting Up Your Environment") in chapter 1. The documentation on nameclt is in the omniORB utilities guide ( utilities.{pdf,ps} ). Documentation on the examples is in chapter 2 of the omniORB User's Guide. Eoin. -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Labs Cambridge, UK From A.Lehmkuehler@imech.com Wed Jun 25 15:45:39 1997 Return-Path: Received: from imech.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA05882; Wed, 25 Jun 1997 15:39:26 +0100 Received: from bohrarm (bohrarm.imech.uni-duisburg.de [134.91.124.62]) by imech.com with SMTP (8.7.5/8.7.3) id QAA20459 for ; Wed, 25 Jun 1997 16:39:25 +0200 (METDST) Message-ID: <33B12D96.1A5@imech.com> Date: Wed, 25 Jun 1997 16:39:18 +0200 From: Andreas Lehmuehler Reply-To: A.Lehmkuehler@imech.com Organization: Imech GmbH X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: omniORB Mailinglist Subject: Re: Distribute processing with omniorb2 References: <199706251325.OAA23104@casabel.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2471 Status: OR Eoin Carroll wrote: > > I have just installed omniorb2 on NT and the examples works fine on one > > single machine. I would try to use COS nameservice and test > > client/server in network. To run the example eg3_clt on a client machine > > I do have to start a nameservice on the client machine too? > > How do I use the nameclt and how do I bind two machines together? > > This is not documented in omniorb or not given a straightforward > > example. > > When I look up in CORBA books their examples are done with other > > propitary services or with a pseudo nameservice. > > There is no need to run omniNames on the client machine as well. You only need > to have omniNames running on one machine on your network. > > When you run omniNames, it outputs a stringified IOR. You should > copy the IOR (including the IOR: prefix), and add it as the (string or REG_SZ) > value NAMESERVICE under the key HKEY_LOCAL_MACHINE\SOFTWARE\ORL\omniORB\2.0 > Use the tool REGEDT32.EXE (on NT 3.5) or REGEDIT.EXE (on NT 4) to do this. > You must add the IOR to the registry of every machine upon which you want to > run omniORB applications. When you have done this, you can run nameclt, eg3, > etc. > Note that you can use a configuration file instead of the registry. > > The steps for configuring the Naming Service on Win32 platforms are documented > in README.win32 . It is also documented in the omniORB User's Guide > ("Setting Up Your Environment") in chapter 1. The documentation on nameclt is > in the omniORB utilities guide ( utilities.{pdf,ps} ). > Documentation on the examples is in chapter 2 of the omniORB User's Guide. I've tried this and it has failed. Whenever I've started eg3_impl I've got a 'abnormal program termination'. The other examples are working fine. I've added the value in the registry and made a config-file and set the env-variable OMNIORB_CONFIG, but nothing happend. I've tried to debug the program with MSVC4.2 but it also failed, because I couldn't single-step through the libraries (omniORB2 and omnithread). I've recompiled the hole distribution with debug-informations included but it doesn't fit. Perhaps the compiler isn't the best one or I'am a little bit too stupid. Is there perhaps a little thing I've forgotten? Andreas -- ================================================ Andreas Lehmkuehler EMail: A.Lehmkuehler@imech.com Institut fuer Mechatronik Tel.: 02841/101-262 ================================================ From huaji@extreme.indiana.edu Wed Jun 25 17:48:25 1997 Return-Path: Received: from olympus.extreme.indiana.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA07681; Wed, 25 Jun 1997 17:40:59 +0100 Received: by olympus.extreme.indiana.edu (8.8.5/IUCS.1.77) id LAA16829; Wed, 25 Jun 1997 11:40:56 -0500 (EST) Date: Wed, 25 Jun 1997 11:40:56 -0500 (EST) From: "Hua Ji" Message-Id: <199706251640.LAA16829@olympus.extreme.indiana.edu> To: ewc@orl.co.uk Subject: questions about nameservices Cc: omniorb-list@orl.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: PaSPEubt3PJP4+LTqOh/0A== Content-Length: 1331 Status: OR Hi, folks, I got 2 questions. Thanks for your attention. 1. "omniORB Nmmeservice is centralized ?!" 1.1 Is there only one Nameservice daemon in a "omniORB" domain? Is it proper in terms of performance if the numbers of clients asking Nameservice are too huge:) 1.2 Of course, we can fork some other Nameservice daemons in a distributed environment(eg., intra-net), but it means different users will "see" some different name contexts in its local configuration file(for example, it is /etc/omniORB.cfg under UNIX). Each of Nameservices daemon will be only responsible for its own name context(service database). So a question arises: Can these Nameservice daemon co-operate based on a protocol(eg. x.500)? For example, client1 issue a service(Service_x) query to Nameservice daemon 1. However, Serverce_x is registed in another Name contest mainytained by Namerservice daemon 2. So client can't get IOR of Service_X if Nameservice daemon 1 and Nameservice daemon 2 can't co-operate with each other. ---------------------------------------------------------------------- 2. How can omniORB interoperate with other half bridge if omniORB Nameservice can't implicitely cooperate with other name context maintained by other Name service daemon? ------------------------------------------- Regards, Hua From Fred_Stevens@dome.com Wed Jun 25 17:48:25 1997 Return-Path: Received: from ntserver2.dome.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA07664; Wed, 25 Jun 1997 17:40:29 +0100 From: Fred_Stevens@dome.com Received: by ntserver2.dome.com(Lotus SMTP MTA v1.06 (346.8 3-18-1997)) id 852564C1.005BB171 ; Wed, 25 Jun 1997 12:41:32 -0400 X-Lotus-FromDomain: DOMENOTES To: omniorb-list@orl.co.uk Message-ID: <852564C1.005BA330.00@ntserver2.dome.com> Date: Wed, 25 Jun 1997 12:41:28 -0400 Subject: blobs across omniORB2 Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Length: 593 Status: OR Fred Stevens@DOMENOTES 06/25/97 12:41 PM I'm putting together a test of throughput for passing blobs (on the order of 10 MB) through omniorb. Can anyone give me any suggestions about how to do this most efficiently? Currently I'm using the BOA interface to pass sequences of octets. Is there a better way of doing this? Can I write to a lower-level interface and perhaps avoid some of the data copying? Thanks for any and all suggestions. I do understand that using an ORB will not be as efficient as using raw sockets. Fred Stevens DOME imaging systems Fred_Stevens@dome.com From Fred_Stevens@dome.com Wed Jun 25 18:08:03 1997 Return-Path: Received: from ntserver2.dome.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA07990; Wed, 25 Jun 1997 18:03:23 +0100 From: Fred_Stevens@dome.com Received: by ntserver2.dome.com(Lotus SMTP MTA v1.06 (346.8 3-18-1997)) id 852564C1.005DCBA7 ; Wed, 25 Jun 1997 13:04:29 -0400 X-Lotus-FromDomain: DOMENOTES To: omniorb-list@orl.co.uk Message-ID: <852564C1.005DC084.00@ntserver2.dome.com> Date: Wed, 25 Jun 1997 13:04:27 -0400 Subject: blobs across omniORB2 Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Length: 593 Status: OR Fred Stevens@DOMENOTES 06/25/97 01:04 PM I'm putting together a test of throughput for passing blobs (on the order of 10 MB) through omniorb. Can anyone give me any suggestions about how to do this most efficiently? Currently I'm using the BOA interface to pass sequences of octets. Is there a better way of doing this? Can I write to a lower-level interface and perhaps avoid some of the data copying? Thanks for any and all suggestions. I do understand that using an ORB will not be as efficient as using raw sockets. Fred Stevens DOME imaging systems Fred_Stevens@dome.com From ewc@orl.co.uk Wed Jun 25 18:19:08 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA08163; Wed, 25 Jun 1997 18:17:55 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id SAA24523; Wed, 25 Jun 1997 18:17:54 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199706251717.SAA24523@casabel.cam-orl.co.uk> Subject: Re: questions about nameservices To: huaji@extreme.indiana.edu (Hua Ji) Date: Wed, 25 Jun 1997 18:17:54 +0100 (BST) Cc: omniorb-list@orl.co.uk In-Reply-To: <199706251640.LAA16829@olympus.extreme.indiana.edu> from "Hua Ji" at Jun 25, 97 11:40:56 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2688 Status: OR Hi, > > I got 2 questions. Thanks for your attention. > > 1. > "omniORB Nmmeservice is centralized ?!" > > 1.1 Is there only one Nameservice daemon in a "omniORB" domain? Is it proper in > terms of performance if the numbers of clients asking Nameservice are too huge:) > No, you can run as many instances of a COS Naming Service (e.g. omniNames) as you like. Furthermore, you can federate the instances of the COS Naming Service. Just bind the (root) context of one Naming Service instance as an object or context in another. In omniNames, you can use the nameclt program to do this. Note that you don't necessarily have to use the root context - you can bind any of the contexts in one Naming Service to an object or context in another. However, as Tristan wrote a few weeks ago, it is worth bearing in mind that there is a subtle difference between using the "bind" operation and the "bind_context" operation for federating name servers. I quote from his e-mail: " Using "bind" will bind another nameserver as an object (BindingType = nobject), whereas "bind_context" will result in a binding as a context (BindingType = ncontext). Only in this second case may a compound name which refers to an object in the second nameserver be resolved in a single call to the first nameserver. For example say nameserver 2 is bound as a context with name "/a/b" inside nameserver 1. An object bound as "/c/d" inside nameserver 2 can be accessed from nameserver 1 by the name "/a/b/c/d". If on the other hand, nameserver 2 is bound as an object, then two calls are necessary. A client must first resolve "/a/b" to get an object reference for nameserver 2, and then use this to resolve "/c/d" inside nameserver 2. " Note that if you're using nameclt's bind_context operation, you must specify the -advanced option. > 1.2 Of course, we can fork some other Nameservice daemons in a distributed > environment(eg., intra-net), but it means different users will "see" some > different name contexts in its local configuration file(for example, it is > /etc/omniORB.cfg under UNIX). Each of Nameservices daemon will be only > responsible for its own name context(service database). So a question arises: > Can these Nameservice daemon co-operate based on a protocol(eg. x.500)? > Yes, they can co-operate using CORBA. See above. > > 2. How can omniORB interoperate with other half bridge if omniORB Nameservice> can't implicitely cooperate with other name context maintained by other Name > service daemon? > Again, see above. Eoin. -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Lab Cambridge, UK From arao@compuware.com Wed Jun 25 18:46:58 1997 Return-Path: Received: from stargate.compuware.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA08649; Wed, 25 Jun 1997 18:46:09 +0100 Received: by stargate.compuware.com id AA04609 (InterLock SMTP Gateway 3.0 for omniorb-list@orl.co.uk); Wed, 25 Jun 1997 13:46:06 -0400 Message-Id: <199706251746.AA04609@stargate.compuware.com> Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-2); Wed, 25 Jun 1997 13:46:06 -0400 From: arao@compuware.com (Anant Rao) Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-1); Wed, 25 Jun 1997 13:46:06 -0400 Date: Wed, 25 Jun 1997 10:45:45 -0700 To: omniorb-list@orl.co.uk Subject: Re: Auto startup of servers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: uCIYKsga0XrevTroxuPwWA== Content-Length: 254 Status: OR Hi, Visibroker has a facility called, 'oad', that starts a server, if not running, when a client makes a call to the server. This is like a server-on-demand. Is there such a facility in omniOrb also or any way we can emulate it? Thanks very much! From huaji@extreme.indiana.edu Wed Jun 25 18:54:38 1997 Return-Path: Received: from olympus.extreme.indiana.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA08768; Wed, 25 Jun 1997 18:54:28 +0100 Received: by olympus.extreme.indiana.edu (8.8.5/IUCS.1.77) id MAA16947; Wed, 25 Jun 1997 12:54:26 -0500 (EST) Date: Wed, 25 Jun 1997 12:54:26 -0500 (EST) From: "Hua Ji" Message-Id: <199706251754.MAA16947@olympus.extreme.indiana.edu> To: omniorb-list@orl.co.uk Subject: Hi, ask help Content-Length: 1332 Status: OR Hi, folks, I got 2 questions. Thanks for your attention. 1. "omniORB Nmmeservice is centralized ?!" 1.1 Is there only one Nameservice daemon in a "omniORB" domain? Is it proper in terms of performance if the numbers of clients asking Nameservice are too huge:) 1.2 Of course, we can fork some other Nameservice daemons in a distributed environment(eg., intra-net), but it means different users will "see" some different name contexts in its local configuration file(for example, it is /etc/omniORB.cfg under UNIX). Each of Nameservices daemon will be only responsible for its own name context(service database). So a question arises: Can these Nameservice daemon co-operate based on a protocol(eg. x.500)? For example, client1 issue a service(Service_x) query to Nameservice daemon 1. However, Serverce_x is registed in another Name contest mainytained by Namerservice daemon 2. So client can't get IOR of Service_X if Nameservice daemon 1 and Nameservice daemon 2 can't co-operate with each other. ---------------------------------------------------------------------- 2. How can omniORB interoperate with other half bridge if omniORB Nameservice can't implicitely cooperate with other name context maintained by other Name service daemon? ------------------------------------------- Regards, Hua From arao@compuware.com Wed Jun 25 23:23:22 1997 Return-Path: Received: from stargate.compuware.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id XAA12034; Wed, 25 Jun 1997 23:22:27 +0100 Received: by stargate.compuware.com id AA14708 (InterLock SMTP Gateway 3.0 for omniorb-list@orl.co.uk); Wed, 25 Jun 1997 18:22:24 -0400 Message-Id: <199706252222.AA14708@stargate.compuware.com> Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-2); Wed, 25 Jun 1997 18:22:24 -0400 From: arao@compuware.com (Anant Rao) Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-1); Wed, 25 Jun 1997 18:22:24 -0400 Date: Wed, 25 Jun 1997 15:22:02 -0700 To: omniorb-list@orl.co.uk Subject: Re: omniOrb2 static libs on NT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: CZnIhWKy8eve0F1vcqBPYg== Content-Length: 170 Status: OR Hi, If I build omniOrb2 static libs on NT 4.0, can I copy them to NT 3.51 and use them "as is" or do I need to re-build them on NT 3.51 separately? Thanks very much! From arao@compuware.com Thu Jun 26 01:18:25 1997 Return-Path: Received: from stargate.compuware.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id BAA13586; Thu, 26 Jun 1997 01:17:54 +0100 Received: by stargate.compuware.com id AA16993 (InterLock SMTP Gateway 3.0 for omniorb-list@orl.co.uk); Wed, 25 Jun 1997 20:17:51 -0400 Message-Id: <199706260017.AA16993@stargate.compuware.com> Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-2); Wed, 25 Jun 1997 20:17:51 -0400 From: arao@compuware.com (Anant Rao) Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-1); Wed, 25 Jun 1997 20:17:51 -0400 Date: Wed, 25 Jun 1997 17:17:29 -0700 To: omniorb-list@orl.co.uk Subject: Re: omniorb2 on NT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: pGHPusocM2L1oix6EwXZYQ== Content-Length: 343 Status: OR Hi, I'm running my client as an NT v3.51 service and when it tries to resolve the names, I get an exception "NO_RESOURCES". 'omninames' is running and so is the Server. In fact, if I run my client in the foreground (i.e., started from a DOS command prompt), the client works fine. Any help greatly appreciated! Thanks very much! /Anant From A.Lehmkuehler@imech.com Thu Jun 26 08:04:48 1997 Return-Path: Received: from imech.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA18358; Thu, 26 Jun 1997 08:02:26 +0100 Received: from bohrarm (bohrarm.imech.uni-duisburg.de [134.91.124.62]) by imech.com with SMTP (8.7.5/8.7.3) id JAA21229 for ; Thu, 26 Jun 1997 09:02:09 +0200 (METDST) Message-ID: <33B213EF.3857@imech.com> Date: Thu, 26 Jun 1997 09:02:07 +0200 From: Andreas Lehmuehler Reply-To: A.Lehmkuehler@imech.com Organization: Imech GmbH X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: omniORB Mailinglist Subject: Re: omniORB on HPUX10.20 References: <199706251314.JAA00520@access2.digex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1191 Status: OR Cary B. O'Brien wrote: > > > Has anyone succesfully build omniORB an HPUX 10.20 using hp's > > c++-compiler? > > I've tried it but I've got several internal problems with the compiler. > > > > Any hints or suggestions? > > > Sure -- make sure you have all the patches for the C++ compiler. > We had a _heck_ of a time getting threading and exceptions > to work. Note that this was with HPUX 9.X, but it can't > hurt to check, and was a different project. I have not tried > omniORB on HPUX. The compiler generally works fine for me and we have applied every important patch beeing available. But especially with omniORB it produces some strange errors. There seems to be a internal compiler problem within the initialization of virtual classes, which can't be obviously resolved by adding a little hack in the sourve code. So I hoped that someone else had been succesful on building omniORB on HPUX 10.20, perhaps using another compiler like gcc or any other little trick. Andreas -- ================================================ Andreas Lehmkuehler EMail: A.Lehmkuehler@imech.com Institut fuer Mechatronik Tel.: 02841/101-262 ================================================ From matthew_newhook@stratos.ca Thu Jun 26 15:44:25 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA24635; Thu, 26 Jun 1997 15:42:33 +0100 Received: (qmail 24190 invoked by alias); 26 Jun 1997 14:42:24 -0000 From: "Matthew Newhook" Received: (qmail 24181 invoked from network); 26 Jun 1997 14:42:22 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 26 Jun 1997 14:42:22 -0000 Received: (qmail 25224 invoked by uid 213); 26 Jun 1997 14:42:21 -0000 Message-ID: <19970626121221.QV50310@odin.stratos.ca> Date: Thu, 26 Jun 1997 12:12:21 -0230 To: omniorb-list@orl.co.uk Subject: bug fixes. X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 2095 Status: OR Hi, I've fixed three bugs in omniORB. bug #1. String_member copy constructor is incorrect. Here is a patch. rcsdiff CORBA.h =================================================================== RCS file: RCS/CORBA.h,v retrieving revision 1.1 diff -r1.1 CORBA.h 34,36d33 < * Revision 1.1 1997/06/24 18:47:11 matthew < * Initial revision < * 185,188c182 < if (_ptr) { < string_free(_ptr); < _ptr = 0; < } --- > _ptr = 0; bug #2 The code generated by omniidl2 for exceptions is incorrect: Here is a patch. (NOTE: this patch is not optimal... but it fixes the problem for now) =================================================================== RCS file: RCS/o2be_operation.cc,v retrieving revision 1.1 diff -r1.1 o2be_operation.cc 520,521c520,522 < if (excpt->repoIdConstLen() > maxIdsize) < maxIdsize = excpt->repoIdConstLen(); --- > int len = strlen(excpt->repositoryID())+1; > if (len > maxIdsize) > maxIdsize = len; 972c973,974 < produceConstStringSizeCalculation(s,"_msgsize",excpt->repoIdConstLen()); --- > int len = strlen(excpt->repositoryID())+1; > produceConstStringSizeCalculation(s,"_msgsize", len); 976,977c978 < produceConstStringMarshalCode(s,"_s",excpt->repoIdConstName(), < excpt->repoIdConstLen()); --- > produceConstStringMarshalCode(s,"_s",excpt->repoIdConstName(), len); bug #3. If an attempt is made to access orb methods that lock the object table (such as is_equivalent) during the destruction of an implementation object a deadlock will occur. Here is a patch for this problem. RCS file: RCS/objectRef.cc,v retrieving revision 1.1 diff -r1.1 objectRef.cc 265a266 > omniObject* toDelete = 0; 268c269,270 < delete obj; --- > toDelete = obj; > //delete obj; 273a276,277 > if (toDelete != 0) > delete toDelete; Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From Edward.Scott@prismtech.co.uk Thu Jun 26 15:51:37 1997 Return-Path: Received: from alpha3.prismtech.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA24775; Thu, 26 Jun 1997 15:50:53 +0100 Received: from alpha3 (localhost.prismtech.co.uk [127.0.0.1]) by alpha3.prismtech.co.uk (8.6.9/8.6.9) with SMTP id PAA16195 for ; Thu, 26 Jun 1997 15:57:27 +0100 Sender: eas@prismtech.co.uk Message-ID: <33B28357.446B@prismtech.co.uk> Date: Thu, 26 Jun 1997 15:57:27 +0100 From: Edward Scott Organization: Prism Technologies Ltd X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: OmniORB list Subject: Debuging omniORB programs on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 628 Status: OR Dear All, I am having problems using gdb on Linux (RedHat 4.2, i386) to debug omniORB programs: breakpoints within threads other than the initial one don't seem to work. I suspect the total lack of support for threading in gdb for Linux... Has anyone else experienced the same problem and, better yet, got a solution? Regards, Edward -- ----------------------------------------------------------------------- Edward Scott ................Prism Technologies Ltd., Kingfisher House, http://www.prismtech.co.uk ..Kingsway, Tyne & Wear, NE11 0JQ, England Edward.Scott@prismtech.co.uk Tel +44(0)1914913983 Fax +44(0)1914913973 From renzo.tomaselli@tecnotp.inet.it Thu Jun 26 20:05:45 1997 Return-Path: Received: from venere.inet.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA27773; Thu, 26 Jun 1997 19:54:39 +0100 Received: (from trusted@localhost) by venere.inet.it (8.6.10/8.6.10) id UAA196436 for ; Thu, 26 Jun 1997 20:54:37 +0200 Message-Id: <199706261854.UAA196436@venere.inet.it> Received: from tecnotp.inet.it(194.20.15.148) by venere.inet.it via I-SMTP id queue/s-194.20.15.148-J1YBab; Thu Jun 26 20:54:36 1997 From: "Renzo Tomaselli" To: Subject: Re: Re: Distributed processing with omniorb2 Date: Thu, 26 Jun 1997 20:57:22 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 1265 Status: OR Andreas Lehmkuehler wrote: > I've tried this and it has failed. Whenever I've started eg3_impl I've > got a 'abnormal program termination'. The other examples are working fine I experienced an 'abnormal program term' in case of truncated pasting of ior into the registry (Win95); in this case there is an uncaught marshalling exception which leads to the termination above. However all examples terminated that way, and it was pretty hard to understand the reason until removing the registry entry; even eg1 didn't run anymore, while it did before touching the registry. About IORs, since OMG doesn't specify the string form of an IOR, why not using a real Ascii one, such as an URL ? Yes, it shouldn't be a directly managed string (by humans), however is has to be moved around; moreover, it keeps a Tcp/IP address which sometimes is useful to read, at least for checking out installations. Renzo Tomaselli --------------------------------------------------------------------------- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 461 773164 Fax. +39 461 773180 e-mail: renzo.tomaselli@tecnotp.inet.it --------------------------------------------------------------------------- From matthew_newhook@stratos.ca Thu Jun 26 20:39:47 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id UAA28165; Thu, 26 Jun 1997 20:29:59 +0100 Received: (qmail 27085 invoked by alias); 26 Jun 1997 19:29:56 -0000 From: "Matthew Newhook" Received: (qmail 27076 invoked from network); 26 Jun 1997 19:29:54 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 26 Jun 1997 19:29:54 -0000 Received: (qmail 22380 invoked by uid 213); 26 Jun 1997 19:29:54 -0000 Message-ID: <19970626165954.LK50900@odin.stratos.ca> Date: Thu, 26 Jun 1997 16:59:54 -0230 To: omniorb-list@orl.co.uk Subject: activator implementation X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 5566 Status: OR Hi, What follows is an implementation of activators. This provides the ability for on-demand loading of objects. What we at Stratos use this for is for is on-demand loading of objects from a message database. The objects are then unloaded after some period of inactivity. This implementation adds three methods. omniORB::register_activator(Omni_Activator* activator) omniORB::unregister_activator(Omni_Activator* activator) CORBA::Object_ptr BOA::make_object(const omniObjectKey& k, const char* type_id) This may not be the most stable of code, I wrote it yesterday and have been testing it for most of the day. It appears to work. Any questions send me some mail. These files are in include/omniORB2: RCS file: RCS/CORBA.h,v retrieving revision 1.1 diff -r1.1 CORBA.h 868a863,866 > Object_ptr make_object(const omniObjectKey& k, const char* type_id); > // omniORB2 specific. Create an proxy that refers to a local object > // with the specified key, and the specified type_id. > RCS file: RCS/omniInternal.h,v retrieving revision 1.1 diff -r1.1 omniInternal.h 74a75,76 > class Omni_Activator; > 129a132 > static omniObject *locateObjectInternal(omniObjectKey &k); 239c242,243 < protected: --- > //protected: > public: 322a327 > friend omniObject *omni::locateObjectInternal(omniObjectKey &k); RCS file: RCS/omniORB.h,v retrieving revision 1.1 diff -r1.1 omniORB.h 42a43,44 > class Omni_Activator; > 172a175,180 > // on demand object activation. > > static void register_activator(Omni_Activator* activator); > static void unregister_activator(Omni_Activator* activator); > static _CORBA_Boolean activate(omniObjectKey &k); > 174a183,184 > static omni_mutex activatorLock; > static Omni_Activator* activatorHead; 175a186,195 > }; > > class Omni_Activator > { > public: > virtual ~Omni_Activator() = 0; > virtual _CORBA_Boolean activate(const omniObjectKey& key) = 0; > private: > friend class omniORB; > Omni_Activator* pd_next; in src/lib/omniORB2 RCS file: RCS/corbaBoa.cc,v retrieving revision 1.1 diff -r1.1 corbaBoa.cc 161a162,202 > Object_ptr > CORBA:: > BOA::make_object(const omniObjectKey& k, const char* type_id) > { > IOP::TaggedProfileList * p = 0; > omniObject* omniObj = 0; > Object_ptr o = 0; > try > { > Rope *r = 0; > { > Rope_iterator next(&Anchor::incomingAnchor); > r = next(); > } > if (r == 0) > { > throw CORBA::INTERNAL(0,CORBA::COMPLETED_NO); > } > p = new IOP::TaggedProfileList(1); > if (p == 0) > { > throw CORBA::NO_MEMORY(0,CORBA::COMPLETED_NO); > } > p->length(1); > r->iopProfile((CORBA::Char *)&k, > sizeof(omniObjectKey), > ((IOP::TaggedProfileList &) *p)[0]); > omniObj = omni::createObjRef(type_id, type_id, p, 0); > delete p; > o = new Object(); > o->PR_setobj(omniObj); > } > catch (...) > { > delete p; > delete omniObj; > delete o; > throw; > } > return o; > } RCS file: RCS/objectRef.cc,v retrieving revision 1.1 diff -r1.1 objectRef.cc 279c279 < omni::locateObject(omniObjectKey &k) --- > omni::locateObjectInternal(omniObjectKey &k) 282,287c282,286 < omniObject **p = &omniObject::localObjectTable[omniORB::hash(k)]; < while (*p) { < if ((*p)->pd_objkey.native == k) { < (*p)->setRefCount((*p)->getRefCount()+1); < omniObject::objectTableLock.unlock(); < return *p; --- > omniObject *p = omniObject::localObjectTable[omniORB::hash(k)]; > while (p) { > if (p->pd_objkey.native == k) { > p->setRefCount(p->getRefCount()+1); > break; 289c288 < p = &((*p)->pd_next); --- > p = p->pd_next; 291a291,311 > return p; > } > > omniObject * > omni::locateObject(omniObjectKey &k) > { > omniObject* obj = locateObjectInternal(k); > if (obj != 0) > { > return obj; > } > > if (omniORB::activate(k)) > { > obj = locateObjectInternal(k); > if (obj != 0) > { > return obj; > } > } > RCS file: RCS/orb.cc,v retrieving revision 1.1 diff -r1.1 orb.cc 871a872,926 > > /*static*/ void > omniORB::register_activator(Omni_Activator* activator) > { > activatorLock.lock(); > > activator->pd_next = activatorHead; > activatorHead = activator; > > activatorLock.unlock(); > } > > /*static*/ void > omniORB::unregister_activator(Omni_Activator* activator) > { > int found = 0; > > activatorLock.lock(); > Omni_Activator** curr = &activatorHead; > while (*curr != 0) > { > if ((*curr) == activator) > { > *curr = (*curr)->pd_next; > found = 1; > break; > } > curr = &(*curr)->pd_next; > } > activatorLock.unlock(); > > if (!found && omniORB::traceLevel > 0) > { > cerr << "Cannot find activator in activator list." << endl; > } > } > > /*static*/ CORBA::Boolean > omniORB::activate(omniObjectKey &k) > { > activatorLock.lock(); > Omni_Activator* curr = activatorHead; > while (curr != 0) > { > if (curr->activate(k)) > break; > curr = curr->pd_next; > } > activatorLock.unlock(); > return curr != 0; > } > > Omni_Activator::~Omni_Activator() > { > } RCS file: RCS/unshared.cc,v retrieving revision 1.1 diff -r1.1 unshared.cc 61a62,64 > omni_mutex omniORB::activatorLock; > Omni_Activator* omniORB::activatorHead = 0; > Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From matthew_newhook@stratos.ca Thu Jun 26 20:05:56 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA27798; Thu, 26 Jun 1997 19:57:48 +0100 Received: (qmail 26555 invoked by alias); 26 Jun 1997 18:57:46 -0000 From: "Matthew Newhook" Received: (qmail 26546 invoked from network); 26 Jun 1997 18:57:45 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 26 Jun 1997 18:57:45 -0000 Received: (qmail 21373 invoked by uid 213); 26 Jun 1997 18:57:44 -0000 Message-ID: <19970626162744.VX57974@odin.stratos.ca> Date: Thu, 26 Jun 1997 16:27:44 -0230 To: omniorb-list@orl.co.uk Subject: further to my previous mail X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 1320 Status: OR Hi, bug #3 deadlock in object deletion. the patch I sent didn't deal with all cases. In the process of fixing this bug I fixed another problem with BOA::dispose. This method doesn't work as documented. In fact the implementation in 2.2.0 corrupts the object table if called with a reference count of 1. This patch fixes these two problems. Apply this patch over a clean objectRef.cc. RCS file: RCS/objectRef.cc,v retrieving revision 1.1 diff -r1.1 objectRef.cc 223a224 > omniObject* toDelete = 0; 234c235 < delete obj; --- > toDelete = obj; 246c247 < delete obj; // call dtor if BOA->disposed() has been called. --- > toDelete = obj; 249a251,252 > if (toDelete != 0) > delete toDelete; // call dtor if BOA->disposed() has been called. 259,264d261 < if (obj->getRefCount() <= 0) { < omniObject::objectTableLock.unlock(); < throw CORBA::INV_OBJREF(0,CORBA::COMPLETED_NO); < } < else < obj->setRefCount(obj->getRefCount()-1); 265a263 > omniObject* toDelete = 0; 268c266 < delete obj; --- > toDelete = obj; 273a272,273 > if (toDelete != 0) > delete toDelete; Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From matthew_newhook@stratos.ca Thu Jun 26 21:04:53 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id UAA28389; Thu, 26 Jun 1997 20:55:08 +0100 Received: (qmail 27286 invoked by alias); 26 Jun 1997 19:55:06 -0000 From: "Matthew Newhook" Received: (qmail 27267 invoked from network); 26 Jun 1997 19:55:03 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 26 Jun 1997 19:55:03 -0000 Received: (qmail 22737 invoked by uid 213); 26 Jun 1997 19:55:03 -0000 Message-ID: <19970626172503.EG47158@odin.stratos.ca> Date: Thu, 26 Jun 1997 17:25:03 -0230 To: omniorb-list@orl.co.uk Subject: those patches X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 881 Status: OR Hi, The changes I mailed out in the previous set of patches for object activation to corbaBoa.cc won't compile under NT (VC++ 4.1) in CORBA::BOA::make_object change Object_ptr to CORBA::Object_ptr. I also managed to get a change in there that I didn't want. in omniInternal.h the declarations for the constructors for omniObject were changed from protected to public. This change should be reversed. This means unfortunately that CORBA::BOA::make_object cannot delete the omniObj pointer at the bottom of make_object. This should be removed. The definitions for the new methods should also be added the .def file for the dll. I'll get back with those later today or tomorrow. Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From A.Lehmkuehler@imech.com Fri Jun 27 07:54:09 1997 Return-Path: Received: from imech.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id HAA07956; Fri, 27 Jun 1997 07:52:22 +0100 Received: from bohrarm (bohrarm.imech.uni-duisburg.de [134.91.124.62]) by imech.com with SMTP (8.7.5/8.7.3) id IAA22046; Fri, 27 Jun 1997 08:51:20 +0200 (METDST) Message-ID: <33B362EE.4B45@imech.com> Date: Fri, 27 Jun 1997 08:51:26 +0200 From: Andreas Lehmuehler Reply-To: A.Lehmkuehler@imech.com Organization: Imech GmbH X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: Renzo Tomaselli CC: omniORB Mailinglist Subject: Re: Distributed processing with omniorb2 References: <199706261854.UAA196436@venere.inet.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 811 Status: OR Renzo Tomaselli wrote: > > Andreas Lehmkuehler wrote: > > I've tried this and it has failed. Whenever I've started eg3_impl I've > > got a 'abnormal program termination'. The other examples are working fine > > I experienced an 'abnormal program term' in case of truncated pasting of > ior into the registry (Win95); in this case there is an uncaught > marshalling exception which leads to the termination above. However all GOTCHA. While debugging the example I realized that there is something wrong with my IOR and I've checked the registry-entry with catior. It was another user-fault. :-( Andreas -- ================================================ Andreas Lehmkuehler EMail: A.Lehmkuehler@imech.com Institut fuer Mechatronik Tel.: 02841/101-262 ================================================ From A.Lehmkuehler@imech.com Fri Jun 27 14:15:25 1997 Return-Path: Received: from imech.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA13123; Fri, 27 Jun 1997 14:13:37 +0100 Received: from bohrarm (bohrarm.imech.uni-duisburg.de [134.91.124.62]) by imech.com with SMTP (8.7.5/8.7.3) id PAA23273 for ; Fri, 27 Jun 1997 15:13:35 +0200 (METDST) Message-ID: <33B3BC88.2825@imech.com> Date: Fri, 27 Jun 1997 15:13:44 +0200 From: Andreas Lehmuehler Reply-To: A.Lehmkuehler@imech.com Organization: Imech GmbH X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: omniORB Mailinglist Subject: Bug in MSVC4.2 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 854 Status: OR I've a IDL-module with some sequences, structs, atrributes and functions. The IDL-compiler works fine and generates the stub and the header. Because of the typical "Use of undefined type "MSVC++-error described in README.win32 I have to manipulate the automatically produced source. But there still remains an error, which seems to be another internal compiler-error. Whenever I try to implement my class I receive the following error: error C2504: '_sk_Robot' : base class undefined Obviously the compiler can't find the base class, although I've included the header file produced by the IDL-compiler. Any hints or is there maybe a work around -- ================================================ Andreas Lehmkuehler EMail: A.Lehmkuehler@imech.com Institut fuer Mechatronik Tel.: 02841/101-262 ================================================ From matthew_newhook@stratos.ca Fri Jun 27 23:44:12 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id XAA19184; Fri, 27 Jun 1997 23:39:42 +0100 Received: (qmail 8541 invoked by alias); 27 Jun 1997 22:39:35 -0000 From: "Matthew Newhook" Received: (qmail 8532 invoked from network); 27 Jun 1997 22:39:33 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 27 Jun 1997 22:39:33 -0000 Received: (qmail 6715 invoked by uid 213); 27 Jun 1997 22:39:32 -0000 Message-ID: <19970627200932.EL24038@odin.stratos.ca> Date: Fri, 27 Jun 1997 20:09:32 -0230 To: omniorb-list@orl.co.uk Subject: code generated by omniidl2 for msvc. X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 1405 Status: OR Hi, Not being satisfied with either the prospect of hand editing generated code or using a different compiler under NT I modified the code generator to compile code that both SUN C++ 4.2 and MSVC 4.1 can deal with. The changes I made to the generated code were: - in headers don't fully specify types that are currently within scope. ie. for interface a { struct b { long c; }; void xxx(in b c); }; this used to generate code virtual void xxx(const a::b& c) = 0; it now generates: virtual void xxx(const b& c) = 0; - In source, for the naming service, we used to see in the dispatch method of _sk_NamingContext CosNaming::NamingContext::list ... This is changed to: NamingContext::list ... for some reason the former tickled a bug in the microsoft compiler. I have the code written to generate code that compiles under both NT and under Solaris (with SUN C++ 4.2). I'm going to beat on the generator a little more to make sure that I've got all the cases. Currently it will generate correct, working code for all of the .idl files that we have (~ 4k lines of .idl) I'll release the code within the next few days. Any comments would be more than welcome. Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From ramana@ix.netcom.com Sun Jun 29 23:10:53 1997 Return-Path: Received: from dfw-ix1.ix.netcom.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id XAA09946; Sun, 29 Jun 1997 23:06:56 +0100 Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id RAA21893 for ; Sun, 29 Jun 1997 17:06:53 -0500 (CDT) Received: from cha-nc2-09.ix.netcom.com(205.184.158.73) by dfw-ix1.ix.netcom.com via smap (V1.3) id sma021882; Sun Jun 29 17:06:37 1997 Received: (from ramana@localhost) by papillon.ix.netcom.com (8.8.5/8.8.5) id SAA00554 for omniorb-list@orl.co.uk; Sun, 29 Jun 1997 18:11:10 -0400 From: Ramana Ramachandran Message-Id: <199706292211.SAA00554@papillon.ix.netcom.com> Subject: COS Event Service? To: omniorb-list@orl.co.uk Date: Sun, 29 Jun 1997 18:11:10 -0400 (EDT) Content-Type: text Content-Length: 220 Status: OR hi I have successfully installed the omniOrb2 on my linux machine. I looking for COS Event service. I see no mention of it also I couldn't see any work in progress also. Any info from the development team? thanks ramana From ewc Mon Jun 30 12:26:48 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA17437; Mon, 30 Jun 1997 12:24:42 +0100 From: ewc (Eoin Carroll) Message-Id: <199706301124.MAA17437@mailhost.orl.co.uk> Subject: Re: COS Event Service? To: ramana@ix.netcom.com (Ramana Ramachandran) Date: Mon, 30 Jun 1997 12:24:42 +0100 (BST) Cc: omniorb-list In-Reply-To: <199706292211.SAA00554@papillon.ix.netcom.com> from "Ramana Ramachandran" at Jun 29, 97 06:11:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 417 Status: OR Hi, > > I have successfully installed the omniOrb2 on my linux machine. I looking > for COS Event service. I see no mention of it also I couldn't see any > work in progress also. Any info from the development team? We are not currently working on a COS Event service. Eoin Carroll -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Lab Cambridge, UK From ewc Mon Jun 30 12:37:35 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA17665; Mon, 30 Jun 1997 12:36:58 +0100 From: ewc (Eoin Carroll) Message-Id: <199706301136.MAA17665@mailhost.orl.co.uk> Subject: Re: Re: Distributed processing with omniorb2 To: renzo.tomaselli@tecnotp.inet.it (Renzo Tomaselli) Date: Mon, 30 Jun 1997 12:36:58 +0100 (BST) Cc: omniorb-list In-Reply-To: <199706261854.UAA196436@venere.inet.it> from "Renzo Tomaselli" at Jun 26, 97 08:57:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 933 Status: OR Him > About IORs, since OMG doesn't specify the string form of an IOR, why not > using a real Ascii one, such as an URL ? > Yes, it shouldn't be a directly managed string (by humans), however is has > to be moved around; moreover, it keeps a Tcp/IP address which sometimes is > useful to read, at least for checking out installations. > > > Renzo Tomaselli The OMG does specify a string form for IORs, which is used by omniORB in the registry and configuration file. This specification is necessary, as otherwise one couldn't cut and paste stringified IORs between different vendor's ORBs. See section 10.6.5 of the CORBA 2.0 spec. for details. If you want to see the contents of a stringified IOR, use the utility catior, included with the omniORB distribution. Regards, Eoin Carroll -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Lab Cambridge, UK From ulbrich@hexmac.com Mon Jun 30 17:22:57 1997 Return-Path: Received: from hexbase.hexmac.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA22168; Mon, 30 Jun 1997 17:21:42 +0100 Received: from [134.60.219.13] ([134.60.219.13]) by hexbase.hexmac.de (8.6.11/8.6.9) with SMTP id SAA05133 for ; Mon, 30 Jun 1997 18:20:46 +0200 Message-Id: <199706301620.SAA05133@hexbase.hexmac.de> Subject: Re: Java ORB to omniORB? Date: Mon, 30 Jun 97 18:22:35 +0200 x-sender: ulbrich@hexbase.hexmac.de x-mailer: Claris Emailer 1.1 From: Jan Ulbrich To: "OmniORB Mailinglist" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Length: 1138 Status: OR Hi there, >Some ORBs (e.g. HP ORB+, JavaIDL) supply a COS Naming IDL that uses the >#pragma prefix "omg.org" preprocessor directive. The COS Naming IDL used in >omniORB doesn't contain this directive. To get omniNames to interoperate >with >these ORBs, add the following line to the beginning of the file >/src/lib/omniORB2/Naming.idl : > >#pragma prefix "omg.org" > >and re-compile omniORB. This advice comes from the omniORB headquater, so it might not be too bad, but would suggest another way to make the parts interact properly: There is no defacto standard on how to name the COS services and I don't want to change the server side every now and then. I took the original Naming.idl and generated stubs for JavaIDL and used these stubs to connect to omniNames. The ZIP file of the Applet is a little bigger this way, but I prefer it this way... Have a nice day, Jan Ulbrich -- /// Jan Ulbrich - flynn (remember tron?) o-o Margarethe von Wrangellweg 1, 89075 Ulm, Germany L Phone +49731552806, Fax +4973159334, Mobile +491727429683, - WWW http://www.hexmac.de/~ulbrich, eMail ulbrich@hexmac.com From Fausto.Torterolo@imag.fr Mon Jun 30 22:16:57 1997 Return-Path: Received: from imag.imag.fr by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id WAA25209; Mon, 30 Jun 1997 22:15:48 +0100 Received: from orage.imag.fr (orage.imag.fr [152.77.201.1]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id XAA18948 for ; Mon, 30 Jun 1997 23:15:47 +0200 (MET DST) Received: from rafale.imag.fr (rafale.imag.fr [152.77.201.16]) by orage.imag.fr (8.6.11/8.6.9) with ESMTP id XAA06344 for ; Mon, 30 Jun 1997 23:15:29 +0200 Received: from rafale (localhost [127.0.0.1]) by rafale.imag.fr (8.8.3/8.6.9) with SMTP id XAA06771 for ; Mon, 30 Jun 1997 23:15:42 +0200 (MET DST) Sender: Fausto.Torterolo@imag.fr Message-ID: <33B821FE.2429@orage.imag.fr> Date: Mon, 30 Jun 1997 23:15:42 +0200 From: Fausto Torterolo X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: problems with the examples References: <9706130832.AA11656@bambi.unibe.ch> <199706161804.TAA08678@santaka.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 251 Status: OR Hi there, I have some problem to make the example. I work under Solaris with gcc and when I make de examples the link don't finde the reference for many function for examples: __0fNstream_rmutexLrmutex_lockv ../../../lib/libomniORB2.so Fausto From lars@ibp.de Tue Jul 1 11:07:02 1997 Return-Path: Received: from googleplex.ibp.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA02527; Tue, 1 Jul 1997 10:58:01 +0100 Received: (from lars@localhost) by googleplex.ibp.de (8.7.3/8.7.3) id LAA16372 for omniorb-list@orl.co.uk; Tue, 1 Jul 1997 11:57:58 +0200 (GMT+0200) Message-Id: <199707010957.LAA16372@googleplex.ibp.de> MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) Received: by NeXT.Mailer (1.118.2) From: Lars Immisch Date: Tue, 1 Jul 97 11:57:56 +0200 To: omniorb-list@orl.co.uk Subject: Re: Java ORB to omniORB? Content-Length: 494 Status: OR Jan Ulbrich wrote and I quote only one sentence: > There is no defacto standard on how to name the COS services This is not my understanding. I had this problem with JavaIDL and Eoin said = in an email: > The recent ORB Portability (POA) submission has mandated that all OMG IDLs > should now have this prefix. This submission can be found at: = ftp://ftp.omg.org/pub/docs/interop/96-05-01.{pdf|ps} So there is standard way to name the COS services. Cheers, Lars Immisch -- lars@ibp.de From lars@ibp.de Tue Jul 1 12:53:50 1997 Return-Path: Received: from googleplex.ibp.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA04196; Tue, 1 Jul 1997 12:50:19 +0100 Received: (from lars@localhost) by googleplex.ibp.de (8.7.3/8.7.3) id NAA16500 for omniorb-list@orl.co.uk; Tue, 1 Jul 1997 13:49:48 +0200 (GMT+0200) Message-Id: <199707011149.NAA16500@googleplex.ibp.de> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <9707011121.AA06243@kira.unibe.ch> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) Received: by NeXT.Mailer (1.118.2) From: Lars Immisch Date: Tue, 1 Jul 97 13:49:45 +0200 To: omniorb-list@orl.co.uk Subject: Re: Java ORB to omniORB? References: <9707011121.AA06243@kira.unibe.ch> Content-Length: 1638 Status: OR Thomas Wenger wrote to me in private: > Ich versuche seit Tagen JavaIDL zum Arbeiten mit dem omniORB und seinem > Naming zu bewegen. Ich habe auch schon die Aenderung mit "omg.org" > eingetragen. Nur das hat nichts geaendert... For the benefit of all - Thomas cannot get JavaIDL Naming to work with omniORB naming although he has added the omg.org prefix: If you use Windows NT for omniORB, then there is a simple explanation: the Naming stubs have no dependency from Naming.idl in the NT version of the makefiles. So if you add the #prefix "omg.org" to Naming.idl and recompile omniORB, this will do nothing. You can easily check if the prefix is present by having a look [with catior -x] at the IOR omniNames announces. The Type ID must start with "IDL:omg.org". To get around this problem, you can compile the stubs yourself, but then, you must rename and modify them to work around the VC++ nested classes bug. You can also get the edited stubs from me. Send email to remind me. I also sent them to orl, just in case. Two more points: to get omniORB to use the JavaIDL name service, enter the IOR from the java name service into the Registry. Be aware that this IOR changes with every start of the name server (different BOA activation policy, I would guess without thinking). To get the JavaIDL use the omniORB name service, specifying -ORBInitialHost and -ORBInitialPort (or what it was) does not help. I did it by getting a reference to the nameservice by doing a ORB::string_to_object on the IOR from omniNames, followed by the appropiate narrow. Hope this helps, Lars Immisch -- lars@ibp.de From wenger@iam.unibe.ch Wed Jul 2 10:54:25 1997 Return-Path: Received: from arwen.unibe.ch by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA19180; Wed, 2 Jul 1997 10:44:28 +0100 Received: from asterix (actually asterix.unibe.ch) by arwen with SMTP (PP); Wed, 2 Jul 1997 11:42:40 +0200 Received: from kira.unibe.ch by asterix (5.x/SMI-SVR4) id AA11874; Wed, 2 Jul 1997 11:43:24 +0200 Received: by kira.unibe.ch (5.x/SMI-SVR4) id AA07946; Wed, 2 Jul 1997 11:43:17 +0200 Date: Wed, 2 Jul 1997 11:43:17 +0200 From: wenger@iam.unibe.ch (Thomas Wenger) Message-Id: <9707020943.AA07946@kira.unibe.ch> To: omniorb-list@orl.co.uk Subject: Solaris omniORB, GNU g++, JavaIDL Cc: wenger@iam.unibe.ch X-Sun-Charset: US-ASCII Content-Length: 2660 Status: OR Hello "omniORBers" I recently posted several questions concerning: 1. How to build omniORB with GNU g++ under Solaris 2. How to interconnect JavaIDL ORB to omniORB and omniNames Here are my experiences made up to this day: 1. How to build omniORB with GNU g++ under Solaris ================================================== First problem was an old installation of Solaris. To build omniORB under Solaris you need Solaris 2.5 or later. Second problem was adapting makefiles and source to compile with GNU g++. I got the needed hints from ORL directly. Now omniORB compiles with GNU but you have to forget about using shared libraries. But static ones work. One problem that still persists, is that omniNames can not check the logfiles. There seems to be a problem with file handles, beacause I get some dead .nfsxxxx files in the log directory. This does not happen when compiling with Sun CC. The output of GNU compiled omniNames is: Wed Jul 2 11:00:52 1997: Checkpointing Phase 1: Prepare. I/O error writing checkpoint file: Bad file number Abandoning checkpoint 2. How to interconnect JavaIDL ORB to omniORB and omniNames =========================================================== Running JavaIDL (Early Access EA) is no problem. But to connect Java programs to C++ programs using omniORB and omniNames seems to be impossible up to now. I can interconnect the two ORBs when using stringified IOR with copy/paste. I added the missing line [#pragma prefix "org.omg"] to the Naming.idl of omniNames, to be compliant with JavaIDL naming. But I can not use omniNames from Java as initial Name Server. So does anybody know how to get a reference to omniNames in JavaIDL without having to copy/paste a stringified IOR? Conclusion: =========== I do like CORBA and i do like omniORB. Especially the support directly from ORL or by the users works quite fast and always gave me the needed answers. So omniORB is a strong, fast and free CORBA ORB that is more than an alternative to commercial ORBs. I think I will use omniORB with JavaIDL in my diploma work. If anyone has remarks, hints, examples, links or so, I would like to here from you. Thanks to everyone that lent me his time TOM -- ================================================================= Thomas Wenger wenger@iam.unibe.ch University: Institute of Computer Science and Applied Mathematics (IAM), Office 205 Neubrueckstr. 10, CH-3012 Bern +41 31 631 49 90 Private: Wydacherstrasse 4, CH-3113 Rubigen +41 31 721 41 18 ================================================================= From tjr@orl.co.uk Wed Jul 2 11:43:58 1997 Return-Path: Received: from pumpkin.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA20051; Wed, 2 Jul 1997 11:42:40 +0100 Received: from localhost by pumpkin.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id LAA07986; Wed, 2 Jul 1997 11:42:40 +0100 Message-Id: <199707021042.LAA07986@pumpkin.cam-orl.co.uk> To: wenger@iam.unibe.ch (Thomas Wenger) cc: tjr@orl.co.uk, omniorb-list@orl.co.uk Subject: Re: Solaris omniORB, GNU g++, JavaIDL In-reply-to: Your message of "Wed, 02 Jul 1997 11:43:17 +0200." <9707020943.AA07946@kira.unibe.ch> Date: Wed, 02 Jul 1997 11:42:39 +0100 From: Tristan Richardson Content-Length: 1645 Status: OR >>>>>>>>> Thomas Wenger writes: > > One problem that still persists, is that omniNames can not check the > logfiles. There seems to be a problem with file handles, beacause I get > some dead .nfsxxxx files in the log directory. This does not happen when > compiling with Sun CC. > > The output of GNU compiled omniNames is: > > Wed Jul 2 11:00:52 1997: > > Checkpointing Phase 1: Prepare. > I/O error writing checkpoint file: Bad file number > Abandoning checkpoint > You may have missed the fix for this which Sai Lai posted a while ago. There is a bug in the Sunpro C++ compiler to do with not closing file descriptors. The code to work around this gets included wrongly when using g++ on Solaris, causing the message you see. To fix it, find the 4 places in appl/omniNames/log.cc where there is code like this: // a bug on Solaris means that the fd doesn't get closed. #if defined(__sunos__) && (__OSVERSION__ == 5) .... #endif and remove it, or better still, change the #if to: #if defined(__sunos__) && defined(__SUNPRO_CC) Regards, Tristan +--------------------------------------------------------------------+ | Tristan Richardson Email: tjr@orl.co.uk | | ORL Tel: +44 1223 343000 | | 24a Trumpington Street Fax: +44 1223 313542 | | Cambridge, CB2 1QA, UK WWW: http://www.orl.co.uk/ | +--------------------------------------------------------------------+ | ORL - The Olivetti & Oracle Research Laboratory | +--------------------------------------------------------------------+ From Michael.Brug@mch.sni.de Wed Jul 2 13:31:32 1997 Return-Path: Received: from thoth.mch.sni.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA21595; Wed, 2 Jul 1997 13:29:38 +0100 Received: from ares.mch.sni.de (root@localhost) by thoth.mch.sni.de (8.8.6/8.8.6) with SMTP id OAA05721; Wed, 2 Jul 1997 14:29:36 +0200 (MDT) Received: from olymp (olymp.mch.sni.de) by ares.mch.sni.de (4.1/SMI-4.1) id AA16142; Wed, 2 Jul 97 14:28:00 +0200 Sender: brug@mch.sni.de Message-Id: <33BA495F.52EE@mch.sni.de> Date: Wed, 02 Jul 1997 14:28:15 +0200 From: Michael Brug X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Thomas Wenger Cc: omniorb-list@orl.co.uk Subject: Re: Solaris omniORB, GNU g++, JavaIDL References: <9707020943.AA07946@kira.unibe.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1816 Status: OR Thomas Wenger wrote: > > ... > Now omniORB compiles with GNU but you have to forget about using shared libraries. But static ones work. > I am not having problems with shared libraries. I had to change some of the Makefiles for shared libraries. I simply can't debug shared libraries. gdb tells me at startup that it does not find these, although LD_LIBRARY_PATH is set. > One problem that still persists, is that omniNames can not check the logfiles. There seems to be a problem with file handles, beacause I get some dead .nfsxxxx files in the log directory. This does not happen when compiling with Sun CC. > > The output of GNU compiled omniNames is: > > Wed Jul 2 11:00:52 1997: > > Checkpointing Phase 1: Prepare. > I/O error writing checkpoint file: Bad file number > Abandoning checkpoint > > Did you change log.cc. There is #defined _sunos__ ... at several places This needs to be changed to #if defined(__sunos__) && (__SUNPRO_CC) This has been noted earlier in a mail. > > Running JavaIDL (Early Access EA) is no problem. But to connect Java programs to C++ programs using omniORB and omniNames seems to be impossible up to now. > > I can interconnect the two ORBs when using stringified IOR with copy/paste. > > I added the missing line [#pragma prefix "org.omg"] to the Naming.idl of omniNames, to be compliant with JavaIDL naming. But I can not use omniNames from Java as initial Name Server. > > So does anybody know how to get a reference to omniNames in JavaIDL without having to copy/paste a stringified IOR? > Could you connect C++ programs with Java programs using the Java Nameservice? This I could do after recompiling everything. There is still a problem somewhere because I did not manage to use the omniORB nameService with Java programs alone. -- Michael Brug From matthew_newhook@stratos.ca Thu Jul 3 19:07:51 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA11644; Thu, 3 Jul 1997 19:00:06 +0100 Received: (qmail 24678 invoked by alias); 3 Jul 1997 17:59:02 -0000 From: "Matthew Newhook" Received: (qmail 24669 invoked from network); 3 Jul 1997 17:59:00 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 3 Jul 1997 17:59:00 -0000 Received: (qmail 13420 invoked by uid 213); 3 Jul 1997 17:58:59 -0000 Message-ID: <19970703152859.LO24675@odin.stratos.ca> Date: Thu, 3 Jul 1997 15:28:59 -0230 To: omniorb-list@orl.co.uk Subject: mods to omniidl2 for msvc compiles X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 38294 Status: OR Hi, As promised here are the diffs for omniidl2 to enable the generation of code from .idl files that compile under both Solaris and MSVC. I have no reason to believe that the generated code won't compile under other platforms, but I haven't got access so no promises. I think that I have all of the cases, but it's quite possible that I've missed some. Currently about ~4k lines idl files that we use all compile and work under both Solaris and NT. In order to get around MSVC bugs the following changes were made: - instead of always fully qualifying the name the name qualification is based on the scope of the current definition. It emits as little as possible of the scope. ie. module x { struct y { }; interface z { void zz(in y yy); } } used to produce class x { public: struct y { }; class z { public: virtual void zz(const x::y& yy); }; }; Now it produces: class x { public: struct y { }; class z { public: virtual void zz(const y& yy); }; }; It takes into the account the case of: module x { struct y { }; interface z { void zz(in y yy); } } module x2 { interface z2 { void zz(in x::y yy); } }; Changes were necessary in the generated skeleton code also. If you need more details I can provide the necessary info. Diffs follow: ---- diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be.h /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be.h --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be.h Tue May 6 11:17:56 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be.h Mon Jun 30 14:29:41 1997 @@ -75,6 +75,8 @@ static char *narrow_and_produce__scopename(AST_Decl *type); static char *narrow_and_produce_uqname(AST_Decl *type); + void emit_sfqname(fstream& s, const char* fqname); + private: o2be_name(); @@ -461,11 +463,13 @@ void produce_decl_rd(fstream &s, const char *prefix = 0, - idl_bool out_var_default = I_TRUE); + idl_bool out_var_default = I_TRUE, + idl_bool in_header = I_TRUE); void produce_decl_wr(fstream &s, const char *prefix = 0, - idl_bool out_var_default = I_TRUE); + idl_bool out_var_default = I_TRUE, + idl_bool in_header = I_TRUE); void produce_proxy_rd_skel(fstream &s,o2be_interface &defined_in); // produce the definition of the proxy's method to get this attribute @@ -507,6 +511,7 @@ void produce_decl(fstream &s, const char *prefix = 0, const char *alias_prefix = 0, + idl_bool in_header = I_TRUE, idl_bool out_var_default = I_TRUE); // produce the declaration of the mapping of this operation @@ -577,7 +582,7 @@ static void declareVarType(fstream &s, AST_Decl *decl, idl_bool is_var=0, - idl_bool is_arrayslice=0); + idl_bool is_arrayslice=0, idl_bool in_header = 1); static void produceUnMarshalCode(fstream &s, AST_Decl *decl, diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_array.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_array.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_array.cc Tue May 6 11:19:12 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_array.cc Fri Jun 27 13:51:58 1997 @@ -27,6 +27,9 @@ /* $Log: o2be_array.cc,v $ +// Revision 1.1 1997/06/27 16:21:03 matthew +// Initial revision +// // Revision 1.5 1997/05/06 13:49:08 sll // Public release. // @@ -263,7 +266,7 @@ break; #endif default: - elm_fqname = o2be_name::narrow_and_produce_fqname(decl); + elm_fqname = o2be_name::narrow_and_produce_uqname(decl); break; } @@ -568,7 +571,7 @@ break; #endif default: - elm_fqname = o2be_name::narrow_and_produce_fqname(decl); + elm_fqname = o2be_name::narrow_and_produce_uqname(decl); break; } @@ -644,7 +647,7 @@ break; #endif default: - elm_fqname = o2be_name::narrow_and_produce_fqname(decl); + elm_fqname = o2be_name::narrow_and_produce_uqname(decl); break; } diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_attribute.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_attribute.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_attribute.cc Tue May 6 11:20:34 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_attribute.cc Fri Jun 27 17:34:43 1997 @@ -27,6 +27,9 @@ /* $Log: o2be_attribute.cc,v $ +// Revision 1.1 1997/06/27 16:21:07 matthew +// Initial revision +// // Revision 1.8 1997/05/06 13:50:29 sll // Public release. // @@ -49,7 +52,8 @@ void o2be_attribute::produce_decl_rd(fstream &s,const char *prefix, - idl_bool out_var_default) + idl_bool out_var_default, + idl_bool in_header) { o2be_operation::argMapping mapping; o2be_operation::argType ntype = o2be_operation::ast2ArgMapping(field_type(), @@ -59,13 +63,19 @@ while (decl->node_type() == AST_Decl::NT_typedef) { decl = o2be_typedef::narrow_from_decl(decl)->base_type(); } - s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); + if (in_header) + s << o2be_interface::narrow_from_decl(decl)->objref_uqname(); + else + s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); } else if (ntype == o2be_operation::tString) { s << "char *"; } else { - s << o2be_name::narrow_and_produce_fqname(field_type()); + if (in_header) + s << o2be_name::narrow_and_produce_uqname(field_type()); + else + s << o2be_name::narrow_and_produce_fqname(field_type()); } s << ((mapping.is_arrayslice) ? "_slice":"") << " " @@ -80,7 +90,8 @@ void o2be_attribute::produce_decl_wr(fstream &s,const char *prefix, - idl_bool out_var_default) + idl_bool out_var_default, + idl_bool in_header) { o2be_operation::argMapping mapping; o2be_operation::argType ntype = o2be_operation::ast2ArgMapping(field_type(), @@ -95,13 +106,19 @@ while (decl->node_type() == AST_Decl::NT_typedef) { decl = o2be_typedef::narrow_from_decl(decl)->base_type(); } - s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); + if (in_header) + s << o2be_interface::narrow_from_decl(decl)->objref_uqname(); + else + s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); } else if (ntype == o2be_operation::tString) { s << "char *"; } else { - s << o2be_name::narrow_and_produce_fqname(field_type()); + if (in_header) + s << o2be_name::narrow_and_produce_uqname(field_type()); + else + s << o2be_name::narrow_and_produce_fqname(field_type()); } s << ((mapping.is_arrayslice) ? "_slice":"") << " " @@ -116,7 +133,7 @@ { idl_bool hasVariableLenOutArgs = I_FALSE; - IND(s); produce_decl_rd(s,defined_in.proxy_fqname(),I_FALSE); + IND(s); produce_decl_rd(s,defined_in.proxy_fqname(),I_FALSE, I_FALSE); s << " {\n"; INC_INDENT_LEVEL(); IND(s); s << "assertObjectExistent();\n"; @@ -399,7 +416,7 @@ { idl_bool hasVariableLenOutArgs = I_FALSE; - IND(s); produce_decl_wr(s,defined_in.proxy_fqname(),I_FALSE); + IND(s); produce_decl_wr(s,defined_in.proxy_fqname(),I_FALSE,I_FALSE); s << " {\n"; INC_INDENT_LEVEL(); IND(s); s << "assertObjectExistent();\n"; diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc Tue May 6 11:24:52 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc Thu Jul 3 10:00:30 1997 @@ -25,6 +25,9 @@ /* $Log: o2be_exception.cc,v $ +// Revision 1.1 1997/06/25 15:04:25 matthew +// Initial revision +// // Revision 1.4 1997/05/06 13:54:46 sll // Public release. // @@ -76,7 +79,7 @@ { while (decl->node_type() == AST_Decl::NT_typedef) decl = o2be_typedef::narrow_from_decl(decl)->base_type(); - s << o2be_interface::narrow_from_decl(decl)->fieldMemberType_fqname(); + s << o2be_interface::narrow_from_decl(decl)->fieldMemberType_uqname(); } break; default: @@ -108,13 +111,13 @@ s << ((mapping.is_const) ? "const ":""); if (ntype == o2be_operation::tObjref) { - s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); + s << o2be_interface::narrow_from_decl(decl)->objref_uqname(); } else if (ntype == o2be_operation::tString) { s << "char* "; } else { - s << o2be_name::narrow_and_produce_fqname(decl) + s << o2be_name::narrow_and_produce_uqname(decl) << ((mapping.is_arrayslice) ? "_slice":"") << " " << ((mapping.is_pointer) ? "*":"") @@ -240,7 +243,7 @@ s << "char* "; } else { - s << o2be_name::narrow_and_produce_fqname(decl) + s << o2be_name::narrow_and_produce_uqname(decl) << ((mapping.is_arrayslice) ? "_slice":"") << " " << ((mapping.is_pointer) ? "*":"") diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_interface.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_interface.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_interface.cc Tue May 6 11:28:57 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_interface.cc Thu Jul 3 10:00:43 1997 @@ -27,6 +27,9 @@ /* $Log: o2be_interface.cc,v $ +// Revision 1.1 1997/06/27 17:31:12 matthew +// Initial revision +// // Revision 1.9 1997/05/06 13:58:53 sll // Public release. // @@ -142,14 +145,14 @@ strcat(pd_fieldmem_uqname,"_Helper"); strcat(pd_fieldmem_uqname,">"); - pd_fieldmem_fqname = new char[strlen(fqname())+ - strlen(fqname())+strlen("_Helper")+ + pd_fieldmem_fqname = new char[strlen(uqname())+ + strlen(uqname())+strlen("_Helper")+ strlen(FIELD_MEMBER_TEMPLATE)+4]; strcpy(pd_fieldmem_fqname,FIELD_MEMBER_TEMPLATE); strcat(pd_fieldmem_fqname,"<"); - strcat(pd_fieldmem_fqname,fqname()); + strcat(pd_fieldmem_fqname,uqname()); strcat(pd_fieldmem_fqname,","); - strcat(pd_fieldmem_fqname,fqname()); + strcat(pd_fieldmem_fqname,uqname()); strcat(pd_fieldmem_fqname,"_Helper"); strcat(pd_fieldmem_fqname,">"); @@ -160,33 +163,33 @@ pd_inout_adptarg_name = new char[strlen(ADPT_INOUT_CLASS_TEMPLATE)+ strlen("<,, >")+ - strlen(fqname())+ - strlen(fqname())+strlen("_var")+ - strlen(pd_fieldmem_fqname)+1]; + strlen(uqname())+ + strlen(uqname())+strlen("_var")+ + strlen(pd_fieldmem_uqname)+1]; strcpy(pd_inout_adptarg_name,ADPT_INOUT_CLASS_TEMPLATE); strcat(pd_inout_adptarg_name,"<"); - strcat(pd_inout_adptarg_name,fqname()); + strcat(pd_inout_adptarg_name,uqname()); strcat(pd_inout_adptarg_name,","); - strcat(pd_inout_adptarg_name,fqname()); + strcat(pd_inout_adptarg_name,uqname()); strcat(pd_inout_adptarg_name,"_var,"); - strcat(pd_inout_adptarg_name,pd_fieldmem_fqname); + strcat(pd_inout_adptarg_name,pd_fieldmem_uqname); strcat(pd_inout_adptarg_name," >"); pd_out_adptarg_name = new char[strlen(ADPT_OUT_CLASS_TEMPLATE)+ strlen("<,,, >")+ - strlen(fqname())+ - strlen(fqname())+strlen("_var")+ - strlen(pd_fieldmem_fqname)+ - strlen(fqname())+strlen("_Helper")+1]; + strlen(uqname())+ + strlen(uqname())+strlen("_var")+ + strlen(pd_fieldmem_uqname)+ + strlen(uqname())+strlen("_Helper")+1]; strcpy(pd_out_adptarg_name,ADPT_OUT_CLASS_TEMPLATE); strcat(pd_out_adptarg_name,"<"); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,","); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,"_var,"); - strcat(pd_out_adptarg_name,pd_fieldmem_fqname); + strcat(pd_out_adptarg_name,pd_fieldmem_uqname); strcat(pd_out_adptarg_name,","); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,"_Helper"); strcat(pd_out_adptarg_name," >"); } @@ -259,10 +262,10 @@ { s << "#ifndef __" << _fqname() << "__\n"; s << "#define __" << _fqname() << "__\n"; - IND(s); s << "class " << uqname() << ";\n"; + IND(s); s << "class " << uqname() << ";\n"; IND(s); s << "typedef " << uqname() << "* " << objref_uqname() << ";\n"; IND(s); s << "typedef " << objref_uqname() << " " << uqname() << "Ref;\n\n"; - IND(s); s << "class " << uqname() << "_Helper {\n"; + IND(s); s << "class " << uqname() << "_Helper {\n"; INC_INDENT_LEVEL(); IND(s); s << "public:\n"; IND(s); s << "static " << objref_uqname() << " _nil();\n"; @@ -697,7 +700,7 @@ IND(s); s << "virtual CORBA::Object_ptr newProxyObject(Rope *r,CORBA::Octet *key,size_t keysize,IOP::TaggedProfileList *profiles,CORBA::Boolean release);\n"; IND(s); s << "virtual CORBA::Boolean is_a(const char *base_repoId) const;\n"; // _nil() - IND(s); s << "static " << objref_fqname() << " _nil() {\n"; + IND(s); s << "static " << objref_uqname() << " _nil() {\n"; INC_INDENT_LEVEL(); IND(s); s << "if (!_" << nil_uqname() << ") {\n"; INC_INDENT_LEVEL(); @@ -710,7 +713,7 @@ DEC_INDENT_LEVEL(); IND(s); s << "private:\n"; INC_INDENT_LEVEL(); - IND(s); s << "static " << objref_fqname() << " _" << nil_uqname() << ";\n"; + IND(s); s << "static " << objref_uqname() << " _" << nil_uqname() << ";\n"; DEC_INDENT_LEVEL(); IND(s); s << "};\n\n"; @@ -889,7 +892,7 @@ { o2be_interface * intf = o2be_interface::narrow_from_decl(intftable[j]); IND(s); s << ((notfirst)?"else ":"") - << "if (" << intf->server_fqname() + << "if (" << intf->server_uqname() << "::dispatch(_s,_op,_response_expected)) {\n"; INC_INDENT_LEVEL(); IND(s); s << "return 1;\n"; @@ -993,7 +996,7 @@ { o2be_interface * intf = o2be_interface::narrow_from_decl(intftable[j]); IND(s); s << ((j)?"else ":"") - << "if ((_p = " << intf->fqname() + << "if ((_p = " << intf->uqname() << "::_widenFromTheMostDerivedIntf(repoId))) {\n"; INC_INDENT_LEVEL(); IND(s); s << "return _p;\n"; diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_name.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_name.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_name.cc Tue May 6 11:31:22 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_name.cc Mon Jun 30 17:17:19 1997 @@ -27,6 +27,9 @@ /* $Log: o2be_name.cc,v $ +// Revision 1.1 1997/06/30 17:00:03 matthew +// Initial revision +// // Revision 1.5 1997/05/06 14:01:18 sll // Public release. // @@ -496,4 +499,49 @@ throw o2be_internal_error(__FILE__,__LINE__,"Unrecognised argument type"); } return 0; // For MSVC++ 4.2 +} + +// +// emit_sfqname +// display the `scoped fully qualified name' +// that is remove any common parts from the fully qualified name. +// +// IE. +// if scope_name is CORBA::, and fqname is CORBA::String +// then display String. +// +void +o2be_name::emit_sfqname( + fstream& s, + const char* fqname +) +{ + const char* sn_start = scopename(); + const char* sn_end; + const char* fq_start = fqname; + const char* fq_end; + do + { + sn_end = strchr(sn_start, ':'); + fq_end = strchr(fq_start, ':'); + if (fq_end != 0 && sn_end != 0) + { + int fq_len = fq_end - fq_start; + if (fq_len == sn_end - sn_start && + strncmp(fq_start, sn_start, fq_len) == 0) + { + fq_start = fq_end + 2; // skip :: + sn_start = sn_end + 2; + continue; + } + } + break; + } + while (sn_end != 0 && fq_end != 0); + + //cout << "scope_name: " << scopename() << endl; + //cout << "fqname: " << fqname << endl; + //cout << "emitting: " << fq_start << endl; + + s << fq_start; } diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_operation.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_operation.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_operation.cc Tue May 6 11:33:13 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_operation.cc Wed Jul 2 11:21:55 1997 @@ -28,6 +28,9 @@ /* $Log: o2be_operation.cc,v $ +// Revision 1.1 1997/06/25 15:31:03 matthew +// Initial revision +// // Revision 1.11 1997/05/06 14:03:08 sll // Public release. // @@ -59,6 +62,7 @@ o2be_operation::produce_decl(fstream &s, const char *prefix, const char *alias_prefix, + idl_bool in_header, idl_bool out_var_default /* ignored */) { if (context()) @@ -79,13 +83,27 @@ while (decl->node_type() == AST_Decl::NT_typedef) { decl = o2be_typedef::narrow_from_decl(decl)->base_type(); } - s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); + if (in_header) + { + emit_sfqname(s, o2be_interface::narrow_from_decl(decl)->objref_fqname()); + } + else + { + s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); + } } else if (ntype == tString) { s << "char *"; } else { - s << o2be_name::narrow_and_produce_fqname(return_type()); + if (in_header) + { + emit_sfqname(s, o2be_name::narrow_and_produce_fqname(return_type())); + } + else + { + s << o2be_name::narrow_and_produce_fqname(return_type()); + } } s << ((mapping.is_arrayslice) ? "_slice":"") << " " @@ -130,13 +148,13 @@ while (decl->node_type() == AST_Decl::NT_typedef) { decl = o2be_typedef::narrow_from_decl(decl)->base_type(); } - s << o2be_interface::narrow_from_decl(decl)->objref_fqname(); + emit_sfqname(s, o2be_interface::narrow_from_decl(decl)->objref_fqname()); } else if (ntype == tString) { s << "char *"; } else { - s << o2be_name::narrow_and_produce_fqname(a->field_type()); + emit_sfqname(s, o2be_name::narrow_and_produce_fqname(a->field_type())); } s << ((mapping.is_arrayslice) ? "_slice":"") << " " @@ -175,7 +193,7 @@ { idl_bool hasVariableLenOutArgs = I_FALSE; - IND(s); produce_decl(s,defined_in.proxy_fqname(),alias_prefix,I_FALSE); + IND(s); produce_decl(s,defined_in.proxy_fqname(),alias_prefix,I_FALSE, I_FALSE); s << "\n"; IND(s); s << "{\n"; INC_INDENT_LEVEL(); @@ -202,7 +220,7 @@ hasVariableLenOutArgs = I_TRUE; // Declare a local pointer variable IND(s); - declareVarType(s,a->field_type(),0,mapping.is_arrayslice); + declareVarType(s,a->field_type(),0,mapping.is_arrayslice, 0); s << ((ntype != tObjref && ntype != tString)?" *":"") << " _" << a->uqname() << "= 0;\n"; } @@ -220,14 +238,14 @@ { hasVariableLenOutArgs = I_TRUE; IND(s); - declareVarType(s,return_type(),0,mapping.is_arrayslice); + declareVarType(s,return_type(),0,mapping.is_arrayslice, 0); s << ((ntype != tObjref && ntype != tString)?" *":"") << " _result" << "= 0;\n"; } else { IND(s); - declareVarType(s,return_type()); + declareVarType(s,return_type(), 0, 0, 0); s << " _result;\n"; } } @@ -343,7 +361,7 @@ } else if (mapping.is_reference && mapping.is_pointer) { IND(s); s << "_" << a->uqname() << " = new "; - declareVarType(s,a->field_type()); + declareVarType(s,a->field_type(), 0, 0, 0); s << ";\n"; } } @@ -366,7 +384,7 @@ } else if (mapping.is_pointer) { IND(s); s << "_result = new "; - declareVarType(s,return_type()); + declareVarType(s,return_type(), 0, 0, 0); s << ";\n"; } } @@ -401,7 +419,7 @@ strcpy(_argname,"_"); strcat(_argname,a->uqname()); IND(s); - declareVarType(s,a->field_type(),0,0); + declareVarType(s,a->field_type(),0,0,0); s << " " << _argname << ";\n"; produceUnMarshalCode(s,a->field_type(),"_c",_argname, ntype,mapping); @@ -416,7 +434,7 @@ strcpy(_argname,"_"); strcat(_argname,a->uqname()); IND(s); - declareVarType(s,a->field_type(),0,0); + declareVarType(s,a->field_type(),0,0,0); s << " " << _argname << ";\n"; produceUnMarshalCode(s,a->field_type(),"_c",_argname, ntype,mapping); @@ -514,8 +532,9 @@ while (!i.is_done()) { o2be_exception *excpt = o2be_exception::narrow_from_decl(i.item()); - if (excpt->repoIdConstLen() > maxIdsize) - maxIdsize = excpt->repoIdConstLen(); + int len = strlen(excpt->repositoryID())+1; + if (len > maxIdsize) + maxIdsize = len; i.next(); } } @@ -764,14 +783,14 @@ (mapping.is_pointer)) { IND(s); - declareVarType(s,return_type(),0,mapping.is_arrayslice); + declareVarType(s,return_type(),0,mapping.is_arrayslice, 0); s << ((ntype != tObjref && ntype != tString)?" *":"") << " _result" << "= 0;\n"; } else { IND(s); - declareVarType(s,return_type()); + declareVarType(s,return_type(), 0, 0, 0); s << " _result"; switch (ntype) { @@ -858,9 +877,9 @@ ntype = ast2ArgMapping(a->field_type(),wIN,mapping); if (ntype == tObjref || ntype == tString) // declare a _var variable to manage the pointer type - declareVarType(s,a->field_type(),1); + declareVarType(s,a->field_type(),1, 0, 0); else - declareVarType(s,a->field_type()); + declareVarType(s,a->field_type(), 0, 0,0); s << " " << a->uqname() << ";\n"; produceUnMarshalCode(s,a->field_type(),"_s",a->uqname(), ntype,mapping); @@ -874,10 +893,10 @@ (mapping.is_reference && mapping.is_pointer)) { // declare a _var variable to manage the pointer type - declareVarType(s,a->field_type(),1,mapping.is_arrayslice); + declareVarType(s,a->field_type(),1,mapping.is_arrayslice, 0); } else - declareVarType(s,a->field_type()); + declareVarType(s,a->field_type(), 0,0,0); s << " " << a->uqname() << ";\n"; break; } @@ -887,10 +906,10 @@ if (ntype == tObjref || ntype == tString) { // declare a _var variable to manage the pointer type - declareVarType(s,a->field_type(),1); + declareVarType(s,a->field_type(),1, 0,0); } else - declareVarType(s,a->field_type()); + declareVarType(s,a->field_type(), 0,0); s << " " << a->uqname() << ";\n"; produceUnMarshalCode(s,a->field_type(),"_s",a->uqname(), ntype,mapping); @@ -912,11 +931,11 @@ (mapping.is_pointer)) { // declare a _var variable to manage the pointer type - declareVarType(s,return_type(),1,mapping.is_arrayslice); + declareVarType(s,return_type(),1,mapping.is_arrayslice, 0); } else { - declareVarType(s,return_type()); + declareVarType(s,return_type(), 0, 0,0); } s << " _result;\n"; } @@ -930,7 +949,8 @@ s << "_result = "; if (has_variable_out_arg() || has_pointer_inout_arg()) { // Use the indirection function in the base class - s << defined_in.fqname() << "::"; + //s << defined_in.fqname() << "::"; + s << defined_in.uqname() << "::"; } produce_invoke(s); s << ";\n"; @@ -938,7 +958,8 @@ else { if (has_variable_out_arg() || has_pointer_inout_arg()) { // Use the indirection function in the base class - s << defined_in.fqname() << "::"; + //s << defined_in.fqname() << "::"; + s << defined_in.uqname() << "::"; } produce_invoke(s); s << ";\n"; @@ -966,12 +987,12 @@ IND(s); s << "size_t _msgsize = (size_t) GIOP_S::ReplyHeaderSize();\n"; - produceConstStringSizeCalculation(s,"_msgsize",excpt->repoIdConstLen()); + int len = strlen(excpt->repositoryID())+1; + produceConstStringSizeCalculation(s,"_msgsize", len); produceSizeCalculation(s,i.item(),"_s","_msgsize","ex",ntype,mapping); IND(s); s << "_s.InitialiseReply(GIOP::USER_EXCEPTION,(CORBA::ULong)_msgsize);\n"; - produceConstStringMarshalCode(s,"_s",excpt->repoIdConstName(), - excpt->repoIdConstLen()); + produceConstStringMarshalCode(s,"_s",excpt->repoIdConstName(), len); produceMarshalCode(s,i.item(),"_s","ex",ntype,mapping); IND(s); s << "_s.ReplyCompleted();\n"; IND(s); s << "return 1;\n"; @@ -1154,7 +1175,7 @@ void o2be_operation::produce_nil_skel(fstream &s,const char* alias_prefix) { - IND(s); produce_decl(s,0,alias_prefix); + IND(s); produce_decl(s,0,alias_prefix, I_TRUE); s << "{\n"; INC_INDENT_LEVEL(); IND(s); s << "throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO);\n"; @@ -1168,14 +1189,14 @@ (mapping.is_pointer)) { IND(s); - declareVarType(s,return_type(),0,mapping.is_arrayslice); + declareVarType(s,return_type(),0,mapping.is_arrayslice, 0); s << ((ntype != tObjref && ntype != tString)?" *":"") << " _result" << "= 0;\n"; } else { IND(s); - declareVarType(s,return_type()); + declareVarType(s,return_type(), 0,0,0); s << " _result"; switch (ntype) { @@ -1261,7 +1282,7 @@ indent_pos += 6; } else { - str = o2be_name::narrow_and_produce_fqname(return_type()); + str = o2be_name::narrow_and_produce_uqname(return_type()); s << str; indent_pos += strlen(str); } @@ -1351,7 +1372,7 @@ s << "char *"; } else { - s << o2be_name::narrow_and_produce_fqname(a->field_type()); + s << o2be_name::narrow_and_produce_uqname(a->field_type()); } s << ((mapping.is_arrayslice) ? "_slice":"") << " " @@ -1842,7 +1863,7 @@ void o2be_operation::declareVarType(fstream &s,AST_Decl *decl,idl_bool is_var, - idl_bool is_arrayslice) + idl_bool is_arrayslice, idl_bool in_header) { AST_Decl *truetype = decl; while (truetype->node_type() == AST_Decl::NT_typedef) { @@ -1852,9 +1873,27 @@ if (truetype->node_type() == AST_Decl::NT_interface) { if (!is_var) - s << o2be_interface::narrow_from_decl(truetype)->objref_fqname(); + { + if (in_header) + { + s << o2be_interface::narrow_from_decl(truetype)->objref_uqname(); + } + else + { + s << o2be_interface::narrow_from_decl(truetype)->objref_fqname(); + } + } else - s << o2be_name::narrow_and_produce_fqname(truetype) << "_var"; + { + if (in_header) + { + s << o2be_name::narrow_and_produce_uqname(truetype) << "_var"; + } + else + { + s << o2be_name::narrow_and_produce_fqname(truetype) << "_var"; + } + } } else if (truetype->node_type() == AST_Decl::NT_string) @@ -1866,7 +1905,10 @@ } else { - s << o2be_name::narrow_and_produce_fqname(decl); + if (in_header) + s << o2be_name::narrow_and_produce_uqname(decl); + else + s << o2be_name::narrow_and_produce_fqname(decl); if (is_var) s << "_var"; else diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_sequence.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_sequence.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_sequence.cc Tue May 6 11:35:32 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_sequence.cc Fri Jun 27 15:14:06 1997 @@ -27,6 +27,9 @@ /* $Log: o2be_sequence.cc,v $ +// Revision 1.1 1997/06/27 17:14:36 matthew +// Initial revision +// // Revision 1.5 1997/05/06 14:05:26 sll // Public release. // @@ -194,7 +197,7 @@ size_t s_max = astExpr2val(max_size()); size_t elmsize = 0; size_t alignment = 0; - const char* baseclassname = o2be_name::narrow_and_produce_fqname(base_type()); + const char* baseclassname = o2be_name::narrow_and_produce_uqname(base_type()); switch (ntype) { case o2be_operation::tBoolean: @@ -227,7 +230,7 @@ AST_Decl *decl = base_type(); while (decl->node_type() == AST_Decl::NT_typedef) decl = o2be_typedef::narrow_from_decl(decl)->base_type(); - baseclassname = o2be_interface::narrow_from_decl(decl)->fieldMemberType_fqname(); + baseclassname = o2be_interface::narrow_from_decl(decl)->fieldMemberType_uqname(); break; } case o2be_operation::tString: @@ -576,9 +579,9 @@ strlen(tdef->fqname())*2+strlen("_var")+1]; strcpy(p,SEQUENCE_TEMPLATE_ADPT_CLASS); strcat(p,"<"); - strcat(p,tdef->fqname()); + strcat(p,tdef->uqname()); strcat(p,","); - strcat(p,tdef->fqname()); + strcat(p,tdef->uqname()); strcat(p,"_var >"); return p; } diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_struct.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_struct.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_struct.cc Tue May 6 11:38:31 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_struct.cc Mon Jun 30 14:37:15 1997 @@ -120,13 +120,13 @@ pd_skel_produced_in_field = I_FALSE; pd_out_adptarg_name = new char[strlen(ADPT_CLASS_TEMPLATE)+strlen("<,>")+ - strlen(fqname())+ - strlen(fqname())+strlen("_var")+1]; + strlen(uqname())+ + strlen(uqname())+strlen("_var")+1]; strcpy(pd_out_adptarg_name,ADPT_CLASS_TEMPLATE); strcat(pd_out_adptarg_name,"<"); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,","); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,"_var>"); } @@ -258,10 +258,15 @@ case AST_Decl::NT_interface: { if (decl->node_type() == AST_Decl::NT_interface) - s << o2be_interface::narrow_from_decl(decl)->fieldMemberType_fqname(); + { + emit_sfqname(s, o2be_interface::narrow_from_decl(decl)->fieldMemberType_fqname()); + } else - s << o2be_typedef::narrow_from_decl(decl)->fieldMemberType_fqname(); + { + s << o2be_interface::narrow_from_decl(decl)->fieldMemberType_uqname(); + } s <<" "<< o2be_field::narrow_from_decl(d)->uqname() << ";\n"; + break; } case AST_Decl::NT_array: @@ -269,7 +274,7 @@ if (decl->node_type() == AST_Decl::NT_array) o2be_array::narrow_from_decl(decl)->produce_struct_member_decl(s,d); else { - s << o2be_typedef::narrow_from_decl(decl)->fqname(); + s << o2be_typedef::narrow_from_decl(decl)->uqname(); s <<" "<< o2be_field::narrow_from_decl(d)->uqname() << ";\n"; } break; @@ -284,14 +289,14 @@ << ";\n"; } else { - s << o2be_typedef::narrow_from_decl(decl)->fqname(); + s << o2be_typedef::narrow_from_decl(decl)->uqname(); s <<" "<< o2be_field::narrow_from_decl(d)->uqname() << ";\n"; } break; } #endif default: - s << o2be_name::narrow_and_produce_fqname(decl) + s << o2be_name::narrow_and_produce_uqname(decl) << " " << o2be_field::narrow_from_decl(d)->uqname() << ";\n"; } } diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_typedef.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_typedef.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_typedef.cc Tue May 6 11:39:08 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_typedef.cc Fri Jun 27 14:45:00 1997 @@ -27,6 +27,9 @@ /* $Log: o2be_typedef.cc,v $ +// Revision 1.1 1997/06/27 17:14:36 matthew +// Initial revision +// // Revision 1.3 1997/05/06 14:09:04 sll // Public release. // @@ -48,7 +51,7 @@ o2be_sequence_chain(this) { AST_Decl *decl = base_type(); - const char *tname = o2be_name::narrow_and_produce_fqname(decl); + const char *tname = o2be_name::narrow_and_produce_uqname(decl); while (decl->node_type() == AST_Decl::NT_typedef) { decl = o2be_typedef::narrow_from_decl(decl)->base_type(); @@ -95,7 +98,7 @@ o2be_typedef::produce_hdr(fstream &s) { AST_Decl *decl = base_type(); - const char *tname = o2be_name::narrow_and_produce_fqname(decl); + const char *tname = o2be_name::narrow_and_produce_uqname(decl); while (decl->node_type() == AST_Decl::NT_typedef) { decl = o2be_typedef::narrow_from_decl(decl)->base_type(); diff -u /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_union.cc /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_union.cc --- /pub/corba/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_union.cc Tue May 6 11:40:07 1997 +++ /shad/src/matthew/omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_union.cc Thu Jul 3 10:00:46 1997 @@ -144,13 +144,13 @@ pd_skel_produced_in_field = I_FALSE; pd_out_adptarg_name = new char[strlen(ADPT_CLASS_TEMPLATE)+strlen("<,>")+ - strlen(fqname())+ - strlen(fqname())+strlen("_var")+1]; + strlen(uqname())+ + strlen(uqname())+strlen("_var")+1]; strcpy(pd_out_adptarg_name,ADPT_CLASS_TEMPLATE); strcat(pd_out_adptarg_name,"<"); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,","); - strcat(pd_out_adptarg_name,fqname()); + strcat(pd_out_adptarg_name,uqname()); strcat(pd_out_adptarg_name,"_var>"); } @@ -421,10 +421,10 @@ DEC_INDENT_LEVEL(); IND(s); s << "}\n\n"; - IND(s); s << o2be_name::narrow_and_produce_fqname(disc_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(disc_type()) << " _d () const { return pd_d;}\n"; IND(s); s << "void _d(" - << o2be_name::narrow_and_produce_fqname(disc_type()) + << o2be_name::narrow_and_produce_uqname(disc_type()) << " _value) {}\n\n"; if (nodefault() && !no_missing_disc_value()) @@ -501,11 +501,11 @@ else { IND(s); s << "const " - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << " &" << f->uqname() << " () const { return pd_" << f->uqname() << "; }\n"; - IND(s); s << o2be_name::narrow_and_produce_fqname(f->field_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(f->field_type()) << " &" << f->uqname() << " () { return pd_" << f->uqname() << "; }\n"; @@ -519,11 +519,11 @@ case o2be_operation::tUnionVariable: case o2be_operation::tAny: IND(s); s << "const " - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << " &" << f->uqname() << " () const { return pd_" << f->uqname() << "; }\n"; - IND(s); s << o2be_name::narrow_and_produce_fqname(f->field_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(f->field_type()) << " &" << f->uqname() << " () { return pd_" << f->uqname() << "; }\n"; @@ -549,7 +549,7 @@ else { IND(s); s << "const " - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << ((mapping.is_arrayslice) ? "_slice":"") << " " << ((mapping.is_pointer) ? "*":"") @@ -560,7 +560,7 @@ break; } default: - IND(s); s << o2be_name::narrow_and_produce_fqname(f->field_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(f->field_type()) << " " << ((mapping.is_pointer) ? "*":"") << ((mapping.is_reference) ? "&":"") @@ -765,7 +765,7 @@ { IND(s); s << "void " << f->uqname() << " (const " - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << "& _value) {\n"; INC_INDENT_LEVEL(); if (l->label_kind() == AST_UnionLabel::UL_label) @@ -795,7 +795,7 @@ case o2be_operation::tAny: IND(s); s << "void " << f->uqname() << " (const " - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << "& _value) {\n"; INC_INDENT_LEVEL(); if (l->label_kind() == AST_UnionLabel::UL_label) @@ -833,7 +833,7 @@ { IND(s); s << "void " << f->uqname() << " (const " - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << " _value) {\n"; } INC_INDENT_LEVEL(); @@ -899,7 +899,7 @@ IND(s); s << "void " << f->uqname() << " (" << ((mapping.is_const) ? "const ":"") - << o2be_name::narrow_and_produce_fqname(f->field_type()) + << o2be_name::narrow_and_produce_uqname(f->field_type()) << " " << ((mapping.is_pointer) ? "*":"") << ((mapping.is_reference) ? "&":"") @@ -941,7 +941,7 @@ IND(s); s << "private:\n\n"; INC_INDENT_LEVEL(); - IND(s); s << o2be_name::narrow_and_produce_fqname(disc_type()) << " pd_d;\n"; + IND(s); s << o2be_name::narrow_and_produce_uqname(disc_type()) << " pd_d;\n"; IND(s); s << "CORBA::Boolean pd_default;\n"; if (has_fix_member) { @@ -972,7 +972,7 @@ case o2be_operation::tOctet: case o2be_operation::tEnum: case o2be_operation::tStructFixed: - IND(s); s << o2be_name::narrow_and_produce_fqname(f->field_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(f->field_type()) << " pd_" << f->uqname() << ";\n"; break; case o2be_operation::tArrayFixed: @@ -1031,7 +1031,7 @@ case o2be_operation::tUnionFixed: case o2be_operation::tUnionVariable: case o2be_operation::tAny: - IND(s); s << o2be_name::narrow_and_produce_fqname(f->field_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(f->field_type()) << " pd_" << f->uqname() << ";\n"; break; case o2be_operation::tSequence: @@ -1047,7 +1047,7 @@ << " pd_" << f->uqname() << ";\n"; } #else - IND(s); s << o2be_name::narrow_and_produce_fqname(f->field_type()) + IND(s); s << o2be_name::narrow_and_produce_uqname(f->field_type()) << " pd_" << f->uqname() << ";\n"; #endif break; -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From matthew_newhook@stratos.ca Thu Jul 3 19:41:45 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA12238; Thu, 3 Jul 1997 19:41:06 +0100 Received: (qmail 25197 invoked by alias); 3 Jul 1997 18:41:04 -0000 From: "Matthew Newhook" Received: (qmail 25188 invoked from network); 3 Jul 1997 18:41:02 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 3 Jul 1997 18:41:02 -0000 Received: (qmail 16730 invoked by uid 213); 3 Jul 1997 18:41:01 -0000 Message-ID: <19970703161101.LQ50246@odin.stratos.ca> Date: Thu, 3 Jul 1997 16:11:01 -0230 To: omniorb-list@orl.co.uk Subject: patches for use under NT X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 72491 Status: OR Hi, What follows are diffs to allow compilation of omniORB under NT without the .def file. If you apply these patches the naming service won't be included in CORBA.h. It is also intended to be used with my previous set of patches for omniidl2. Another major change is that the naming service is no longer directly compiled into the ORB. Under solaris a single library libnaming.a is produced. This is due to the fact that the stubs that are produced are not intended to be compiled as a .dll (no dllexport, or dllimport) and therefore cannot be linked into a .dll without a .def file. Under NT two libraries are produced. naming_rt.lib and naming.lib. naming_rt.lib is supposed to be used with the .dll version (omniORB_rt.lib), and naming.lib should be used with omniORB.lib. The changes that I've made to the MAKEFILE under NT produce a version of omniORB with debugging information. To compile a version without debugging change /Zi to /O2 and /DEBUG:full to /pdb:none These patches contain: - fixes for .dll compilation under NT. - implementation of activators under NT. - fix to CORBA::String_member copy constructor. - fix for deadlock when calling ORB methods in destructor of an implementation object. - fix to BOA::dispose method - modifications to makefiles to produce naming.lib and naming_rt.lib and to produce libnaming.a under NT. --- diffs follow --- diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/CORBA.h include/omniORB2/CORBA.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/CORBA.h Tue May 6 13:34:49 1997 +++ include/omniORB2/CORBA.h Thu Jul 3 10:05:51 1997 @@ -166,7 +166,7 @@ }; // omniORB2 private class - class String_member + class _OMNIORB2_NTDLL_ String_member { public: typedef char* ptr_t; @@ -179,10 +179,7 @@ } inline String_member(const String_member &s) { - if (_ptr) { - string_free(_ptr); - _ptr = 0; - } + _ptr = 0; if (s._ptr) { _ptr = string_alloc((ULong)(strlen(s._ptr)+1)); strcpy(_ptr,s._ptr); @@ -398,7 +395,7 @@ // PIDL Exception // //////////////////////////////////////////////////////////////////////// - class Exception { + class _OMNIORB2_NTDLL_ Exception { public: virtual ~Exception() {} protected: @@ -406,7 +403,7 @@ }; enum CompletionStatus { COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE }; - class SystemException : public Exception { + class _OMNIORB2_NTDLL_ SystemException : public Exception { public: SystemException() { pd_minor = 0; @@ -454,7 +451,7 @@ }; #define STD_EXCEPTION(name) \ - class name : public SystemException { \ + class _OMNIORB2_NTDLL_ name : public SystemException { \ public: \ name (ULong minor = 0, CompletionStatus completed = COMPLETED_NO \ ) : SystemException (minor,completed) {} \ @@ -490,7 +487,7 @@ #undef STD_EXCEPTION - class UserException : public Exception { + class _OMNIORB2_NTDLL_ UserException : public Exception { public: UserException() {} virtual ~UserException() {} @@ -600,8 +597,8 @@ static Environment_ptr _duplicate(); static Environment_ptr _nil(); + Environment() {} // Not implemented yet private: - Environment(); // Not implemented yet }; //////////////////////////////////////////////////////////////////////// @@ -728,6 +725,7 @@ class Object; typedef Object *Object_ptr; + typedef Object_ptr ObjectRef; typedef _CORBA_Unbounded_Sequence_Octet ReferenceData; @@ -741,7 +739,7 @@ ImplementationDef(); // Not implemented yet; }; - class Object_Helper { + class _OMNIORB2_NTDLL_ Object_Helper { public: // omniORB2 specifics static Object_ptr _nil(); @@ -755,7 +753,7 @@ static Object_ptr unmarshalObjRef(MemBufferedStream &s); }; - class Object { + class _OMNIORB2_NTDLL_ Object { public: #if defined(SUPPORT_DII) @@ -844,7 +842,7 @@ class BOA; typedef class BOA *BOA_ptr; - class BOA { + class _OMNIORB2_NTDLL_ BOA { public: Object_ptr create( const ReferenceData&, InterfaceDef_ptr, @@ -863,6 +861,10 @@ void obj_is_ready(Object_ptr, ImplementationDef_ptr p=0); + Object_ptr make_object(const omniObjectKey& k, const char* type_id); + // omniORB2 specific. Create an proxy that refers to a local object + // with the specified key, and the specified type_id. + static BOA_ptr _duplicate(BOA_ptr); static BOA_ptr _nil(); @@ -883,7 +885,7 @@ class ORB; typedef class ORB *ORB_ptr; - class ORB { + class _OMNIORB2_NTDLL_ ORB { public: char *object_to_string(Object_ptr) ; @@ -1281,7 +1283,6 @@ private: ORB_ptr pd_orbref; }; - }; @@ -1289,10 +1290,6 @@ #include // Include the COSS Naming Service header: -#ifdef __NT__ -#include -#else -#include -#endif +//#include #endif // __CORBA_H__ diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/CORBA_basetypes.h include/omniORB2/CORBA_basetypes.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/CORBA_basetypes.h Tue May 6 13:35:25 1997 +++ include/omniORB2/CORBA_basetypes.h Wed Jul 2 15:45:10 1997 @@ -68,8 +68,8 @@ typedef double _CORBA_Double; #endif -extern void _CORBA_new_operator_return_null(); -extern void _CORBA_bound_check_error(); -extern void _CORBA_marshal_error(); +extern void _OMNIORB2_NTDLL_ _CORBA_new_operator_return_null(); +extern void _OMNIORB2_NTDLL_ _CORBA_bound_check_error(); +extern void _OMNIORB2_NTDLL_ _CORBA_marshal_error(); #endif // __CORBA_BASETYPES_H__ diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/CORBA_sysdep.h include/omniORB2/CORBA_sysdep.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/CORBA_sysdep.h Tue May 6 13:36:06 1997 +++ include/omniORB2/CORBA_sysdep.h Wed Jul 2 15:27:00 1997 @@ -32,6 +32,9 @@ /* $Log: CORBA_sysdep.h,v $ + * Revision 1.1 1997/07/02 17:52:14 matthew + * Initial revision + * * Revision 1.10 1997/05/06 16:06:03 sll * Public release. * @@ -136,10 +139,13 @@ #elif defined(_OMNIORB2_DLL) #define _OMNIORB2_NTDLL_ __declspec(dllexport) #pragma warning(disable: 4251) +#pragma warning(disable: 4275) // Disable this warning, as myPrincipalID is defined by a template, which // can't be exported using __declspec #elif !defined(_WINSTATIC) #define _OMNIORB2_NTDLL_ __declspec(dllimport) +#pragma warning(disable: 4275) +// disable non dll-interface class '*' used as base for dll-interface class #pragma warning(disable: 4251) // Disable this warning, as myPrincipalID is defined by a template, which // can't be imported using __declspec diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/Naming.hh include/omniORB2/Naming.hh --- /pub/corba/omniORB_2.2.0/include/omniORB2/Naming.hh Wed Apr 23 12:45:08 1997 +++ include/omniORB2/Naming.hh Thu Jul 3 11:15:52 1997 @@ -21,8 +21,8 @@ typedef _CORBA_ConstrType_Variable_Var NameComponent_var; - typedef _CORBA_Unbounded_Sequence Name; - typedef _CORBA_Sequence_Var Name_var; + typedef _CORBA_Unbounded_Sequence Name; + typedef _CORBA_Sequence_Var Name_var; enum BindingType { nobject, ncontext }; @@ -61,8 +61,8 @@ } struct Binding { - CosNaming::Name binding_name; - CosNaming::BindingType binding_type; + Name binding_name; + BindingType binding_type; size_t NP_alignedSize(size_t initialoffset) const; void operator>>= (NetBufferedStream &) const; @@ -73,8 +73,8 @@ typedef _CORBA_ConstrType_Variable_Var Binding_var; - typedef _CORBA_Unbounded_Sequence BindingList; - typedef _CORBA_Sequence_Var BindingList_var; + typedef _CORBA_Unbounded_Sequence BindingList; + typedef _CORBA_Sequence_Var BindingList_var; #ifndef __CosNaming_BindingIterator__ #define __CosNaming_BindingIterator__ @@ -120,11 +120,11 @@ #endif #ifndef __CosNaming_NamingContext__ #define __CosNaming_NamingContext__ - class NamingContext; + class NamingContext; typedef NamingContext* NamingContext_ptr; typedef NamingContext_ptr NamingContextRef; - class NamingContext_Helper { + class NamingContext_Helper { public: static NamingContext_ptr _nil(); static CORBA::Boolean is_nil(NamingContext_ptr p); @@ -139,7 +139,7 @@ typedef _CORBA_ObjRef_Var NamingContext_var; #endif -#define CosNaming_NamingContext_IntfRepoID "IDL:CosNaming/NamingContext:1.0" +#define CosNaming_NamingContext_IntfRepoID "IDL:omg.org/CosNaming/NamingContext:1.0" class NamingContext : public virtual omniObject, public virtual CORBA::Object { public: @@ -182,17 +182,17 @@ } } -#define CosNaming_NamingContext_NotFound_IntfRepoID "IDL:CosNaming/NamingContext/NotFound:1.0" +#define CosNaming_NamingContext_NotFound_IntfRepoID "IDL:omg.org/CosNaming/NamingContext/NotFound:1.0" class NotFound : public CORBA::UserException { public: - CosNaming::NamingContext::NotFoundReason why; - CosNaming::Name rest_of_name; + NotFoundReason why; + Name rest_of_name; NotFound() {}; NotFound(const NotFound &); - NotFound(CosNaming::NamingContext::NotFoundReason _why, const CosNaming::Name & _rest_of_name); + NotFound(NotFoundReason _why, const Name & _rest_of_name); NotFound & operator=(const NotFound &); virtual ~NotFound() {}; size_t NP_alignedSize(size_t initialoffset); @@ -202,17 +202,17 @@ void operator<<= (MemBufferedStream &); }; -#define CosNaming_NamingContext_CannotProceed_IntfRepoID "IDL:CosNaming/NamingContext/CannotProceed:1.0" +#define CosNaming_NamingContext_CannotProceed_IntfRepoID "IDL:omg.org/CosNaming/NamingContext/CannotProceed:1.0" class CannotProceed : public CORBA::UserException { public: - _CORBA_ObjRef_Member cxt; - CosNaming::Name rest_of_name; + _CORBA_ObjRef_Member cxt; + Name rest_of_name; CannotProceed() {}; CannotProceed(const CannotProceed &); - CannotProceed(CosNaming::NamingContext_ptr _cxt, const CosNaming::Name & _rest_of_name); + CannotProceed(NamingContext_ptr _cxt, const Name & _rest_of_name); CannotProceed & operator=(const CannotProceed &); virtual ~CannotProceed() {}; size_t NP_alignedSize(size_t initialoffset); @@ -222,7 +222,7 @@ void operator<<= (MemBufferedStream &); }; -#define CosNaming_NamingContext_InvalidName_IntfRepoID "IDL:CosNaming/NamingContext/InvalidName:1.0" +#define CosNaming_NamingContext_InvalidName_IntfRepoID "IDL:omg.org/CosNaming/NamingContext/InvalidName:1.0" class InvalidName : public CORBA::UserException { public: @@ -239,7 +239,7 @@ void operator<<= (MemBufferedStream &); }; -#define CosNaming_NamingContext_AlreadyBound_IntfRepoID "IDL:CosNaming/NamingContext/AlreadyBound:1.0" +#define CosNaming_NamingContext_AlreadyBound_IntfRepoID "IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0" class AlreadyBound : public CORBA::UserException { public: @@ -256,7 +256,7 @@ void operator<<= (MemBufferedStream &); }; -#define CosNaming_NamingContext_NotEmpty_IntfRepoID "IDL:CosNaming/NamingContext/NotEmpty:1.0" +#define CosNaming_NamingContext_NotEmpty_IntfRepoID "IDL:omg.org/CosNaming/NamingContext/NotEmpty:1.0" class NotEmpty : public CORBA::UserException { public: @@ -273,19 +273,19 @@ void operator<<= (MemBufferedStream &); }; - virtual void bind ( const CosNaming::Name & n, CORBA::Object_ptr obj ) = 0; - virtual void rebind ( const CosNaming::Name & n, CORBA::Object_ptr obj ) = 0; - virtual void bind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ) = 0; - virtual void rebind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ) = 0; - virtual CORBA::Object_ptr resolve ( const CosNaming::Name & n ) = 0; - virtual void unbind ( const CosNaming::Name & n ) = 0; - virtual CosNaming::NamingContext_ptr new_context ( ) = 0; - virtual CosNaming::NamingContext_ptr bind_new_context ( const CosNaming::Name & n ) = 0; + virtual void bind ( const Name & n, CORBA::Object_ptr obj ) = 0; + virtual void rebind ( const Name & n, CORBA::Object_ptr obj ) = 0; + virtual void bind_context ( const Name & n, NamingContext_ptr nc ) = 0; + virtual void rebind_context ( const Name & n, NamingContext_ptr nc ) = 0; + virtual CORBA::Object_ptr resolve ( const Name & n ) = 0; + virtual void unbind ( const Name & n ) = 0; + virtual NamingContext_ptr new_context ( ) = 0; + virtual NamingContext_ptr bind_new_context ( const Name & n ) = 0; virtual void destroy ( ) = 0; - virtual void ___list ( CORBA::ULong how_many, CosNaming::BindingList *& bl, CosNaming::BindingIterator_ptr & bi ) = 0; + virtual void ___list ( CORBA::ULong how_many, BindingList *& bl, BindingIterator_ptr & bi ) = 0; void list ( CORBA::ULong how_many, - _CORBA_Sequence_OUT_arg bl, - _CORBA_ObjRef_OUT_arg,CosNaming::BindingIterator_Helper > bi ) + _CORBA_Sequence_OUT_arg bl, + _CORBA_ObjRef_OUT_arg,BindingIterator_Helper > bi ) { ___list ( how_many, bl._data, bi._data ); } @@ -294,11 +294,11 @@ static NamingContext_ptr _nil(); static inline size_t NP_alignedSize(NamingContext_ptr obj,size_t initialoffset) { - return CORBA::AlignedObjRef(obj,CosNaming_NamingContext_IntfRepoID,32,initialoffset); + return CORBA::AlignedObjRef(obj,CosNaming_NamingContext_IntfRepoID,40,initialoffset); } static inline void marshalObjRef(NamingContext_ptr obj,NetBufferedStream &s) { - CORBA::MarshalObjRef(obj,CosNaming_NamingContext_IntfRepoID,32,s); + CORBA::MarshalObjRef(obj,CosNaming_NamingContext_IntfRepoID,40,s); } static inline NamingContext_ptr unmarshalObjRef(NetBufferedStream &s) { @@ -309,7 +309,7 @@ } static inline void marshalObjRef(NamingContext_ptr obj,MemBufferedStream &s) { - CORBA::MarshalObjRef(obj,CosNaming_NamingContext_IntfRepoID,32,s); + CORBA::MarshalObjRef(obj,CosNaming_NamingContext_IntfRepoID,40,s); } static inline NamingContext_ptr unmarshalObjRef(MemBufferedStream &s) { @@ -348,17 +348,17 @@ CORBA::BOA_ptr _boa() { return CORBA::BOA::getBOA(); } void _dispose() { _boa()->dispose(this); } omniORB::objectKey _key(); - virtual void bind ( const CosNaming::Name & n, CORBA::Object_ptr obj ) = 0; - virtual void rebind ( const CosNaming::Name & n, CORBA::Object_ptr obj ) = 0; - virtual void bind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ) = 0; - virtual void rebind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ) = 0; - virtual CORBA::Object_ptr resolve ( const CosNaming::Name & n ) = 0; - virtual void unbind ( const CosNaming::Name & n ) = 0; - virtual CosNaming::NamingContext_ptr new_context ( ) = 0; - virtual CosNaming::NamingContext_ptr bind_new_context ( const CosNaming::Name & n ) = 0; + virtual void bind ( const Name & n, CORBA::Object_ptr obj ) = 0; + virtual void rebind ( const Name & n, CORBA::Object_ptr obj ) = 0; + virtual void bind_context ( const Name & n, NamingContext_ptr nc ) = 0; + virtual void rebind_context ( const Name & n, NamingContext_ptr nc ) = 0; + virtual CORBA::Object_ptr resolve ( const Name & n ) = 0; + virtual void unbind ( const Name & n ) = 0; + virtual NamingContext_ptr new_context ( ) = 0; + virtual NamingContext_ptr bind_new_context ( const Name & n ) = 0; virtual void destroy ( ) = 0; - virtual void list ( CORBA::ULong how_many, CosNaming::BindingList *& bl, CosNaming::BindingIterator_ptr & bi ) = 0; - virtual void ___list ( CORBA::ULong how_many, CosNaming::BindingList *& bl, CosNaming::BindingIterator_ptr & bi ) { + virtual void list ( CORBA::ULong how_many, BindingList *& bl, BindingIterator_ptr & bi ) = 0; + virtual void ___list ( CORBA::ULong how_many, BindingList *& bl, BindingIterator_ptr & bi ) { list ( how_many, bl, bi ); } virtual CORBA::Boolean dispatch(GIOP_S &s,const char *op,CORBA::Boolean response); @@ -380,16 +380,16 @@ omni::objectIsReady(this); } virtual ~_proxy_NamingContext() {} - virtual void bind ( const CosNaming::Name & n, CORBA::Object_ptr obj ); - virtual void rebind ( const CosNaming::Name & n, CORBA::Object_ptr obj ); - virtual void bind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ); - virtual void rebind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ); - virtual CORBA::Object_ptr resolve ( const CosNaming::Name & n ); - virtual void unbind ( const CosNaming::Name & n ); - virtual CosNaming::NamingContext_ptr new_context ( ); - virtual CosNaming::NamingContext_ptr bind_new_context ( const CosNaming::Name & n ); + virtual void bind ( const Name & n, CORBA::Object_ptr obj ); + virtual void rebind ( const Name & n, CORBA::Object_ptr obj ); + virtual void bind_context ( const Name & n, NamingContext_ptr nc ); + virtual void rebind_context ( const Name & n, NamingContext_ptr nc ); + virtual CORBA::Object_ptr resolve ( const Name & n ); + virtual void unbind ( const Name & n ); + virtual NamingContext_ptr new_context ( ); + virtual NamingContext_ptr bind_new_context ( const Name & n ); virtual void destroy ( ); - virtual void ___list ( CORBA::ULong how_many, CosNaming::BindingList *& bl, CosNaming::BindingIterator_ptr & bi ); + virtual void ___list ( CORBA::ULong how_many, BindingList *& bl, BindingIterator_ptr & bi ); protected: @@ -408,51 +408,51 @@ public: _nil_NamingContext() { this->PR_setobj(0); } virtual ~_nil_NamingContext() {} - void bind ( const CosNaming::Name & n, CORBA::Object_ptr obj ){ + void bind ( const Name & n, CORBA::Object_ptr obj ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. return; } - void rebind ( const CosNaming::Name & n, CORBA::Object_ptr obj ){ + void rebind ( const Name & n, CORBA::Object_ptr obj ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. return; } - void bind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ){ + void bind_context ( const Name & n, NamingContext_ptr nc ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. return; } - void rebind_context ( const CosNaming::Name & n, CosNaming::NamingContext_ptr nc ){ + void rebind_context ( const Name & n, NamingContext_ptr nc ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. return; } - CORBA::Object_ptr resolve ( const CosNaming::Name & n ){ + CORBA::Object_ptr resolve ( const Name & n ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. CORBA::Object_ptr _result= 0; return _result; } - void unbind ( const CosNaming::Name & n ){ + void unbind ( const Name & n ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. return; } - CosNaming::NamingContext_ptr new_context ( ){ + NamingContext_ptr new_context ( ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. CosNaming::NamingContext_ptr _result= 0; return _result; } - CosNaming::NamingContext_ptr bind_new_context ( const CosNaming::Name & n ){ + NamingContext_ptr bind_new_context ( const Name & n ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. CosNaming::NamingContext_ptr _result= 0; @@ -465,7 +465,7 @@ return; } - void ___list ( CORBA::ULong how_many, CosNaming::BindingList *& bl, CosNaming::BindingIterator_ptr & bi ){ + void ___list ( CORBA::ULong how_many, BindingList *& bl, BindingIterator_ptr & bi ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. return; @@ -484,23 +484,23 @@ virtual const char *irRepoId() const; virtual CORBA::Object_ptr newProxyObject(Rope *r,CORBA::Octet *key,size_t keysize,IOP::TaggedProfileList *profiles,CORBA::Boolean release); virtual CORBA::Boolean is_a(const char *base_repoId) const; - static CosNaming::NamingContext_ptr _nil() { + static NamingContext_ptr _nil() { if (!__nil_NamingContext) { __nil_NamingContext = new CosNaming::_nil_NamingContext; } return __nil_NamingContext; } private: - static CosNaming::NamingContext_ptr __nil_NamingContext; + static NamingContext_ptr __nil_NamingContext; }; #ifndef __CosNaming_BindingIterator__ #define __CosNaming_BindingIterator__ - class BindingIterator; + class BindingIterator; typedef BindingIterator* BindingIterator_ptr; typedef BindingIterator_ptr BindingIteratorRef; - class BindingIterator_Helper { + class BindingIterator_Helper { public: static BindingIterator_ptr _nil(); static CORBA::Boolean is_nil(BindingIterator_ptr p); @@ -515,19 +515,19 @@ typedef _CORBA_ObjRef_Var BindingIterator_var; #endif -#define CosNaming_BindingIterator_IntfRepoID "IDL:CosNaming/BindingIterator:1.0" +#define CosNaming_BindingIterator_IntfRepoID "IDL:omg.org/CosNaming/BindingIterator:1.0" class BindingIterator : public virtual omniObject, public virtual CORBA::Object { public: - virtual CORBA::Boolean ___next_one ( CosNaming::Binding *& b ) = 0; - CORBA::Boolean next_one ( _CORBA_ConstrType_Variable_OUT_arg b ) + virtual CORBA::Boolean ___next_one ( Binding *& b ) = 0; + CORBA::Boolean next_one ( _CORBA_ConstrType_Variable_OUT_arg b ) { return ___next_one ( b._data ); } - virtual CORBA::Boolean ___next_n ( CORBA::ULong how_many, CosNaming::BindingList *& bl ) = 0; + virtual CORBA::Boolean ___next_n ( CORBA::ULong how_many, BindingList *& bl ) = 0; CORBA::Boolean next_n ( CORBA::ULong how_many, - _CORBA_Sequence_OUT_arg bl ) + _CORBA_Sequence_OUT_arg bl ) { return ___next_n ( how_many, bl._data ); } @@ -537,11 +537,11 @@ static BindingIterator_ptr _nil(); static inline size_t NP_alignedSize(BindingIterator_ptr obj,size_t initialoffset) { - return CORBA::AlignedObjRef(obj,CosNaming_BindingIterator_IntfRepoID,34,initialoffset); + return CORBA::AlignedObjRef(obj,CosNaming_BindingIterator_IntfRepoID,42,initialoffset); } static inline void marshalObjRef(BindingIterator_ptr obj,NetBufferedStream &s) { - CORBA::MarshalObjRef(obj,CosNaming_BindingIterator_IntfRepoID,34,s); + CORBA::MarshalObjRef(obj,CosNaming_BindingIterator_IntfRepoID,42,s); } static inline BindingIterator_ptr unmarshalObjRef(NetBufferedStream &s) { @@ -552,7 +552,7 @@ } static inline void marshalObjRef(BindingIterator_ptr obj,MemBufferedStream &s) { - CORBA::MarshalObjRef(obj,CosNaming_BindingIterator_IntfRepoID,34,s); + CORBA::MarshalObjRef(obj,CosNaming_BindingIterator_IntfRepoID,42,s); } static inline BindingIterator_ptr unmarshalObjRef(MemBufferedStream &s) { @@ -591,12 +591,12 @@ CORBA::BOA_ptr _boa() { return CORBA::BOA::getBOA(); } void _dispose() { _boa()->dispose(this); } omniORB::objectKey _key(); - virtual CORBA::Boolean next_one ( CosNaming::Binding *& b ) = 0; - virtual CORBA::Boolean ___next_one ( CosNaming::Binding *& b ) { + virtual CORBA::Boolean next_one ( Binding *& b ) = 0; + virtual CORBA::Boolean ___next_one ( Binding *& b ) { return next_one ( b ); } - virtual CORBA::Boolean next_n ( CORBA::ULong how_many, CosNaming::BindingList *& bl ) = 0; - virtual CORBA::Boolean ___next_n ( CORBA::ULong how_many, CosNaming::BindingList *& bl ) { + virtual CORBA::Boolean next_n ( CORBA::ULong how_many, BindingList *& bl ) = 0; + virtual CORBA::Boolean ___next_n ( CORBA::ULong how_many, BindingList *& bl ) { return next_n ( how_many, bl ); } virtual void destroy ( ) = 0; @@ -619,8 +619,8 @@ omni::objectIsReady(this); } virtual ~_proxy_BindingIterator() {} - virtual CORBA::Boolean ___next_one ( CosNaming::Binding *& b ); - virtual CORBA::Boolean ___next_n ( CORBA::ULong how_many, CosNaming::BindingList *& bl ); + virtual CORBA::Boolean ___next_one ( Binding *& b ); + virtual CORBA::Boolean ___next_n ( CORBA::ULong how_many, BindingList *& bl ); virtual void destroy ( ); protected: @@ -640,14 +640,14 @@ public: _nil_BindingIterator() { this->PR_setobj(0); } virtual ~_nil_BindingIterator() {} - CORBA::Boolean ___next_one ( CosNaming::Binding *& b ){ + CORBA::Boolean ___next_one ( Binding *& b ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. CORBA::Boolean _result = 0; return _result; } - CORBA::Boolean ___next_n ( CORBA::ULong how_many, CosNaming::BindingList *& bl ){ + CORBA::Boolean ___next_n ( CORBA::ULong how_many, BindingList *& bl ){ throw CORBA::BAD_OPERATION(0,CORBA::COMPLETED_NO); // never reach here! Dummy return to keep some compilers happy. CORBA::Boolean _result = 0; @@ -673,14 +673,14 @@ virtual const char *irRepoId() const; virtual CORBA::Object_ptr newProxyObject(Rope *r,CORBA::Octet *key,size_t keysize,IOP::TaggedProfileList *profiles,CORBA::Boolean release); virtual CORBA::Boolean is_a(const char *base_repoId) const; - static CosNaming::BindingIterator_ptr _nil() { + static BindingIterator_ptr _nil() { if (!__nil_BindingIterator) { __nil_BindingIterator = new CosNaming::_nil_BindingIterator; } return __nil_BindingIterator; } private: - static CosNaming::BindingIterator_ptr __nil_BindingIterator; + static BindingIterator_ptr __nil_BindingIterator; }; }; diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/bufferedStream.h include/omniORB2/bufferedStream.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/bufferedStream.h Tue May 6 13:37:54 1997 +++ include/omniORB2/bufferedStream.h Thu Jul 3 10:06:58 1997 @@ -70,7 +70,7 @@ #error "UMARSHAL has already been defined" #endif -class NetBufferedStream : public Strand_Sync { +class _OMNIORB2_NTDLL_ NetBufferedStream : public Strand_Sync { public: NetBufferedStream(Strand *s, _CORBA_Boolean RdLock=1, @@ -338,7 +338,7 @@ -class MemBufferedStream { +class _OMNIORB2_NTDLL_ MemBufferedStream { public: MemBufferedStream(size_t initialBufsize=0); ~MemBufferedStream(); diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/giopDriver.h include/omniORB2/giopDriver.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/giopDriver.h Tue May 6 13:38:23 1997 +++ include/omniORB2/giopDriver.h Thu Jul 3 10:08:50 1997 @@ -72,7 +72,7 @@ id = i; len = strlen((const char *)i); } }; - class SysExceptRepoID { + class _OMNIORB2_NTDLL_ SysExceptRepoID { public: static const _SysExceptRepoID UNKNOWN; static const _SysExceptRepoID BAD_PARAM; @@ -108,7 +108,7 @@ static size_t max_giop_message_size; }; -class GIOP_C : public GIOP_Basetypes, public NetBufferedStream { +class _OMNIORB2_NTDLL_ GIOP_C : public GIOP_Basetypes, public NetBufferedStream { public: GIOP_C(Rope *r); @@ -228,7 +228,7 @@ }; -class GIOP_S : public GIOP_Basetypes, public NetBufferedStream { +class _OMNIORB2_NTDLL_ GIOP_S : public GIOP_Basetypes, public NetBufferedStream { public: static void dispatcher(Strand *s); diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/omniInternal.h include/omniORB2/omniInternal.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/omniInternal.h Tue May 6 13:39:17 1997 +++ include/omniORB2/omniInternal.h Wed Jul 2 15:45:50 1997 @@ -29,6 +29,9 @@ /* $Log: omniInternal.h,v $ + * Revision 1.1 1997/06/25 17:36:04 matthew + * Initial revision + * * Revision 1.9 1997/05/06 16:09:13 sll * Public release. * @@ -69,6 +72,8 @@ _CORBA_ULong lo; }; +class Omni_Activator; + class _OMNIORB2_NTDLL_ omni { public: @@ -124,6 +129,7 @@ // call to BOA::dispose(). static omniObject *locateObject(omniObjectKey &k); + static omniObject *locateObjectInternal(omniObjectKey &k); static void disposeObject(omniObject *obj); // If the reference count of the object is 0, call the delete operator // to remove the object. @@ -231,7 +237,7 @@ omniRopeAndKey(const omniRopeAndKey&); }; -class omniObject { +class _OMNIORB2_NTDLL_ omniObject { protected: @@ -317,6 +323,7 @@ friend char * omni::objectToString(const omniObject *obj); friend void omni::objectDuplicate(omniObject *obj); friend omniObject *omni::locateObject(omniObjectKey &k); + friend omniObject *omni::locateObjectInternal(omniObjectKey &k); friend void omni::disposeObject(omniObject *obj); friend void omni::objectRelease(omniObject *obj); friend char *objectToString(const omniObject *obj); diff -u /pub/corba/omniORB_2.2.0/include/omniORB2/omniORB.h include/omniORB2/omniORB.h --- /pub/corba/omniORB_2.2.0/include/omniORB2/omniORB.h Tue May 6 13:39:44 1997 +++ include/omniORB2/omniORB.h Wed Jul 2 15:16:12 1997 @@ -29,6 +29,9 @@ /* $Log: omniORB.h,v $ + * Revision 1.1 1997/06/25 18:02:04 matthew + * Initial revision + * * Revision 1.5 1997/05/06 16:09:39 sll * Public release. * @@ -37,6 +40,8 @@ #ifndef __OMNIORB_H__ #define __OMNIORB_H__ +class Omni_Activator; + class _OMNIORB2_NTDLL_ omniORB { public: @@ -167,9 +172,27 @@ }; // //////////////////////////////////////////////////////////////////////// + // on demand object activation. + + static void register_activator(Omni_Activator* activator); + static void unregister_activator(Omni_Activator* activator); + static _CORBA_Boolean activate(omniObjectKey &k); + friend class omni; private: + static omni_mutex activatorLock; + static Omni_Activator* activatorHead; static objectKey seed; +}; + +class _OMNIORB2_NTDLL_ Omni_Activator +{ +public: + virtual ~Omni_Activator() = 0; + virtual _CORBA_Boolean activate(const omniObjectKey& key) = 0; +private: + friend class omniORB; + Omni_Activator* pd_next; }; #endif // __OMNIORB_H__ diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/Makefile src/lib/omniORB2/Makefile --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/Makefile Fri May 2 08:28:48 1997 +++ src/lib/omniORB2/Makefile Thu Jul 3 10:15:08 1997 @@ -10,7 +10,7 @@ ORB2_OBJS = constants.o corbaBoa.o corbaObject.o corbaOrb.o \ corbaString.o \ exception.o giopClient.o giopServer.o initFile.o ior.o \ - libcWrapper.o mbufferedStream.o nbufferedStream.o $(NAMINGOBJ) \ + libcWrapper.o mbufferedStream.o nbufferedStream.o\ object.o objectRef.o objectKey.o orb.o strand.o $(NETLIBOBJS) \ unshared.o @@ -19,25 +19,33 @@ -DCONFIG_DEFAULT_LOCATION=$(OMNIORB_CONFIG_DEFAULT_LOCATION) -all:: libomniORB2.a +all:: libomniORB2.a libnaming.a -libomniORB2.a: Naming.hh $(ORB2_OBJS) +libomniORB2.a: $(ORB2_OBJS) (set -x; \ $(RM) $@; \ $(AR) $@ $(ORB2_OBJS); \ $(RANLIB) $@; \ ) +libnaming.a: Naming.hh $(NAMINGOBJ) + (set -x; \ + $(RM) $@; \ + $(AR) $@ $(NAMINGOBJ); \ + $(RANLIB) $@; \ + ) + Naming.hh NamingSK.cc: Naming.idl $(BINDIR)/omniidl2 Naming.idl clean:: $(RM) *.a *.o Naming.hh NamingSK.cc -install:: libomniORB2.a +install:: libomniORB2.a libnaming.a (set -x; \ $(MKDIRHIER) $(LIBDIR); \ $(CP) libomniORB2.a $(LIBDIR); \ + $(CP) libnaming.a $(LIBDIR); \ ) SUBDIRS = sharedlib @@ -172,7 +180,6 @@ corbaBoa.o : ../../../include/omniORB2/omniORB.h corbaBoa.o : ../../../include/omniORB2/templates.h corbaBoa.o : ../../../include/omniORB2/proxyFactory.h -corbaBoa.o : Naming.hh corbaBoa.o : ../../../include/omniORB2/CORBA.h corbaObject.o : corbaObject.cc corbaObject.o : ../../../include/omniORB2/CORBA.h @@ -195,7 +202,6 @@ corbaObject.o : ../../../include/omniORB2/omniORB.h corbaObject.o : ../../../include/omniORB2/templates.h corbaObject.o : ../../../include/omniORB2/proxyFactory.h -corbaObject.o : Naming.hh corbaObject.o : ../../../include/omniORB2/CORBA.h corbaOrb.o : corbaOrb.cc corbaOrb.o : ../../../include/omniORB2/CORBA.h @@ -218,7 +224,6 @@ corbaOrb.o : ../../../include/omniORB2/omniORB.h corbaOrb.o : ../../../include/omniORB2/templates.h corbaOrb.o : ../../../include/omniORB2/proxyFactory.h -corbaOrb.o : Naming.hh corbaOrb.o : ../../../include/omniORB2/CORBA.h corbaString.o : corbaString.cc corbaString.o : ../../../include/omniORB2/CORBA.h @@ -241,7 +246,6 @@ corbaString.o : ../../../include/omniORB2/omniORB.h corbaString.o : ../../../include/omniORB2/templates.h corbaString.o : ../../../include/omniORB2/proxyFactory.h -corbaString.o : Naming.hh corbaString.o : ../../../include/omniORB2/CORBA.h exception.o : exception.cc exception.o : ../../../include/omniORB2/CORBA.h @@ -264,7 +268,6 @@ exception.o : ../../../include/omniORB2/omniORB.h exception.o : ../../../include/omniORB2/templates.h exception.o : ../../../include/omniORB2/proxyFactory.h -exception.o : Naming.hh exception.o : ../../../include/omniORB2/CORBA.h giopClient.o : giopClient.cc giopClient.o : ../../../include/omniORB2/CORBA.h @@ -287,7 +290,6 @@ giopClient.o : ../../../include/omniORB2/omniORB.h giopClient.o : ../../../include/omniORB2/templates.h giopClient.o : ../../../include/omniORB2/proxyFactory.h -giopClient.o : Naming.hh giopClient.o : ../../../include/omniORB2/CORBA.h giopServer.o : giopServer.cc giopServer.o : ../../../include/omniORB2/CORBA.h @@ -310,7 +312,6 @@ giopServer.o : ../../../include/omniORB2/omniORB.h giopServer.o : ../../../include/omniORB2/templates.h giopServer.o : ../../../include/omniORB2/proxyFactory.h -giopServer.o : Naming.hh giopServer.o : ../../../include/omniORB2/CORBA.h initFile.o : initFile.cc initFile.o : ../../../include/omniORB2/CORBA.h @@ -333,7 +334,6 @@ initFile.o : ../../../include/omniORB2/omniORB.h initFile.o : ../../../include/omniORB2/templates.h initFile.o : ../../../include/omniORB2/proxyFactory.h -initFile.o : Naming.hh initFile.o : ../../../include/omniORB2/CORBA.h ior.o : ior.cc ior.o : ../../../include/omniORB2/CORBA.h @@ -356,7 +356,6 @@ ior.o : ../../../include/omniORB2/omniORB.h ior.o : ../../../include/omniORB2/templates.h ior.o : ../../../include/omniORB2/proxyFactory.h -ior.o : Naming.hh ior.o : ../../../include/omniORB2/CORBA.h libcWrapper.o : libcWrapper.cc libcWrapper.o : ../../../include/omniORB2/CORBA.h @@ -379,7 +378,6 @@ libcWrapper.o : ../../../include/omniORB2/omniORB.h libcWrapper.o : ../../../include/omniORB2/templates.h libcWrapper.o : ../../../include/omniORB2/proxyFactory.h -libcWrapper.o : Naming.hh libcWrapper.o : ../../../include/omniORB2/CORBA.h libcWrapper.o : libcWrapper.h mbufferedStream.o : mbufferedStream.cc @@ -403,7 +401,6 @@ mbufferedStream.o : ../../../include/omniORB2/omniORB.h mbufferedStream.o : ../../../include/omniORB2/templates.h mbufferedStream.o : ../../../include/omniORB2/proxyFactory.h -mbufferedStream.o : Naming.hh mbufferedStream.o : ../../../include/omniORB2/CORBA.h nbufferedStream.o : nbufferedStream.cc nbufferedStream.o : ../../../include/omniORB2/CORBA.h @@ -426,7 +423,6 @@ nbufferedStream.o : ../../../include/omniORB2/omniORB.h nbufferedStream.o : ../../../include/omniORB2/templates.h nbufferedStream.o : ../../../include/omniORB2/proxyFactory.h -nbufferedStream.o : Naming.hh nbufferedStream.o : ../../../include/omniORB2/CORBA.h object.o : object.cc object.o : ../../../include/omniORB2/CORBA.h @@ -449,7 +445,6 @@ object.o : ../../../include/omniORB2/omniORB.h object.o : ../../../include/omniORB2/templates.h object.o : ../../../include/omniORB2/proxyFactory.h -object.o : Naming.hh object.o : ../../../include/omniORB2/CORBA.h objectKey.o : objectKey.cc objectKey.o : ../../../include/omniORB2/CORBA.h @@ -472,7 +467,6 @@ objectKey.o : ../../../include/omniORB2/omniORB.h objectKey.o : ../../../include/omniORB2/templates.h objectKey.o : ../../../include/omniORB2/proxyFactory.h -objectKey.o : Naming.hh objectKey.o : ../../../include/omniORB2/CORBA.h objectRef.o : objectRef.cc objectRef.o : ../../../include/omniORB2/CORBA.h @@ -495,7 +489,6 @@ objectRef.o : ../../../include/omniORB2/omniORB.h objectRef.o : ../../../include/omniORB2/templates.h objectRef.o : ../../../include/omniORB2/proxyFactory.h -objectRef.o : Naming.hh objectRef.o : ../../../include/omniORB2/CORBA.h objectRef.o : ../../../include/omniORB2/proxyFactory.h orb.o : orb.cc @@ -519,7 +512,6 @@ orb.o : ../../../include/omniORB2/omniORB.h orb.o : ../../../include/omniORB2/templates.h orb.o : ../../../include/omniORB2/proxyFactory.h -orb.o : Naming.hh orb.o : ../../../include/omniORB2/CORBA.h orb.o : tcpSocket_UNIX.h strand.o : strand.cc @@ -543,7 +535,6 @@ strand.o : ../../../include/omniORB2/omniORB.h strand.o : ../../../include/omniORB2/templates.h strand.o : ../../../include/omniORB2/proxyFactory.h -strand.o : Naming.hh strand.o : ../../../include/omniORB2/CORBA.h tcpSocket_UNIX.o : tcpSocket_UNIX.cc tcpSocket_UNIX.o : ../../../include/omniORB2/CORBA.h @@ -566,7 +557,6 @@ tcpSocket_UNIX.o : ../../../include/omniORB2/omniORB.h tcpSocket_UNIX.o : ../../../include/omniORB2/templates.h tcpSocket_UNIX.o : ../../../include/omniORB2/proxyFactory.h -tcpSocket_UNIX.o : Naming.hh tcpSocket_UNIX.o : ../../../include/omniORB2/CORBA.h tcpSocket_UNIX.o : tcpSocket_UNIX.h tcpSocket_UNIX.o : libcWrapper.h @@ -591,7 +581,6 @@ unshared.o : ../../../include/omniORB2/omniORB.h unshared.o : ../../../include/omniORB2/templates.h unshared.o : ../../../include/omniORB2/proxyFactory.h -unshared.o : Naming.hh unshared.o : ../../../include/omniORB2/CORBA.h unshared.o : libcWrapper.h unshared.o : tcpSocket_UNIX.h diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/Naming.idl src/lib/omniORB2/Naming.idl --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/Naming.idl Tue Jan 21 11:09:10 1997 +++ src/lib/omniORB2/Naming.idl Wed Jun 25 11:45:47 1997 @@ -17,6 +17,8 @@ */ +#pragma prefix "omg.org" + module CosNaming { typedef string Istring; diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/constants.cc src/lib/omniORB2/constants.cc --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/constants.cc Tue May 6 12:37:52 1997 +++ src/lib/omniORB2/constants.cc Thu Jul 3 10:20:14 1997 @@ -29,6 +29,9 @@ /* $Log: constants.cc,v $ +// Revision 1.1 1997/06/25 17:38:36 matthew +// Initial revision +// // Revision 1.4 1997/05/06 15:07:47 sll // Public release. // diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/corbaBoa.cc src/lib/omniORB2/corbaBoa.cc --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/corbaBoa.cc Tue May 6 12:39:09 1997 +++ src/lib/omniORB2/corbaBoa.cc Thu Jun 26 17:21:56 1997 @@ -29,6 +29,9 @@ /* $Log: corbaBoa.cc,v $ +// Revision 1.1 1997/06/25 17:37:45 matthew +// Initial revision +// // Revision 1.3 1997/05/06 15:09:04 sll // Public release. // @@ -156,3 +159,44 @@ return; } +CORBA::Object_ptr +CORBA:: +BOA::make_object(const omniObjectKey& k, const char* type_id) +{ + IOP::TaggedProfileList * p = 0; + omniObject* omniObj = 0; + CORBA::Object_ptr o = 0; + try + { + Rope *r = 0; + { + Rope_iterator next(&Anchor::incomingAnchor); + r = next(); + } + if (r == 0) + { + throw CORBA::INTERNAL(0,CORBA::COMPLETED_NO); + } + p = new IOP::TaggedProfileList(1); + if (p == 0) + { + throw CORBA::NO_MEMORY(0,CORBA::COMPLETED_NO); + } + p->length(1); + r->iopProfile((CORBA::Char *)&k, + sizeof(omniObjectKey), + ((IOP::TaggedProfileList &) *p)[0]); + omniObj = omni::createObjRef(type_id, type_id, p, 0); + delete p; + o = new Object(); + o->PR_setobj(omniObj); + } + catch (...) + { + delete p; + //delete omniObj; + delete o; + throw; + } + return o; +} diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/initFile.cc src/lib/omniORB2/initFile.cc --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/initFile.cc Mon May 12 11:43:41 1997 +++ src/lib/omniORB2/initFile.cc Thu Jul 3 10:13:56 1997 @@ -29,6 +29,9 @@ /* $Log: initFile.cc,v $ +// Revision 1.1 1997/07/03 12:43:28 matthew +// Initial revision +// // Revision 1.12 1997/05/12 14:13:33 ewc // Minor cosmetic change. // @@ -193,13 +196,16 @@ if (objptr) { +#if 0 if((objptr->_widenFromTheMostDerivedIntf( CosNaming_NamingContext_IntfRepoID)) == 0) { // The object reference supplied is not for the NamingService invref(entryname); } - else NameService = objptr; + else +#endif + NameService = objptr; } else invref(entryname); diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/objectRef.cc src/lib/omniORB2/objectRef.cc --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/objectRef.cc Tue May 6 12:56:41 1997 +++ src/lib/omniORB2/objectRef.cc Thu Jun 26 16:27:26 1997 @@ -29,6 +29,9 @@ /* $Log: objectRef.cc,v $ +// Revision 1.1 1997/06/25 17:49:16 matthew +// Initial revision +// // Revision 1.7 1997/05/06 15:26:37 sll // Public release. // @@ -218,6 +221,7 @@ return; } obj->setRefCount(obj->getRefCount()-1); + omniObject* toDelete = 0; if (obj->getRefCount() == 0) { if (obj->is_proxy()) { omniObject **p = &omniObject::proxyObjectTable; @@ -228,7 +232,7 @@ } p = &((*p)->pd_next); } - delete obj; + toDelete = obj; } else { omniObject **p = &omniObject::localObjectTable[omniORB::hash(obj->pd_objkey.native)]; @@ -240,10 +244,12 @@ p = &((*p)->pd_next); } if (obj->pd_disposed) - delete obj; // call dtor if BOA->disposed() has been called. + toDelete = obj; } } omniObject::objectTableLock.unlock(); + if (toDelete != 0) + delete toDelete; // call dtor if BOA->disposed() has been called. return; } @@ -253,39 +259,56 @@ if (obj->is_proxy()) return; omniObject::objectTableLock.lock(); - if (obj->getRefCount() <= 0) { - omniObject::objectTableLock.unlock(); - throw CORBA::INV_OBJREF(0,CORBA::COMPLETED_NO); - } - else - obj->setRefCount(obj->getRefCount()-1); + omniObject* toDelete = 0; if (obj->getRefCount() == 0) { // object has already been removed from the object table - delete obj; + toDelete = obj; } else { obj->pd_disposed = 1; } omniObject::objectTableLock.unlock(); + if (toDelete != 0) + delete toDelete; return; } omniObject * -omni::locateObject(omniObjectKey &k) +omni::locateObjectInternal(omniObjectKey &k) { omniObject::objectTableLock.lock(); - omniObject **p = &omniObject::localObjectTable[omniORB::hash(k)]; - while (*p) { - if ((*p)->pd_objkey.native == k) { - (*p)->setRefCount((*p)->getRefCount()+1); - omniObject::objectTableLock.unlock(); - return *p; + omniObject *p = omniObject::localObjectTable[omniORB::hash(k)]; + while (p) { + if (p->pd_objkey.native == k) { + p->setRefCount(p->getRefCount()+1); + break; } - p = &((*p)->pd_next); + p = p->pd_next; } omniObject::objectTableLock.unlock(); + return p; +} + +omniObject * +omni::locateObject(omniObjectKey &k) +{ + omniObject* obj = locateObjectInternal(k); + if (obj != 0) + { + return obj; + } + + if (omniORB::activate(k)) + { + obj = locateObjectInternal(k); + if (obj != 0) + { + return obj; + } + } + throw CORBA::OBJECT_NOT_EXIST(0,CORBA::COMPLETED_NO); return 0; // MS VC++ 4.0 needs this. } diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/orb.cc src/lib/omniORB2/orb.cc --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/orb.cc Tue May 6 12:57:18 1997 +++ src/lib/omniORB2/orb.cc Wed Jun 25 15:50:39 1997 @@ -29,6 +29,9 @@ /* $Log: orb.cc,v $ +// Revision 1.1 1997/06/25 17:41:27 matthew +// Initial revision +// // Revision 1.9 1997/05/06 15:27:14 sll // Public release. // @@ -865,4 +868,59 @@ return 0; } return 1; +} + +/*static*/ void +omniORB::register_activator(Omni_Activator* activator) +{ + activatorLock.lock(); + + activator->pd_next = activatorHead; + activatorHead = activator; + + activatorLock.unlock(); +} + +/*static*/ void +omniORB::unregister_activator(Omni_Activator* activator) +{ + int found = 0; + + activatorLock.lock(); + Omni_Activator** curr = &activatorHead; + while (*curr != 0) + { + if ((*curr) == activator) + { + *curr = (*curr)->pd_next; + found = 1; + break; + } + curr = &(*curr)->pd_next; + } + activatorLock.unlock(); + + if (!found && omniORB::traceLevel > 0) + { + cerr << "Cannot find activator in activator list." << endl; + } +} + +/*static*/ CORBA::Boolean +omniORB::activate(omniObjectKey &k) +{ + activatorLock.lock(); + Omni_Activator* curr = activatorHead; + while (curr != 0) + { + if (curr->activate(k)) + break; + curr = curr->pd_next; + } + activatorLock.unlock(); + return curr != 0; +} + +Omni_Activator::~Omni_Activator() +{ } diff -u /pub/corba/omniORB_2.2.0/src/lib/omniORB2/unshared.cc src/lib/omniORB2/unshared.cc --- /pub/corba/omniORB_2.2.0/src/lib/omniORB2/unshared.cc Tue May 6 13:03:02 1997 +++ src/lib/omniORB2/unshared.cc Thu Jul 3 10:20:27 1997 @@ -32,6 +32,9 @@ /* $Log: unshared.cc,v $ +// Revision 1.1 1997/06/25 17:39:13 matthew +// Initial revision +// // Revision 1.5 1997/05/06 15:32:58 sll // Public release. // @@ -56,6 +59,9 @@ CORBA::Object CORBA::Object::CORBA_Object_nil; +omni_mutex omniORB::activatorLock; +Omni_Activator* omniORB::activatorHead = 0; + omni_mutex omni::initLock; CORBA::Boolean omni::orb_initialised = 0; CORBA::Boolean omni::boa_initialised = 0; @@ -85,6 +91,4 @@ omniORB::objectKey omniORB::seed; -static const CosNaming::NamingContext_proxyObjectFactory CosNaming_NamingContext_proxyObjectFactory1; // To ensure that Naming Stubs are linked. - - +//static const CosNaming::NamingContext_proxyObjectFactory CosNaming_NamingContext_proxyObjectFactory1; // To ensure that Naming Stubs are linked. diff -u /pub/corba/omniORB_2.2.0/src/appl/omniNames/NamingContext_i.h src/appl/omniNames/NamingContext_i.h --- /pub/corba/omniORB_2.2.0/src/appl/omniNames/NamingContext_i.h Wed May 7 12:07:38 1997 +++ src/appl/omniNames/NamingContext_i.h Wed Jul 2 14:13:44 1997 @@ -28,11 +28,7 @@ #include #include -#ifdef __NT__ -#include -#else #include -#endif class NamingContext_i : public virtual CosNaming::_sk_NamingContext { diff -u /pub/corba/omniORB_2.2.0/src/appl/omniNames/log.h src/appl/omniNames/log.h --- /pub/corba/omniORB_2.2.0/src/appl/omniNames/log.h Wed May 7 12:06:15 1997 +++ src/appl/omniNames/log.h Thu Jul 3 11:50:10 1997 @@ -26,6 +26,7 @@ #define _log_h_ #include +#include #include #ifndef LOGDIR_ENV_VAR diff -u /pub/corba/omniORB_2.2.0/build-win32/Applications.mak build-win32/Applications.mak --- /pub/corba/omniORB_2.2.0/build-win32/Applications.mak Thu May 8 16:24:09 1997 +++ build-win32/Applications.mak Thu Jul 3 11:52:31 1997 @@ -114,7 +114,7 @@ /Fo"$(INTDIR)/" /c CPP_OBJS=$(BASEDIR)\appl\omniNames/ -LINK32_FLAGS=kernel32.lib user32.lib wsock32.lib advapi32.lib omniORB2_rt.lib\ +LINK32_FLAGS=kernel32.lib user32.lib wsock32.lib advapi32.lib naming_rt.lib omniORB2_rt.lib\ omnithread_rt.lib /nologo /subsystem:console /pdb:none /machine:I386\ /out:"$(OUTDIR)/omniNames.exe" LINK32_OBJS= \ @@ -203,7 +203,7 @@ "__NT__" /D "_X86_" /Fo"$(INTDIR)/" /c CPP_OBJS=$(BASEDIR)\appl\utils\nameclt/ -LINK32_FLAGS=kernel32.lib user32.lib wsock32.lib advapi32.lib omniORB2_rt.lib\ +LINK32_FLAGS=kernel32.lib user32.lib wsock32.lib advapi32.lib naming_rt.lib omniORB2_rt.lib\ omnithread_rt.lib /nologo /subsystem:console /pdb:none /machine:I386\ /out:"$(OUTDIR)/nameclt.exe" LINK32_OBJS= \ diff -u /pub/corba/omniORB_2.2.0/build-win32/MAKEFILE build-win32/MAKEFILE --- /pub/corba/omniORB_2.2.0/build-win32/MAKEFILE Fri May 9 07:01:01 1997 +++ build-win32/MAKEFILE Thu Jul 3 11:52:53 1997 @@ -21,7 +21,8 @@ "omnithread_DLL" && "$(CFG)" != "omniORB2_static"\ && "$(CFG)" != "omnithread_static" && "$(CFG)" != "ALL" \ && "$(CFG)" != "omniidl2" && "$(CFG)" != "Applications" && "$(CFG)" != "all" \ - && "$(CFG)" != "install" && "$(CFG)" != "INSTALL" + && "$(CFG)" != "install" && "$(CFG)" != "INSTALL" \ + && "$(CFG)" != "naming_shared" && "$(CFG)" != "naming_static" !IF "$(CFG)" != "HELP" !MESSAGE Invalid configuration "$(CFG)" specified. @@ -80,6 +81,8 @@ @copy $(BASEDIR)\omniORB2_shared\omniORB2_rt.lib $(INSTALL_LOC)\lib @copy $(BASEDIR)\omnithread_shared\omnithread_rt.lib $(INSTALL_LOC)\lib @copy $(BASEDIR)\omniORB2_static\omniORB2.lib $(INSTALL_LOC)\lib + @copy $(BASEDIR)\omniORB2_static\naming.lib $(INSTALL_LOC)\lib + @copy $(BASEDIR)\omniORB2_static\naming_rt.lib $(INSTALL_LOC)\lib @copy $(BASEDIR)\omnithread_static\omnithread.lib $(INSTALL_LOC)\lib @copy $(BASEDIR)\omniidl2\omniidl2.exe $(INSTALL_LOC)\bin @copy $(BASEDIR)\appl\omniNames\omniNames.exe $(INSTALL_LOC)\bin @@ -99,7 +102,7 @@ @copy $(INCLDIR)\omniORB2\IIOP.h $(INSTALL_LOC)\include\omniORB2 @copy $(INCLDIR)\omniORB2\initFile.h $(INSTALL_LOC)\include\omniORB2 @copy $(INCLDIR)\omniORB2\IOP.h $(INSTALL_LOC)\include\omniORB2 - @copy $(INCLDIR)\omniORB2\Naming_NT.hh $(INSTALL_LOC)\include\omniORB2 + @copy $(INCLDIR)\omniORB2\Naming.hh $(INSTALL_LOC)\include\omniORB2 @copy $(INCLDIR)\omniORB2\omniInternal.h $(INSTALL_LOC)\include\omniORB2 @copy $(INCLDIR)\omniORB2\omniORB.h $(INSTALL_LOC)\include\omniORB2 @copy $(INCLDIR)\omniORB2\proxyFactory.h $(INSTALL_LOC)\include\omniORB2 @@ -139,6 +142,8 @@ ALL : $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CFG="omniORB2_DLL" $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CFG="omniORB2_static" + $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CFG="naming_static" + $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CFG="naming_shared" $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CFG="omniidl2" $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CFG="Applications" @@ -146,6 +151,8 @@ CLEAN: $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CLEAN CFG="omniORB2_DLL" $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CLEAN CFG="omniORB2_static" + $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CLEAN CFG="naming_static" + $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CLEAN CFG="naming_shared" $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CLEAN CFG="omniidl2" $(MAKE) /$(MAKEFLAGS) /F "MAKEFILE" CLEAN CFG="Applications" @@ -202,7 +209,7 @@ -@erase "$(INTDIR)\ior.obj" -@erase "$(INTDIR)\libcWrapper.obj" -@erase "$(INTDIR)\mbufferedStream.obj" - -@erase "$(INTDIR)\NamingSK_NT.obj" + -@erase "$(INTDIR)\NamingSK.obj" -@erase "$(INTDIR)\nbufferedStream.obj" -@erase "$(INTDIR)\object.obj" -@erase "$(INTDIR)\objectKey.obj" @@ -219,17 +226,19 @@ "$(OUTDIR)" : if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" -CPP_PROJ=/nologo /MD /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ +#CPP_PROJ=/nologo /MD /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ +# "__NT__" /D "_X86_" /D "NTArchitecture" /D "_OMNIORB2_DLL" /Fo"$(INTDIR)/" /c +CPP_PROJ=/nologo /MD /W3 /GX /Zi /D "WIN32" /D "_WINDOWS" /D\ "__NT__" /D "_X86_" /D "NTArchitecture" /D "_OMNIORB2_DLL" /Fo"$(INTDIR)/" /c CPP_OBJS=$(BASEDIR)\omniORB2_shared/ .cc{$(CPP_OBJS)}.obj: $(CPP) $(CPP_PROJ) $< -LINK32_FLAGS=wsock32.lib advapi32.lib \ - "$(BASEDIR)\omnithread_shared\omnithread_rt.lib" /nologo /subsystem:windows\ - /dll /pdb:none /machine:I386 /def:"$(SRCDIR)\omniORB2\omniorb2.def" \ - /out:"$(OUTDIR)/omniORB2_rt.dll" /implib:"$(OUTDIR)/omniORB2_rt.lib" +#LINK32_FLAGS=wsock32.lib advapi32.lib "$(BASEDIR)\omnithread_shared\omnithread_rt.lib" /nologo /subsystem:windows /dll /pdb:none /machine:I386 /out:"$(OUTDIR)/omniORB2_rt.dll" /implib:"$(OUTDIR)/omniORB2_rt.lib" + +LINK32_FLAGS=wsock32.lib advapi32.lib "$(BASEDIR)\omnithread_shared\omnithread_rt.lib" /nologo /subsystem:windows /dll /DEBUG:full /machine:I386 /out:"$(OUTDIR)/omniORB2_rt.dll" /implib:"$(OUTDIR)/omniORB2_rt.lib" + LINK32_OBJS= \ "$(INTDIR)\constants.obj" \ "$(INTDIR)\corbaBoa.obj" \ @@ -243,7 +252,6 @@ "$(INTDIR)\ior.obj" \ "$(INTDIR)\libcWrapper.obj" \ "$(INTDIR)\mbufferedStream.obj" \ - "$(INTDIR)\NamingSK_NT.obj" \ "$(INTDIR)\nbufferedStream.obj" \ "$(INTDIR)\object.obj" \ "$(INTDIR)\objectKey.obj" \ @@ -255,10 +263,7 @@ "$(BASEDIR)\omnithread_shared\omnithread_rt.lib" "$(OUTDIR)\omniORB2_rt.dll" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) - $(LINK32) @<< - $(LINK32_FLAGS) $(LINK32_OBJS) -<< - + $(LINK32) $(LINK32_FLAGS) $(LINK32_OBJS) !ELSEIF "$(CFG)" == "omnithread_DLL" @@ -276,16 +281,20 @@ "$(OUTDIR)" : if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" -CPP_PROJ=/nologo /MD /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ - "__NT__" /D "_X86_" /D "NTArchitecture" /D "_OMNITHREAD_DLL" /Fo"$(INTDIR)/" /c\ +#CPP_PROJ=/nologo /MD /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ +# "__NT__" /D "_X86_" /D "NTArchitecture" /D "_OMNITHREAD_DLL" /Fo"$(INTDIR)/" /c +CPP_PROJ=/nologo /MD /W3 /GX /Zi /D "WIN32" /D "_WINDOWS" /D\ + "__NT__" /D "_X86_" /D "NTArchitecture" /D "_OMNITHREAD_DLL" /Fo"$(INTDIR)/" /c CPP_OBJS=$(BASEDIR)\omnithread_shared/ .cc{$(CPP_OBJS)}.obj: $(CPP) $(CPP_PROJ) $< -LINK32_FLAGS=/nologo /subsystem:windows /dll /pdb:none /machine:I386\ - /out:"$(OUTDIR)/omnithread_rt.dll" /implib:"$(OUTDIR)/omnithread_rt.lib" +#LINK32_FLAGS=/nologo /subsystem:windows /dll /pdb:none /machine:I386 /out:"$(OUTDIR)/omnithread_rt.dll" /implib:"$(OUTDIR)/omnithread_rt.lib" + +LINK32_FLAGS=/nologo /subsystem:windows /dll /DEBUG:FULL /machine:I386 /out:"$(OUTDIR)/omnithread_rt.dll" /implib:"$(OUTDIR)/omnithread_rt.lib" + LINK32_OBJS= \ "$(INTDIR)\nt.obj" @@ -296,13 +305,59 @@ +!ELSEIF "$(CFG)" == "naming_shared" + +OUTDIR=$(BASEDIR)\omniORB2_shared +INTDIR=$(BASEDIR)\omniORB2_shared + +ALL : "$(OUTDIR)\naming_rt.lib" + +CLEAN : + -@erase "$(INTDIR)\NamingSK.obj" + +"$(OUTDIR)" : + if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" + +CPP_PROJ=/nologo /MD /W3 /GX /Zi /D "WIN32" /D "_WINDOWS" /D\ + "__NT__" /D "_X86_" /D "NTArchitecture" /Fo"$(INTDIR)/" /c + +LINK32_FLAGS=/lib /out:"$(OUTDIR)/naming_rt.lib" +LINK32_OBJS= \ + "$(INTDIR)\NamingSK.obj" + +"$(OUTDIR)\naming_rt.lib" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) + $(LINK32) $(LINK32_FLAGS) $(LINK32_OBJS) + +!ELSEIF "$(CFG)" == "naming_static" + +OUTDIR=$(BASEDIR)\omniORB2_static +INTDIR=$(BASEDIR)\omniORB2_static + +ALL : "$(OUTDIR)\naming.lib" + +CLEAN : + -@erase "$(INTDIR)\NamingSK.obj" + +"$(OUTDIR)" : + if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" + +CPP_PROJ=/nologo /MD /W3 /GX /Zi /D "WIN32" /D "_WINDOWS" /D\ + "__NT__" /D "_X86_" /D "_WINSTATIC" /D "NTArchitecture" /Fo"$(INTDIR)/" /c +LINK32_FLAGS=/lib /out:"$(OUTDIR)/naming.lib" +LINK32_OBJS= \ + "$(INTDIR)\NamingSK.obj" + +"$(OUTDIR)\naming.lib" : "$(OUTDIR)" $(DEF_FILE) $(LINK32_OBJS) + $(LINK32) $(LINK32_FLAGS) $(LINK32_OBJS) + !ELSEIF "$(CFG)" == "omniORB2_static" OUTDIR=$(BASEDIR)\omniORB2_static INTDIR=$(BASEDIR)\omniORB2_static -ALL : "$(BASEDIR)\omnithread_static\omnithread.lib" "$(OUTDIR)\omniORB2.lib" +ALL : "$(BASEDIR)\omnithread_static\omnithread.lib" "$(OUTDIR)\omniORB2.lib" \ +"$(OUTDIR)\naming.lib" CLEAN : -@erase "$(INTDIR)\constants.obj" @@ -316,7 +371,8 @@ -@erase "$(INTDIR)\initFile.obj" -@erase "$(INTDIR)\ior.obj" -@erase "$(INTDIR)\libcWrapper.obj" - -@erase "$(INTDIR)\NamingSK_NT.obj" + -@erase "$(INTDIR)\mbufferedStream.obj" + -@erase "$(INTDIR)\NamingSK.obj" -@erase "$(INTDIR)\nbufferedStream.obj" -@erase "$(INTDIR)\object.obj" -@erase "$(INTDIR)\objectKey.obj" @@ -331,8 +387,10 @@ "$(OUTDIR)" : if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" -CPP_PROJ=/nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ - "__NT__" /D "_X86_" /D "NTArchitecture" /D "_WINSTATIC" /Fo"$(INTDIR)/" /c +#CPP_PROJ=/nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ +#"__NT__" /D "_X86_" /D "NTArchitecture" /D "_WINSTATIC" /Fo"$(INTDIR)/" /c +CPP_PROJ=/nologo /MT /W3 /GX /Zi /D "WIN32" /D "_WINDOWS" /D\ +"__NT__" /D "_X86_" /D "NTArchitecture" /D "_WINSTATIC" /Fo"$(INTDIR)/" /c CPP_OBJS=$(BASEDIR)\omniORB2_static/ .cc{$(CPP_OBJS)}.obj: @@ -351,7 +409,7 @@ "$(INTDIR)\initFile.obj" \ "$(INTDIR)\ior.obj" \ "$(INTDIR)\libcWrapper.obj" \ - "$(INTDIR)\NamingSK_NT.obj" \ + "$(INTDIR)\mbufferedStream.obj" \ "$(INTDIR)\nbufferedStream.obj" \ "$(INTDIR)\object.obj" \ "$(INTDIR)\objectKey.obj" \ @@ -381,7 +439,9 @@ "$(OUTDIR)" : if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)" -CPP_PROJ=/nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ +#CPP_PROJ=/nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D\ +# "__NT__" /D "_X86_" /D "NTArchitecture" /D "_WINSTATIC" /Fo"$(INTDIR)/" /c +CPP_PROJ=/nologo /MT /W3 /GX /Zi /D "WIN32" /D "_WINDOWS" /D\ "__NT__" /D "_X86_" /D "NTArchitecture" /D "_WINSTATIC" /Fo"$(INTDIR)/" /c CPP_OBJS=$(BASEDIR)\omnithread_static/ @@ -417,8 +477,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -429,7 +487,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\objectRef.obj" : $(SOURCE) $(DEP_CPP_OBJEC) "$(INTDIR)" +"$(INTDIR)\objectRef.obj" : $(SOURCE) $(DEP_CPP_OBJEC) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -448,8 +506,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -460,7 +516,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\corbaBoa.obj" : $(SOURCE) $(DEP_CPP_CORBA) "$(INTDIR)" +"$(INTDIR)\corbaBoa.obj" : $(SOURCE) $(DEP_CPP_CORBA) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -479,8 +535,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -491,7 +545,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\corbaObject.obj" : $(SOURCE) $(DEP_CPP_CORBAO) "$(INTDIR)" +"$(INTDIR)\corbaObject.obj" : $(SOURCE) $(DEP_CPP_CORBAO) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -510,8 +564,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -522,7 +574,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\corbaOrb.obj" : $(SOURCE) $(DEP_CPP_CORBAOR) "$(INTDIR)" +"$(INTDIR)\corbaOrb.obj" : $(SOURCE) $(DEP_CPP_CORBAOR) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -541,8 +593,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -553,7 +603,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\corbaString.obj" : $(SOURCE) $(DEP_CPP_CORBAS) "$(INTDIR)" +"$(INTDIR)\corbaString.obj" : $(SOURCE) $(DEP_CPP_CORBAS) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -572,8 +622,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -584,7 +632,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\exception.obj" : $(SOURCE) $(DEP_CPP_EXCEP) "$(INTDIR)" +"$(INTDIR)\exception.obj" : $(SOURCE) $(DEP_CPP_EXCEP) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -603,8 +651,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -615,7 +661,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\giopClient.obj" : $(SOURCE) $(DEP_CPP_GIOPC) "$(INTDIR)" +"$(INTDIR)\giopClient.obj" : $(SOURCE) $(DEP_CPP_GIOPC) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -634,8 +680,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -646,7 +690,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\giopServer.obj" : $(SOURCE) $(DEP_CPP_GIOPS) "$(INTDIR)" +"$(INTDIR)\giopServer.obj" : $(SOURCE) $(DEP_CPP_GIOPS) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -665,8 +709,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -677,7 +719,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\initFile.obj" : $(SOURCE) $(DEP_CPP_INITF) "$(INTDIR)" +"$(INTDIR)\initFile.obj" : $(SOURCE) $(DEP_CPP_INITF) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -696,8 +738,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -708,7 +748,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\ior.obj" : $(SOURCE) $(DEP_CPP_IOR_C) "$(INTDIR)" +"$(INTDIR)\ior.obj" : $(SOURCE) $(DEP_CPP_IOR_C) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -728,8 +768,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -740,7 +778,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\libcWrapper.obj" : $(SOURCE) $(DEP_CPP_LIBCW) "$(INTDIR)" +"$(INTDIR)\libcWrapper.obj" : $(SOURCE) $(DEP_CPP_LIBCW) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -759,8 +797,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -771,7 +807,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\mbufferedStream.obj" : $(SOURCE) $(DEP_CPP_MBUFF) "$(INTDIR)" +"$(INTDIR)\mbufferedStream.obj" : $(SOURCE) $(DEP_CPP_MBUFF) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -779,7 +815,7 @@ ################################################################################ # Begin Source File -SOURCE=$(SRCDIR)\omniORB2\NamingSK_NT.cc +SOURCE=$(SRCDIR)\omniORB2\NamingSK.cc DEP_CPP_NAMIN=\ {$(INCLUDE)}"\omniORB2\bufferedStream.h"\ {$(INCLUDE)}"\omniORB2\CORBA.h"\ @@ -791,7 +827,6 @@ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -802,7 +837,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\NamingSK_NT.obj" : $(SOURCE) $(DEP_CPP_NAMIN) "$(INTDIR)" +"$(INTDIR)\NamingSK.obj" : $(SOURCE) $(DEP_CPP_NAMIN) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -821,8 +856,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -832,7 +865,7 @@ {$(INCLUDE)}"\omnithread.h"\ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\nbufferedStream.obj" : $(SOURCE) $(DEP_CPP_NBUFF) "$(INTDIR)" +"$(INTDIR)\nbufferedStream.obj" : $(SOURCE) $(DEP_CPP_NBUFF) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -853,8 +886,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -865,7 +896,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\unshared.obj" : $(SOURCE) $(DEP_CPP_UNSHA) "$(INTDIR)" +"$(INTDIR)\unshared.obj" : $(SOURCE) $(DEP_CPP_UNSHA) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -884,8 +915,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -896,7 +925,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\strand.obj" : $(SOURCE) $(DEP_CPP_STRAN) "$(INTDIR)" +"$(INTDIR)\strand.obj" : $(SOURCE) $(DEP_CPP_STRAN) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -917,8 +946,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -930,7 +957,7 @@ {$(INCLUDE)}"\sys\types.h"\ -"$(INTDIR)\tcpSocket_NT.obj" : $(SOURCE) $(DEP_CPP_TCPSO) "$(INTDIR)" +"$(INTDIR)\tcpSocket_NT.obj" : $(SOURCE) $(DEP_CPP_TCPSO) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -950,8 +977,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -964,7 +989,7 @@ {$(INCLUDE)}"\sys\types.h"\ -"$(INTDIR)\orb.obj" : $(SOURCE) $(DEP_CPP_ORB_C) "$(INTDIR)" +"$(INTDIR)\orb.obj" : $(SOURCE) $(DEP_CPP_ORB_C) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -983,8 +1008,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -997,7 +1020,7 @@ {$(INCLUDE)}"\sys\types.h"\ -"$(INTDIR)\objectKey.obj" : $(SOURCE) $(DEP_CPP_OBJECT) "$(INTDIR)" +"$(INTDIR)\objectKey.obj" : $(SOURCE) $(DEP_CPP_OBJECT) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -1016,8 +1039,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -1028,7 +1049,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\object.obj" : $(SOURCE) $(DEP_CPP_OBJECT_) "$(INTDIR)" +"$(INTDIR)\object.obj" : $(SOURCE) $(DEP_CPP_OBJECT_) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -1047,8 +1068,6 @@ {$(INCLUDE)}"\omniORB2\IIOP.h"\ {$(INCLUDE)}"\omniORB2\initFile.h"\ {$(INCLUDE)}"\omniORB2\IOP.h"\ - {$(INCLUDE)}"\omniORB2\Naming.hh"\ - {$(INCLUDE)}"\omniORB2\Naming_NT.hh"\ {$(INCLUDE)}"\omniORB2\omniInternal.h"\ {$(INCLUDE)}"\omniORB2\omniORB.h"\ {$(INCLUDE)}"\omniORB2\proxyFactory.h"\ @@ -1059,7 +1078,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\constants.obj" : $(SOURCE) $(DEP_CPP_CONST) "$(INTDIR)" +"$(INTDIR)\constants.obj" : $(SOURCE) $(DEP_CPP_CONST) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) @@ -1122,7 +1141,7 @@ {$(INCLUDE)}"\omnithread\nt.h"\ -"$(INTDIR)\nt.obj" : $(SOURCE) $(DEP_CPP_NT_CP) "$(INTDIR)" +"$(INTDIR)\nt.obj" : $(SOURCE) $(DEP_CPP_NT_CP) $(CPP) $(CPP_PROJ) /Tp$(SOURCE) diff -u /pub/corba/omniORB_2.2.0/build-win32/config.win32 build-win32/config.win32 --- /pub/corba/omniORB_2.2.0/build-win32/config.win32 Thu May 8 14:47:48 1997 +++ build-win32/config.win32 Mon Jun 23 17:15:00 1997 @@ -6,7 +6,7 @@ #Location of top-level directory containing omniORB2 installation (i.e. directory where omniORB2 # distribution was unpacked): #Note that this must be an absolute path. -BASEDIR = +BASEDIR = j:\omniorb_2.2.0 #Directory where omniORB2 should be installed Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From matthew_newhook@stratos.ca Thu Jul 3 19:17:25 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA11919; Thu, 3 Jul 1997 19:16:47 +0100 Received: (qmail 24955 invoked by alias); 3 Jul 1997 18:16:46 -0000 From: "Matthew Newhook" Received: (qmail 24946 invoked from network); 3 Jul 1997 18:16:44 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 3 Jul 1997 18:16:44 -0000 Received: (qmail 15836 invoked by uid 213); 3 Jul 1997 18:16:43 -0000 Message-ID: <19970703154643.CH57081@odin.stratos.ca> Date: Thu, 3 Jul 1997 15:46:43 -0230 To: omniorb-list@orl.co.uk Subject: mod to omnithread for NT. X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 3330 Status: OR Hi, What follows is a change to the omnithread library to allow an arbitrary thread-wrapper function to be setup. The function of this is to allow some per-thread stuff to be setup for each thread that is created. We use this to create objectstore thread handles under NT. This implementation is ONLY for NT also. If you use omni_thread::set_thread_wrapper under something other that NT you will get undefined symbols. Here is a sample that uses this new API: #include "corba/compat.h" #include "corba/cap/ostore.h" #include #include static void* thr_ret(void *arg) { struct thread_arg* thr_arg = (struct thread_arg*)arg; void* (*fn)(void*) = thr_arg->fn; void* the_arg = thr_arg->arg; delete thr_arg; void* rc; OS_ESTABLISH_FAULT_HANDLER rc = (*fn)(the_arg); OS_END_FAULT_HANDLER return rc; } /*static*/ void c_ostore_handler::ostore_init() { omni_thread::set_thread_wrapper(thr_ret); } ---- diffs follow ---- --- /pub/corba/omniORB_2.2.0/include/omnithread.h Tue May 6 13:26:59 1997 +++ include/omnithread.h Thu Jul 3 12:37:26 1997 @@ -242,6 +242,11 @@ // /////////////////////////////////////////////////////////////////////////// +struct thread_arg +{ + void* (*fn)(void*); + void* arg; +}; class _OMNITHREAD_NTDLL_ omni_thread { public: @@ -260,6 +265,10 @@ // been reclaimed (i.e. waiting to be joined). }; + static void set_thread_wrapper(void* (*fn)(void* arg)); + // set a up wrapper function that is called *before* + // the thread specific function is called. + // // Constructors set up the thread object but the thread won't start until // start() is called. The create method can be used to construct and start @@ -364,6 +373,8 @@ static omni_mutex* next_id_mutex; static int next_id; int _id; + + static void *(*fn_wrapper)(void* arg); void (*fn_void)(void*); void* (*fn_ret)(void*); --- /pub/corba/omniORB_2.2.0/src/lib/omnithread/nt.cc Tue May 6 13:12:54 1997 +++ src/lib/omnithread/nt.cc Thu Jul 3 12:42:49 1997 @@ -406,6 +406,8 @@ // Wrapper for thread creation. // +/*static*/ void *(*omni_thread::fn_wrapper)(void *(*fn_ret)(void*)) = 0; + extern "C" { // @@ -501,8 +503,19 @@ thread_arg = arg; detached = det; // may be altered in start_undetached() - handle = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)wrapper, + if (fn_wrapper == 0) + { + handle = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)wrapper, (LPVOID)this, CREATE_SUSPENDED, &nt_id); + } + else + { + struct thread_arg* thr_arg = new struct thread_arg; + thr_arg->fn = (void*(*)(void*))wrapper; + thr_arg->arg = this; + handle = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)fn_wrapper, + (LPVOID)thr_arg, CREATE_SUSPENDED, &nt_id); + } if (handle == NULL) { cerr << "omni_thread::common_constructor: CreateThread error " @@ -822,6 +835,11 @@ } } +/*static*/ void +omni_thread::set_thread_wrapper(void *(*fn)(void *)) +{ + fn_wrapper = fn; +} static void get_time_now(unsigned long* abs_sec, unsigned long* abs_nsec) { Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From ercanm@access.bel.alcatel.be Fri Jul 4 14:43:11 1997 Return-Path: Received: from btmplq.god.bel.alcatel.be by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA12532; Fri, 4 Jul 1997 14:40:39 +0100 Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id PAA07450 for ; Fri, 4 Jul 1997 15:40:06 +0200 Received: from btmpm3.access.bel.alcatel.be(138.203.151.4) by btmplq via smap (V1.3) id sma007433; Fri Jul 4 15:40:02 1997 Received: from btmp0e (btmp0e.access.bel.alcatel.be [138.203.151.117]) by btmpm3.access.bel.alcatel.be (8.6.5/8.6.12) with SMTP id PAA27800 for ; Fri, 4 Jul 1997 15:40:07 +0200 Sender: ercanm@access.bel.alcatel.be Message-ID: <33BCFCF3.6201DD56@access.bel.alcatel.be> Date: Fri, 04 Jul 1997 15:39:00 +0200 From: Melih Ercan xe44 9777 Organization: Alcatel Telecom X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omnithreads Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1639 Status: OR Hi, In his e-mail -Re:threading under omniORB)- Sai-Lai Lo wrote: **************************** At the server end ----------------- For *each* network connection, a thread blocks waiting for incoming requests. When a request message arrives, the thread partially unmarshal the request to the extend that it can identify which object the request is targeted. It then performs an upcall to the stub-level dispatch routine specific to the object. The dispatch routine further unmarshals the request and invokes on the specified operation. The dispatch routine then marshals the results and sends back the reply. On return from the dispatch routine, the cycle begins again with the thread blocks waiting for another incoming request. ***************************** THIS IS VISIBLE IN orb.cc FILE THAT THERE ARE 2 CLASSES WHICH CREATE THREADS: ->class tcpsock_rendezvouser:public omni_thread ->class strand_server:public omni_thread ***************************** At the client end ----------------- A thread calls on an operation of an object in a remote address space. This is routed to the proxy object in the local address space. Through the proxy object, the thread obtains *exclusive* access to a network connection, marshals in the arguments, sends off the request, and blocks waiting for the reply. After the reply arrives and is unmarshalled, the thread *release* the network connection and the operation is completed. .... ***************************** I can't see any derived class from omni_thread or any instantiation of omni_thread on the client side. Can anybody tell how a thread is created on client side? Regards, Melih. From A.Lehmkuehler@imech.com Mon Jul 7 10:24:09 1997 Return-Path: Received: from imech.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA06730; Mon, 7 Jul 1997 10:17:29 +0100 Received: from bohrarm (bohrarm.imech.uni-duisburg.de [134.91.124.62]) by imech.com with SMTP (8.7.5/8.7.3) id LAA00384 for ; Mon, 7 Jul 1997 11:17:23 +0200 (METDST) Message-ID: <33C0B437.5310@imech.com> Date: Mon, 07 Jul 1997 11:17:44 +0200 From: Andreas Lehmuehler Reply-To: A.Lehmkuehler@imech.com Organization: Imech GmbH X-Mailer: Mozilla 3.01 (WinNT; I) MIME-Version: 1.0 To: omniORB Mailinglist Subject: Using HPORB+-naming Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 566 Status: OR I've tried to use the HPORB+-namingservice (on HPUX 10.20) within the echo-example of omniORB2, but it didn't work. I've applied the namingservice-patch to omniORB2 (concerning the org.omg prefix), but I've got always an MARSHAL-exception in UnMarshalObjRef whenever I've tried to bind a new Namingcontext. Any expieriences with this combination? Andreas -- ================================================ Andreas Lehmkuehler EMail: A.Lehmkuehler@imech.com Institut fuer Mechatronik Tel.: 02841/101-262 ================================================ From szuber@man.poznan.pl Tue Jul 8 10:47:51 1997 Return-Path: Received: from rose.man.poznan.pl by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA21416; Tue, 8 Jul 1997 10:37:35 +0100 Received: from sybil (sybil.man.poznan.pl [150.254.170.11]) by rose.man.poznan.pl (8.8.5/8.8.5) with ESMTP id KAA11803 for ; Tue, 8 Jul 1997 10:36:40 +0200 (MESZ) Message-ID: <33E6E5C7.1E1E2B42@man.poznan.pl> Date: Tue, 05 Jul 1997 10:35:19 +0200 From: Sebastian Szuber Organization: PCSS X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: OmniORB mailing list Subject: IRIX port X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 299 Status: OR Hi, Did anyone compile OmniORB2 on SGI IRIX platform ? Please let me know. Sebastian -- /* * Sebastian Szuber * Poznan Supercomputing & Networking Center * * szuber@man.poznan.pl * http://www.man.poznan.pl/~sebach/ * * phone: (+48 61) 528-503 ext. 266, fax: (+48 61) 525-954 * */ From S.Lo@orl.co.uk Tue Jul 8 15:53:39 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA25482; Tue, 8 Jul 1997 15:44:16 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id PAA12892; Tue, 8 Jul 1997 15:44:13 +0100 Date: Tue, 8 Jul 1997 15:44:13 +0100 Message-Id: <199707081444.PAA12892@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: blobs across omniORB2 In-Reply-To: <852564C1.005BA330.00@ntserver2.dome.com> References: <852564C1.005BA330.00@ntserver2.dome.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: Fred_Stevens@dome.com Content-Length: 2397 Status: OR >>>>> Fred Stevens writes: > I'm putting together a test of throughput for passing blobs (on the order > of 10 MB) through omniorb. Can anyone give me any suggestions about how to > do this most efficiently? Currently I'm using the BOA interface to pass > sequences of octets. I would suggest using sequence, e.g.: // IDL interface ttcp { typedef sequence blob; oneway void dump(in blob data); }; > Is there a better way of doing this? Can I write to > a lower-level interface and perhaps avoid some of the data copying? May be you'll be surprised to know that omniORB is quite efficent in handling very long sequence of octets and of other primitive types. **There is no copying in the marshalling process.** In otherwords, the sequences are directly sent from and received into the sequences' buffers. ----------------------------------------------------------------------- With omniORB_2.2.0, you should be able to send blob up to around 256K and then you will get a marshalling exception. It is not a bug but a feature. omniORB sets a limit on the GIOP message size that it sends out and accept. The value can be obtained by calling omniORB::MaxMessageSize(). The default value is set at 256*1024. The exact value is somewhat arbitrary and can be overrided by setting the variable GIOP_Basetypes::max_giop_message_size. For example: GIOP_Basetypes::max_giop_message_size = 2048*1024; The reason such a limit exists is to provide some way to protect the server side from resource exhaustion. Think about the case when a rogue IIOP request message contains a sequence length field set to 2^31. I have tested omniORB against a test client that deliberately sent out randomly corrupted IIOP messages. Try that on Orbix and it died horribly. The current situation is not idea as the variable is inside a private interface and should not really be accessed in the applications. The default should be larger. In the next release, I'll add a set value function omniORB::MaxMssageSize(size_t sz); And a ORB init parameter -ORBmaxGIOPmessageSize. Regards, Sai-Lai Lo -- 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 S.Lo@orl.co.uk Tue Jul 8 15:54:33 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA25518; Tue, 8 Jul 1997 15:47:03 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id PAA12936; Tue, 8 Jul 1997 15:47:01 +0100 Date: Tue, 8 Jul 1997 15:47:01 +0100 Message-Id: <199707081447.PAA12936@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Debuging omniORB programs on Linux In-Reply-To: <33B28357.446B@prismtech.co.uk> References: <33B28357.446B@prismtech.co.uk> X-Mailer: VM 6.23 under Emacs 19.34.2 CC: Edward Scott From: Sai-Lai Lo Content-Length: 974 Status: OR >>>>> Edward Scott writes: > I am having problems using gdb on Linux (RedHat 4.2, i386) to debug > omniORB programs: breakpoints within threads other than the initial one > don't seem to work. I suspect the total lack of support for threading in > gdb for Linux... I haven't found a way to use gdb to debug linuxthread programs. One can step through the main thread but I can't stop a spawned thread at a specific breakpoint. I suspect that is because each thread under linuxthread looks every bit like a process to the kernel (but shares the code and data sections with others). Gdb is not written to cope with that. The writer of linuxthreads may be able to provide a better answer. Sai-Lai -- 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 S.Lo@orl.co.uk Tue Jul 8 16:03:28 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA25650; Tue, 8 Jul 1997 15:56:38 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id PAA13080; Tue, 8 Jul 1997 15:56:36 +0100 Date: Tue, 8 Jul 1997 15:56:36 +0100 Message-Id: <199707081456.PAA13080@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: omnithreads In-Reply-To: <33BCFCF3.6201DD56@access.bel.alcatel.be> References: <33BCFCF3.6201DD56@access.bel.alcatel.be> X-Mailer: VM 6.23 under Emacs 19.34.2 CC: Melih Ercan From: Sai-Lai Lo Content-Length: 1368 Status: OR >>>>> Melih Ercan xe44 9777 writes: > ***************************** > At the client end > ----------------- > A thread calls on an operation of an object in a remote address space. > This > is routed to the proxy object in the local address space. Through the > proxy > object, the thread obtains *exclusive* access to a network connection, > marshals in the arguments, sends off the request, and blocks waiting for > the > reply. After the reply arrives and is unmarshalled, the thread > *release* > the network connection and the operation is completed. .... > ***************************** > I can't see any derived class from omni_thread or any instantiation of > omni_thread > on the client side. > Can anybody tell how a thread is created on client side? On the client side, it is up to the application to create any threads it needs. The application can use the omnithread library to create the threads or to use the native thread APIs to do so. Using omnithread library ensures that your source code can be compiled unchanged on all the supported platforms. Regards, Sai-Lai Lo -- 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 S.Lo@orl.co.uk Tue Jul 8 17:00:17 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA26605; Tue, 8 Jul 1997 16:58:12 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id QAA13971; Tue, 8 Jul 1997 16:58:10 +0100 Date: Tue, 8 Jul 1997 16:58:10 +0100 Message-Id: <199707081558.QAA13971@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: omniorb2 on NT In-Reply-To: <199706260017.AA16993@stargate.compuware.com> References: <199706260017.AA16993@stargate.compuware.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: arao@compuware.com (Anant Rao) Content-Length: 1162 Status: OR >>>>> Anant Rao writes: > Hi, > I'm running my client as an NT v3.51 service and when it tries to > resolve the names, I get an exception "NO_RESOURCES". Running the client as an NT service... this is tricky... It looks like one or more of the following is not working: 1. The client program is not able to read the registry. 2. The client program is not able to read the configuration file. 3. The client program is not able to access the network. 4. .... something else that I don't have a clue. Are you using srvany? According to the documentation, one of the restriction enforced by NT on services is that the application can either be interactive (have a Console) or have network access but ***not both at the same time***. This may be the cause of your problem. Could someone with a better understanding of NT services provide a better explanation? Regards, Sai-Lai Lo -- 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 S.Lo@orl.co.uk Tue Jul 8 17:08:53 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA26799; Tue, 8 Jul 1997 17:08:27 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id RAA14118; Tue, 8 Jul 1997 17:08:24 +0100 Date: Tue, 8 Jul 1997 17:08:24 +0100 Message-Id: <199707081608.RAA14118@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Auto startup of servers In-Reply-To: <199706251746.AA04609@stargate.compuware.com> References: <199706251746.AA04609@stargate.compuware.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: arao@compuware.com (Anant Rao) Content-Length: 1020 Status: OR >>>>> Anant Rao writes: > Visibroker has a facility called, 'oad', that starts a server, if > not running, when a client makes a call to the server. This is > like a server-on-demand. > Is there such a facility in omniOrb also or any way we can > emulate it? This dynamic server activition policy is one of the four activition policies described in the Basic Object Adaptor specification. omniORB only supports the persistent server policy and not 'server-on-demand'. Having said that, all the APIs are there in omniORB to implement a daemon application to do what is provided by Visibroker's oad or Orbix's orbixd. If anyone is interested in implementing this daemon, please contact us for more information. Regards, Sai-Lai Lo -- 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 S.Lo@orl.co.uk Tue Jul 8 17:28:25 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA27043; Tue, 8 Jul 1997 17:27:49 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id RAA14413; Tue, 8 Jul 1997 17:27:37 +0100 Date: Tue, 8 Jul 1997 17:27:37 +0100 Message-Id: <199707081627.RAA14413@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: OmniORB2 for Windows NT/Alpha In-Reply-To: References: X-Mailer: VM 6.23 under Emacs 19.34.2 CC: econommx@rose-hulman.edu From: Sai-Lai Lo Content-Length: 1091 Status: OR >>>>> Matthew X Economou writes: > Is OmniORB2 available for Windows NT on the Digital Alpha > architecture? If not, do you know if OmniORB2 will run under > Digital's FX!32? We don't know if omniORB2 runs under FX!32 because we do not have any Alpha/NT box. Obviously, we have not done the port ourselves. However, I believe the port is most likely to be a straight forward compilation. Off hand I can think of two changes to make: 1. Replace all occurances of _X86_ in /build-win32/* to __alpha__. 2. Find out what is the size of a long and an int? With Digital's cxx a long is 64 bits and an int is 32 bits. You will have to specify this in /include/omniORB2/CORBA_sysdep.h If you are willing to have a go with it, please let us know. Regards, Sai-Lai Lo -- 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 arao@compuware.com Tue Jul 8 18:04:43 1997 Return-Path: Received: from stargate.compuware.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA27451; Tue, 8 Jul 1997 18:03:19 +0100 Received: by stargate.compuware.com id AA19816 (InterLock SMTP Gateway 3.0); Tue, 8 Jul 1997 13:03:12 -0400 Message-Id: <199707081703.AA19816@stargate.compuware.com> Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-2); Tue, 8 Jul 1997 13:03:12 -0400 From: arao@compuware.com (Anant Rao) Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-1); Tue, 8 Jul 1997 13:03:12 -0400 Date: Tue, 8 Jul 1997 10:02:49 -0700 To: S.Lo@orl.co.uk Subject: Re: Auto startup of servers Cc: omniorb-list@orl.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: 3Z7trVwXrscuhDZd9MWvxg== Content-Length: 466 Status: OR Sai-Lai, You answered all my questions at one shot. Thank you very much! I could solve this problem by using the registry, instead of storing the IOR in file. I don't why; looks like the NT service could access the registry , but not the file. I also would like to take this opportunity to congratulate you, Eoin (I hope I got the name right) and others in your team for doing one hell of a job developing a solid omniORB2. Very good job!! Thanks very much! From tjr@orl.co.uk Wed Jul 9 11:53:06 1997 Return-Path: Received: from pumpkin.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA07933; Wed, 9 Jul 1997 11:50:04 +0100 Received: from localhost by pumpkin.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id LAA19924; Wed, 9 Jul 1997 11:50:03 +0100 Message-Id: <199707091050.LAA19924@pumpkin.cam-orl.co.uk> To: omniorb-list@orl.co.uk cc: tjr@orl.co.uk, matthew_newhook@stratos.ca (Matthew Newhook) Subject: Re: mod to omnithread for NT. In-reply-to: Your message of "Thu, 03 Jul 1997 15:46:43 -0230." <19970703154643.CH57081@odin.stratos.ca> Date: Wed, 09 Jul 1997 11:49:48 +0100 From: Tristan Richardson Content-Length: 3187 Status: OR >>>>>> "Matthew Newhook" writes: > > Hi, > What follows is a change to the omnithread library to allow an arbitrary > thread-wrapper function to be setup. The function of this is to > allow some per-thread stuff to be setup for each thread that is > created. We use this to create objectstore thread handles under NT. > > This implementation is ONLY for NT also. If you use > omni_thread::set_thread_wrapper under something other that NT you > will get undefined symbols. > > Here is a sample that uses this new API: > > ... > > static void* > thr_ret(void *arg) > { > struct thread_arg* thr_arg = (struct thread_arg*)arg; > void* (*fn)(void*) = thr_arg->fn; > void* the_arg = thr_arg->arg; > delete thr_arg; > > void* rc; > OS_ESTABLISH_FAULT_HANDLER > rc = (*fn)(the_arg); > OS_END_FAULT_HANDLER > return rc; > } > > /*static*/ void > c_ostore_handler::ostore_init() > { > omni_thread::set_thread_wrapper(thr_ret); > } > This is unnecessary. The "wrapper" function is totally internal to the omnithread implementation. Matthew's example could be implemented more easily without his set_thread_wrapper stuff, e.g. void // or void* for undetached my_thread_fn(void* arg) { OS_ESTABLISH_FAULT_HANDLER ... do whatever ... OS_END_FAULT_HANDLER } where you create the thread with omni_thread::create(my_thread_fn,...). There is one problem with this approach (which may be why Matthew _thought_ he needed to change the "wrapper" function). If the thread calls omni_thread::exit(), rather than just getting to the end of my_thread_fn() then the "OS_END_FAULT_HANDLER" bit won't be invoked. This is true also of your set_thread_wrapper stuff. One way to get around this is to make sure that you always do the same "OS_END_FAULT_HANDLER" bit before calling omni_thread::exit(). A less error-prone solution is to define a class which derives from omni_thread, and to do your extra bits in the constructor and destructor of that derived class. The destructor of this class will be called even when the thread exits by calling omni_thread::exit(). However, note that the constructor of a derived class will be invoked by the thread that creates it, not by the created thread itself. If it is necessary for the created thread itself to call something, this must be done in the run() or run_undetached() member functions. The destructor will be called by the thread itself in the case of a detached thread, and by the joining thread in the case of an undetached thread. Tristan +--------------------------------------------------------------------+ | Tristan Richardson Email: tjr@orl.co.uk | | ORL Tel: +44 1223 343000 | | 24a Trumpington Street Fax: +44 1223 313542 | | Cambridge, CB2 1QA, UK WWW: http://www.orl.co.uk/ | +--------------------------------------------------------------------+ | ORL - The Olivetti & Oracle Research Laboratory | +--------------------------------------------------------------------+ From emil-gerhard.frank@sea.ericsson.se Wed Jul 9 13:17:13 1997 Return-Path: Received: from glacier.wise.edt.ericsson.se by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA09146; Wed, 9 Jul 1997 13:16:47 +0100 From: emil-gerhard.frank@sea.ericsson.se Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id OAA27421 for ; Wed, 9 Jul 1997 14:14:39 +0200 (MET DST) Received: from mira.sea.ericsson.se (root@mira.sea.ericsson.se [193.186.193.9]) by mailgate.ericsson.se (8.7.5/8.7.3/eri-0.9) with ESMTP id NAA21604 for ; Wed, 9 Jul 1997 13:11:17 +0200 (MET DST) Received: from localhost (root@localhost) by mira.sea.ericsson.se with SMTP (8.7.6/8.7.3) id OAA06441 for omniorb-list@orl.co.uk; Wed, 9 Jul 1997 14:13:56 +0200 (METDST) X-OpenMail-Hops: 1 Date: Wed, 9 Jul 97 14:13:44 +0200 Message-Id: Subject: Omniorb and Java IDL TO: omniorb-list@orl.co.uk CC: emil-gerhard.frank@sea.ericsson.se Encoding: 21 text Content-Length: 468 Status: OR Hi Can OnmiOrb cope with Java (especially with the JavaIDL from JavaSoft on NT 4.0 ?) Could the JavaToIDL compiler from JavaSoft JavaIDL be used with Omniorb ? With what Java technology else can OmniOrb deal ? Emil Frank Software Design Business Group Business Phone Business Unit Enterprise Networks Ericsson Austria AG Pottendorfer Strasse 25 - 27 A-1121 Vienna, Austria e-mail: Emil-Gerhard.Frank@sea.ericsson.se Tel.: +43-1-811 00-4795 Fax: +43-1-811 00-4686 From dlawson@teir.com Wed Jul 9 16:13:54 1997 Return-Path: Received: from teir.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA12039; Wed, 9 Jul 1997 16:12:43 +0100 Received: from r2d2.teir.com (r2d2.teir.com [206.151.82.74]) by teir.com (SMI-8.6/SMI-SVR4) with SMTP id LAA25215 for ; Wed, 9 Jul 1997 11:12:41 -0400 Received: from hector.teir.com (hector [206.152.90.27]) by r2d2.teir.com (SMI-8.6/SMI-SVR4) with SMTP id LAA18977 for ; Wed, 9 Jul 1997 11:12:41 -0400 Received: from dlawson-pc2.teir.com (dlawson-pc2.teir.com [206.152.90.73]) by hector.teir.com (SMI-8.6/SMI-SVR4) with SMTP id LAA19337 for ; Wed, 9 Jul 1997 11:12:39 -0400 Received: by dlawson-pc2.teir.com with Microsoft Mail id <01BC8C59.5353F380@dlawson-pc2.teir.com>; Wed, 9 Jul 1997 11:14:53 -0400 Message-ID: <01BC8C59.5353F380@dlawson-pc2.teir.com> From: "David B. Lawson" To: "'omniORB List'" Subject: A Novice question Date: Wed, 9 Jul 1997 11:14:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Length: 552 Status: OR I have a couple of simple questions: 1) How can I have one server object per client connection? I suspect = the answer is that I can't but I had to ask. The situation is that I'd = like to have one server object for each client. 2) How do I export more than 1 object from the server? Do I need to = start a separate thread for object being exported? The situation is = that I have an object A that has a method that returns an object B. Can = I just create a B and return it or does it need to be in another thread? Thanks for any help Dave From lars@ibp.de Wed Jul 9 17:05:36 1997 Return-Path: Received: from googleplex.ibp.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA12979; Wed, 9 Jul 1997 17:04:46 +0100 Received: (from lars@localhost) by googleplex.ibp.de (8.7.3/8.7.3) id SAA02266 for omniorb-list@orl.co.uk; Wed, 9 Jul 1997 18:04:30 +0200 (GMT+0200) Message-Id: <199707091604.SAA02266@googleplex.ibp.de> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) Received: by NeXT.Mailer (1.118.2) From: Lars Immisch Date: Wed, 9 Jul 97 18:04:27 +0200 To: omniorb-list@orl.co.uk Subject: Re: Omniorb and Java IDL References: Content-Length: 622 Status: OR > Can OnmiOrb cope with Java (especially with the JavaIDL from JavaSoft on NT > 4.0 ?) The Orbs interoperate, yes. There is one known snag that Naming.idl must be compiled with the #pragma prefix "omg.org" defined, otherwise the naming services will not work interoperably, see one of my previous mails. > Could the JavaToIDL compiler from JavaSoft JavaIDL be used with > Omniorb ? If JavaToIDL generates proper idl, then it should be no problem to generate C++ stubs with omniidl2 from them. You can also talk to your Java objects from an object living within omniORB2. Is this what you mean? Cheers, Lars From saintlou@tumbleweed.com Thu Jul 10 01:27:29 1997 Return-Path: Received: from tumbleweed1.tumbleweed.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id BAA18106; Thu, 10 Jul 1997 01:26:43 +0100 Received: from dev1 ([199.220.220.201]) by tumbleweed1.tumbleweed.com (post.office MTA v2.0 0813 ID# 0-11773) with ESMTP id AAA231 for ; Wed, 9 Jul 1997 17:24:30 -0700 Message-ID: <33C42C69.6934F320@tumbleweed.com> Date: Wed, 09 Jul 1997 17:27:21 -0700 From: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Organization: Tumbleweed Software Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: On the wire encryption X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 611 Status: OR Hello, I would like to implement on-the wire encryption with OmniORB. Does anyone know if ominiORB has filter-type capabilities (as in Orbix). Namely where a filter (function) can be interposed before or after marshalling of the message. Or does anyone in the ORL team could point me to the place where such capability could be added (by myself) ? Thanks a lot, -- Emmanuel R. Saint-Loubert saintlou@tumbleweed.com Tumbleweed Software Corp. http://www.tumbleweed.com 2010 Broadway Tel 415-569-3676 Redwood City, CA 94063 Fax 415-369-7197 From wenger@iam.unibe.ch Thu Jul 10 07:31:21 1997 Return-Path: Received: from arwen.unibe.ch by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id HAA21147; Thu, 10 Jul 1997 07:30:21 +0100 Received: from asterix (actually asterix.unibe.ch) by arwen with SMTP (PP); Thu, 10 Jul 1997 08:28:11 +0200 Received: from kira.unibe.ch by asterix (5.x/SMI-SVR4) id AA25475; Thu, 10 Jul 1997 08:28:56 +0200 Received: by kira.unibe.ch (5.x/SMI-SVR4) id AA23141; Thu, 10 Jul 1997 08:28:48 +0200 Date: Thu, 10 Jul 1997 08:28:48 +0200 From: wenger@iam.unibe.ch (Thomas Wenger) Message-Id: <9707100628.AA23141@kira.unibe.ch> To: emil-gerhard.frank@sea.ericsson.se Subject: Re: Omniorb and Java IDL Cc: omniorb-list@orl.co.uk X-Sun-Charset: US-ASCII Content-Length: 1183 Status: OR Emil asked: > Can OnmiOrb cope with Java (especially with the JavaIDL from JavaSoft > on NT 4.0 ?) Yes. Objects in Java/JavaIDL can operate with objects that are built in C++/omniORB perfectly. Up to this moment I could not use omniNames service in Java/JavaIDL for an unknown reason. I'm working on that. > Could the JavaToIDL compiler from JavaSoft JavaIDL be used with > Omniorb ? If this interface-translator generates proper IDL (what I suppose), then it can be used of course again as input to omniORBs IDL-compiler. > With what Java technology else can OmniOrb deal ? There are several Java ORBs, that should work with omniORB (not tested by me): - JacORB (FU Berlin), freeware - orbixWEB - and so on Have a nice day TOM -- ================================================================= Thomas Wenger wenger@iam.unibe.ch University: Institute of Computer Science and Applied Mathematics (IAM), Office 205 Neubrueckstr. 10, CH-3012 Bern +41 31 631 49 90 Private: Wydacherstrasse 4, CH-3113 Rubigen +41 31 721 41 18 ================================================================= From matthew_newhook@stratos.ca Thu Jul 10 13:37:26 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA25584; Thu, 10 Jul 1997 13:31:34 +0100 Received: (qmail 9110 invoked by alias); 10 Jul 1997 12:31:31 -0000 From: "Matthew Newhook" Received: (qmail 9097 invoked from network); 10 Jul 1997 12:31:29 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 10 Jul 1997 12:31:29 -0000 Received: (qmail 5971 invoked by uid 213); 10 Jul 1997 12:31:28 -0000 Message-ID: <19970710100128.BB61618@odin.stratos.ca> Date: Thu, 10 Jul 1997 10:01:28 -0230 To: omniorb-list@orl.co.uk Subject: heres an interesting bug. X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 800 Status: OR Hi, Consider the following scenario. You have two object references. Both will reside within the same process on the same machine. Object one is created an attempts to narrow an the second object. This narrow will fail. In looking through the code, it looks determines that the object will be local and then looks it up in the local object table. This, of course, fails since it doesn't yet exist, and we get an OBJECT_NOT_EXIST exception. I believe that this behaviour is incorrect. We should get this exception when an attempt is made to invoke a method on the object, and it doesn't yet exist. Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From valerie.castelain@sema.es Thu Jul 10 16:12:26 1997 Return-Path: Received: from vivaldi.sema.es by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA27607; Thu, 10 Jul 1997 16:10:16 +0100 Received: from ortega.sema.es ([193.148.251.251]) by vivaldi.sema.es (8.6.12/6.3.1) with SMTP id RAA14283 for ; Thu, 10 Jul 1997 17:10:23 +0100 Received: from valerie (fjavier) by ortega.sema.es (5.x/6.3.2) id AA17091 for omniorb-list@orl.co.uk; b Date: Thu, 10 Jul 1997 17:08:25 +0200 Message-Id: <1.5.4.16.19970710171033.2d5778bc@ortega> X-Sender: valerie@ortega X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: omniorb-list@orl.co.uk From: Valerie Castelain Subject: eg3 Content-Length: 958 Status: OR Hello, I'm beginning with OmniORB2 and I'm trying to compile the exanples with VC++ 4.2. * When compiling eg2_impl, eg2_clt, eg3_impl, eg3_clt, I have (several times) the warning message: warning C4101: 'ex' : unreferenced local variable * With eg3, the line: initServ =3D orb -> resolve_initial_references("NameService"); doesn't *work* (I did all the steps to generate an IOR and copy it in the key NAMESERVICE with regedit ... omniNames in itself looks like it works well: *Read log file successfully, Root context is ..., Checkpointing completed*). So what's the problem ? Thanks. ------------------------------------------------------------------------ Val=E9rie CASTELAIN e-mail: valerie.castelain@sema.es Tel: +34 1 3272828 =20 Fax: +34 1 7543252 Sema Group sae c/Albarracin 25 - 28037 Madrid (Spain) http://www.sema.com ------------------------------------------------------------------------ From saintlou@tumbleweed.com Thu Jul 10 18:01:16 1997 Return-Path: Received: from tumbleweed1.tumbleweed.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA28861; Thu, 10 Jul 1997 17:59:53 +0100 Received: from dev1 ([199.220.220.201]) by tumbleweed1.tumbleweed.com (post.office MTA v2.0 0813 ID# 0-11773) with ESMTP id AAA160 for ; Thu, 10 Jul 1997 09:57:31 -0700 Message-ID: <33C51527.7B210943@tumbleweed.com> Date: Thu, 10 Jul 1997 10:00:23 -0700 From: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Organization: Tumbleweed Software Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: Omniorb List Subject: Is OmniORB2 Tx enabled X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 386 Status: OR Hello, Is OmniORB Transaction-enabled ? Will it pass a transaction context as required by an OMG compliant Transaction Service ? Thanks, -- Emmanuel R. Saint-Loubert saintlou@tumbleweed.com Tumbleweed Software Corp. http://www.tumbleweed.com 2010 Broadway Tel 415-569-3676 Redwood City, CA 94063 Fax 415-369-7197 From S.Lo@orl.co.uk Thu Jul 10 21:56:07 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id VAA00911; Thu, 10 Jul 1997 21:44:54 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id VAA06322; Thu, 10 Jul 1997 21:44:48 +0100 Date: Thu, 10 Jul 1997 21:44:48 +0100 Message-Id: <199707102044.VAA06322@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Possible recovery strategies to handle transient COMM_FAILURE (was Re: problem with dying server) In-Reply-To: <19970626134014.UX44182@odin.stratos.ca> References: <19970626134014.UX44182@odin.stratos.ca> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 5268 Status: OR Sorry for being a bit long-winded. I'm describing below a possible enhancement to omniORB. It may be of interest to you. Comments are welcomed. >>>>> Matthew Newhook writes: > I have a server that always uses the same object key, and port (ie. it's > a persistent server) - server A. I have another persistent server B > that uses server A. > If server A dies, and is restarted it seems that the Strand in server B > still points to the old connection that was established with server A. > Of course, server B attempts to invoke methods on A which fail 'cause > the socket is bad (COMM_FAILURE). The next attempt re-establishes > the connection (because the strand is missing). It seems to me that > a COMM_FAILURE should result in *one* reconnection attempt before > resulting in a total COMM_FAILURE. Your analysis is correct, the current implementation does throw a COMM_FAILURE under the condition you described. This issue was also raised by Hans Huebner earlier on this mailing list. While the CORBA spec. does not mandate any error handling strategy, I agree that the ORB should not just give up when a cached connection is broken. ------------------------------------------------ There are a number of possible improvements: 1. When a cached connection is broken, throw a TRANSIENT exception. Reconnection will be attempted when the application repeats the call. If an attempt to connect fails or the call is the first one to use a connection that breaks, then a COMM_FAILURE exception is raised. 2. When a cached connection is broken, retry the call *once* and throw a COMM_FAILURE if either the reconnection attempt fails or the connection is again broken during the call. 3. Same as 2 but retry a few more times/indefinitely instead of just *once*. 4. A variation of 1 that I will explain below. ------------------------------------------------ There is a related issue with *location forwarded objects*, i.e. objects that have been redirected by IIOP LOCATION_FORWARD messages. If a call to a location forwarded object fails because the connection to it is broken, instead of COMM_FAILURE, the current implementation throws a TRANSIENT exception. A COMM_FAILURE exception is not appropriate in this case because the original location, given in the object's IOR, should be taken as the true home of the object. The forwarded location is only a hint. If it fails, it should be dropped and the original re-used. Then why doesn't the ORB just retry transparently using the original, instead of throwing a TRANSIENT? Well, if the ORB retries, there is a possibility that it will receive the same LOCATION_FORWARD message from the home location of the object and redirects the call to the same forwarded location, and fails again and repeats the cycle again and again... This is the reason why the current implementation throws a TRANSIENT exception and the application can retry if it wants to. If it does so, the object's home location will be contacted. ----------------------------------------------------- I think in most applications, it is too troublesome to write code to catch the TRANSIENT exception and to relaunch the call again. Typically, one would retry up to a certain number of times, possibly with increasing delay between each call, and if in the end none of the attempts succeed, a COMM_FAILURE exception is thrown. May be there are also situations in which one does not want to retry or one wants to retry forever. Therefore, I'm thinking of enhancing the implementation to allow the application to install a handler for TRANSIENT exception. The ORB let the handler decides when to perform a retry. The handler's signature looks like this: typedef void (*transient_handler_t)(CORBA::ULong n_retries, const CORBA::TRANSIENT& ex) throw (CORBA::SystemException); The new scheme works as follows: The stub code catches the TRANSIENT exception and calls the transient_handler with the exception value and the number of retries attempted as arguments. The handler can return normally, in which case the stub code will retry the call again. Alternatively, the handler can throw a System Exception and this will be propagated out of the stub code into the application code. The handler is installed by either of these functions: void omniORB::install_transient_handler(transient_handler_t fn); void omniORB::install_transient_handler(CORBA::Object_ptr obj, transient_handler_t fn); The first one installs a handler for all object references. The second applies to individual object reference. --------------------------------------------------------------- Coming back to the 4th alternative to handle broken cache connection, I suggest treating this as a TRANSIENT exception and based on the policy determined by the transient_handler, retry the call transparently. Sai-Lai Lo -- 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 S.Lo@orl.co.uk Fri Jul 11 15:13:33 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA10641; Fri, 11 Jul 1997 15:13:10 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id PAA14215; Fri, 11 Jul 1997 15:13:02 +0100 Date: Fri, 11 Jul 1997 15:13:02 +0100 Message-Id: <199707111413.PAA14215@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: Is OmniORB2 Tx enabled In-Reply-To: <33C51527.7B210943@tumbleweed.com> References: <33C51527.7B210943@tumbleweed.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Content-Length: 629 Status: OR >>>>> Emmanuel Saint-Loubert writes: > Is OmniORB Transaction-enabled ? No. > Will it pass a transaction context as required by an OMG compliant > Transaction Service ? No. As I understand it, to support the current Transaction Service spec, GIOP v1.1 and IIOP v.1.1 are required. We are still at GIOP v1.0 and IIOP v1.0. Regards, Sai-Lai Lo -- 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 S.Lo@orl.co.uk Fri Jul 11 15:13:29 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA10525; Fri, 11 Jul 1997 15:04:29 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id PAA14091; Fri, 11 Jul 1997 15:04:21 +0100 Date: Fri, 11 Jul 1997 15:04:21 +0100 Message-Id: <199707111404.PAA14091@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: On the wire encryption In-Reply-To: <33C42C69.6934F320@tumbleweed.com> References: <33C42C69.6934F320@tumbleweed.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Content-Length: 1992 Status: OR >>>>> Emmanuel Saint-Loubert writes: > I would like to implement on-the wire encryption with OmniORB. Does > anyone know if ominiORB has filter-type capabilities (as in Orbix). > Namely where a filter (function) can be interposed before or after > marshalling of the message. > Or does anyone in the ORL team could point me to the place where such > capability could be added (by myself) ? omniORB does not have a mechanism to insert Orbix-style pre/post marshalling filters. While it seems like a reasonable way to insert call tracing, allowing the application to insert/remove application specific data on the wire using this mechanism, IMHO, is an invitation to *violate* the on-the-wire protocol. I guess you are thinking of using the said filter to encrypt the marshalled data before sending it onto the wire and to decrypt the data at the other end before unmarshalling. This is not practical because omniORB does not always hold the complete request/reply message in its marshalling buffer. In fact, for a very large message, part of the message may have been sent onto the wire while the rest is still being marshalled. I'm not going into the details here but suffice to say the marshalling mechanism in omniORB is geared towards efficent bulk data transfer and minimal buffer space requirement. It seems to me the best place to insert on-the-wire encryption is at the socket level. The idea is to intercept the send() and recv() calls and encrypt or decrypt the data. You can take a look at src/lib/omniORB/tcpSocket_UNIX.cc and locate where send() and recv() are called. The harder part is how you are going to exchange encryption keys and to assiciate a key to a connection. Regards, Sai-Lai Lo -- 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 hans@Berlin.IRS.DE Fri Jul 11 16:29:32 1997 Return-Path: Received: from unlisys.unlisys.NET by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA11498; Fri, 11 Jul 1997 16:27:32 +0100 Received: by unlisys.unlisys.NET (Smail3.2) from castle.Berlin.IRS.DE (195.21.242.203) with smtp id ; Fri, 11 Jul 1997 17:26:50 +0200 (MET DST) Received: from localhost by castle.Berlin.IRS.DE with smtp (Smail3.1.29.1 #4) id m0wmehp-00028fC; Fri, 11 Jul 97 14:21 MET DST Date: Fri, 11 Jul 1997 14:21:49 +0200 (MET DST) From: Hans Huebner X-Sender: hans@castle.irs.de Reply-To: hh@Berlin.SNAFU.DE To: Sai-Lai Lo cc: omniorb-list@orl.co.uk, Matthew Newhook Subject: Re: Possible recovery strategies to handle transient COMM_FAILURE (was Re: problem with dying server) In-Reply-To: <199707102044.VAA06322@santaka.cam-orl.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1120 Status: OR On Thu, 10 Jul 1997, Sai-Lai Lo wrote: > Therefore, I'm thinking of enhancing the implementation to allow the > application to install a handler for TRANSIENT exception. The ORB let the > handler decides when to perform a retry. The mechanism described looks quite reasonable to me. Retries can't be transparently controlled by the ORB, because it can not decide whether the call was actually completed by the server in the first run. The application program should be forced to implement proper transaction handling, which, for now, means that the application must have some control over the retry strategy used. For some applications it is preferable not to retry a failed call at all and fall back to a recovery mechanism whenever a COMM_FAILURE is detected. Just to mention it again: A mechanism to properly shut down a server ORB (and orderly disconnecting all clients) is also badly needed. This will help to avoid many COMM_FAILURE exceptions, thus greatly simplifying real-world systems where server processes need to be independently restartable. -Hans Hans.Huebner@berlin.snafu.de +49-177-512 1024 From hjkamm@compuserve.com Mon Jul 14 18:26:45 1997 Return-Path: Received: from dub-img-4.compuserve.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA16462; Mon, 14 Jul 1997 18:03:19 +0100 Received: (from mailgate@localhost) by dub-img-4.compuserve.com (8.8.6/8.8.6/2.1) id NAA14147 for omniorb-list@orl.co.uk; Mon, 14 Jul 1997 13:03:16 -0400 (EDT) Date: Mon, 14 Jul 1997 13:02:39 -0400 From: Hans-Jörg Kamm Subject: COSS - Event, Security, Licensing, Transaction To: Mailing list Message-ID: <199707141302_MC2-1AD1-46D5@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Length: 396 Status: OR hello, we would like to use OmniORB to build up a small project. The goal of the= project is to "evaluate" CORBA as a substitute to our proprietary middleware. My question is: will any (or all) of the following COS be implemented in future or are there people out there who would like to do so? 1. Event Service 2. Security Service 3. Licensing Service 4. Transaction Thx, Hans-J=F6rg Kamm From renzo.tomaselli@tecnotp.inet.it Tue Jul 15 12:34:28 1997 Return-Path: Received: from venere.inet.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA04064; Tue, 15 Jul 1997 12:11:52 +0100 Received: (from trusted@localhost) by venere.inet.it (8.6.10/8.6.10) id NAA135932 for ; Tue, 15 Jul 1997 13:11:40 +0200 Message-Id: <199707151111.NAA135932@venere.inet.it> Received: from tecnotp.inet.it(194.20.15.148) by venere.inet.it via I-SMTP id queue/s-194.20.15.148-oXJBqb; Tue Jul 15 13:11:37 1997 From: "Renzo Tomaselli" To: Subject: using thread unsafe third party code Date: Tue, 15 Jul 1997 13:15:02 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 1667 Status: OR Hi people, a couple of questions for you: 1. I'm collecting comments about how to setup a server architecture made up of mixed, thread-safe and unsafe services. Thinking of objects clustered into dynamically loadable services (such as DLLs on NT), a very basic bootstrap ORB might load them on demand (such as local/remote configurations requests); this loading interface should be embedded into the ORB, like the actual OmniORB nameservice. This is the easy part, the real troubles come out whenever a requested service links to thread-unsafe third party software, such as a RDBMS library; in this case the implementation might wrap each call into lock/unlock mutex brackets (strict sequentialization), or resort to the old multiprocessing scheme (such as ftpd). The latter case would require the ORB to spawn processes instead of threads, in order to avoid doubling the marshalling toward a more internal, implementation dependent interprocess comm. layer; however this solution would be tightly coupled to the idea of "connection". 2. (for the developers); the implementations of "any" is of a fundamental importance for implementing almost any COSS service. Any scheduling for related OmniORB support ? (I'm not pushing anyone, just wanting to know :-) Any comment is more than welcome, Renzo Tomaselli --------------------------------------------------------------------------- TecnoTP s.n.c. Special Information System Design Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY Tel. +39 461 773164 Fax. +39 461 773180 e-mail: renzo.tomaselli@tecnotp.inet.it --------------------------------------------------------------------------- From S.Lo@orl.co.uk Tue Jul 15 14:56:11 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA05800; Tue, 15 Jul 1997 14:54:55 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id OAA14430; Tue, 15 Jul 1997 14:54:53 +0100 Date: Tue, 15 Jul 1997 14:54:53 +0100 Message-Id: <199707151354.OAA14430@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lars Jarnbo Pedersen Subject: Re: omniORB questions In-Reply-To: <33CB86A3@wk06.Copenhagen.NCR.COM> References: <33CB86A3@wk06.Copenhagen.NCR.COM> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: omniorb-list@orl.co.uk Content-Length: 2623 Status: OR Thanks for your message. >>>>> Lars Jarnbo Pedersen writes: > I'm using omniORB to gain some insights on basic CORBA ORB > infrastructure. After studying your very well structured and modular ORB > architecture I'm considering using omniORB for some prototyping > projects. But before I start my internal "lobbying" I have a couple of > questions: > 1) My understanding of the GNU General Public License vs GNU Library > General Public License in omniORB is that we can write CORBA programs > link it with omniORB.lib and sell it without having to make our source > available under GPL (because omniORB.lib is under the GNU library > license). However if we modify or extend the ORB core we have to provide > our source modification under GPL. Is this a correct understanding? This is correct. > 2) On your web page and in your README files you claim that support for > Typecode, Any, DII and DSI will be included in a version to be released > shortly. Can you comment on the progress of this release? Typecode and Any is being worked on right now. May be a couple of months from a solid public release. We have not started on DII and DSI, it is not a major piece of work once Typecode and Any are done. > 3) The last question is a more technical one. You write that your next > release will include DII, but in your README files you also state that > you have no plan of supporting an Interface Repository. My understanding > of the CORBA specification is that the Interface Repository is needed to > discover the interface of an "unknown" object. What benefits do you see > by providing DII without an Interface Repository? It depends on what one uses DII for. Even without IR, DII is useful to program CORBA calls on the fly, e.g. in scripting languages, once the interface to the object is known. In these applications, typically one has to verify that the object one wants to communicate does support the interface one has in mind. To do so, one does not need the IR. Instead, the object can be contacted directly using the _is_a operation to obtain an authoritative answer about the object's interface. IMHO, interface browsing is one application that requires an IR. In our own application domain, this is lower in priority than other features we have to put in place. Regards, Sai-Lai Lo -- 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 S.Lo@orl.co.uk Tue Jul 15 15:00:29 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA05914; Tue, 15 Jul 1997 15:00:18 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id PAA14557; Tue, 15 Jul 1997 15:00:16 +0100 Date: Tue, 15 Jul 1997 15:00:16 +0100 Message-Id: <199707151400.PAA14557@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: omniorb-list@orl.co.uk Subject: Re: COSS - Event, Security, Licensing, Transaction In-Reply-To: <199707141302_MC2-1AD1-46D5@compuserve.com> References: <199707141302_MC2-1AD1-46D5@compuserve.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo CC: Hans-Jörg Kamm Content-Transfer-Encoding: quoted-printable Content-Length: 619 Status: OR At ORL, we have no plan to implement the COS services you mentioned. However, we'll assist anyone who is willing to implement any= of these services and distribute it under GPL. Regards, Sai-Lai Lo >>>>> Hans-J=F6rg Kamm writes: > we would like to use OmniORB to build up a small project. The goal of= the > project is to "evaluate" CORBA as a substitute to our proprietary > middleware. > My question is: will any (or all) of the following COS be implemented= in > future or are there people out there who would like to do so? > 1. Event Service > 2. Security Service > 3. Licensing Service > 4. Transaction From israel@his.com Tue Jul 15 17:14:38 1997 Return-Path: Received: from ers.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA07751; Tue, 15 Jul 1997 17:13:20 +0100 Received: from desoto.ers.com ([192.168.0.21]) by gateway.ers.com with SMTP id <27780>; Tue, 15 Jul 1997 12:12:38 -0400 Received: by desoto.ers.com (SMI-8.6/SMI-SVR4) id MAA08851; Tue, 15 Jul 1997 12:10:23 -0400 Date: Tue, 15 Jul 1997 12:10:23 -0400 Message-Id: <199707151610.MAA08851@desoto.ers.com> From: Bruce Israel To: omniorb-list@orl.co.uk Subject: Re: omniORB questions Content-Length: 323 Status: OR I recall that it was mentioned that people have used omniORB with OrbixWeb. I have an application that's currently OrbixWeb to Orbix on solaris, but I need to port the server to Linux. I was going to switch the server code to omniORB. Does someone have an example of an OrbixWeb to omniORB application? Thanks. Bruce From hjkamm@compuserve.com Wed Jul 16 09:42:53 1997 Return-Path: Received: from dub-img-4.compuserve.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id JAA15693; Wed, 16 Jul 1997 09:41:29 +0100 Received: (from mailgate@localhost) by dub-img-4.compuserve.com (8.8.6/8.8.6/2.1) id EAA02247 for omniorb-list@orl.co.uk; Wed, 16 Jul 1997 04:41:28 -0400 (EDT) Date: Wed, 16 Jul 1997 04:40:55 -0400 From: Hans-Joerg Kamm Subject: HP-UX Port To: orb-mlist Message-ID: <199707160441_MC2-1AF2-ACD6@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Length: 203 Status: OR Does anyone know about omniORB2 under HP-UX 10.x (we're using HP-UX B 10.= 20 A)? If so: where can I get the correct makefiles/configfiles or how can I= do it on my own? Thx in advance, Hans-Joerg Kamm From matthew_newhook@stratos.ca Wed Jul 16 17:38:36 1997 Return-Path: Received: from lothar.stratos.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA21584; Wed, 16 Jul 1997 17:29:54 +0100 Received: (qmail 3552 invoked by alias); 16 Jul 1997 16:29:44 -0000 From: "Matthew Newhook" Received: (qmail 3543 invoked from network); 16 Jul 1997 16:29:42 -0000 Received: from odin.stratos.ca (198.165.24.17) by lothar.stratos.ca with SMTP; 16 Jul 1997 16:29:42 -0000 Received: (qmail 16174 invoked by uid 213); 16 Jul 1997 16:29:42 -0000 Message-ID: <19970716135941.RC32153@odin.stratos.ca> Date: Wed, 16 Jul 1997 13:59:41 -0230 To: omniorb-list@orl.co.uk Subject: object deactivation X-Mailer: Mutt 0.60 Mime-Version: 1.0 Reply-to: matthew_newhook@stratos.ca (Matthew Newhook) Content-Length: 685 Status: OR Hi, There doesn't seem to be any way of releasing an implementation object in a application without releasing all references to that object within the same application. This is quite a problem. I would expect to be able to tell the ORB that the object is no longer active, and then delete the implementation object. Any further calls to that object would result either in a TRANSIENT or OBJECT_NOT_EXIST exception, until the object is reactivated. Any ideas on how to proceed in this area? Matthew -- Matthew Newhook. matthew_newhook@stratos.ca, http://www.engr.mun.ca/~matthew Software Designer, Stratos Network Research. w: (709) 364-5950, h: (709)-745-4346 From S.Lo@orl.co.uk Thu Jul 17 14:08:50 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA02803; Thu, 17 Jul 1997 14:05:22 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id OAA02745; Thu, 17 Jul 1997 14:05:21 +0100 Date: Thu, 17 Jul 1997 14:05:21 +0100 Message-Id: <199707171305.OAA02745@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: object deactivation In-Reply-To: <19970716135941.RC32153@odin.stratos.ca> References: <19970716135941.RC32153@odin.stratos.ca> X-Mailer: VM 6.23 under Emacs 19.34.2 CC: matthew_newhook@stratos.ca (Matthew Newhook) From: Sai-Lai Lo Content-Length: 2776 Status: OR >>>>> Matthew Newhook writes: > There doesn't seem to be any way of releasing an implementation object > in a application without releasing all references to that object > within the same application. This is quite a problem. I would > expect to be able to tell the ORB that the object is no longer > active, and then delete the implementation object. Any further calls > to that object would result either in a TRANSIENT or OBJECT_NOT_EXIST > exception, until the object is reactivated. > Any ideas on how to proceed in this area? Your description is correct and is documented in the omniORB2 user's guide (2.7.4 Object disposal). To obtain the behaviour your want, an additional level of indirection is needed. Essentially the real implementation cannot directly inherits from the implementation skeleton. Instead, a new class has to be introduced to link between the skeleton and the real implementation. I shall use the Echo example to illustrate how I think one should proceed: The example only shows how one can implement _dispose() that will guarantee to have called the dtor of the real implementation when it returns. Further calls to the object, local or remote would result in OBJECT_NOT_EXIST exception. The principle is the same to implement an object that can be reactivated, only the details differ. // Real implmentation of echo class Echo_realImpl { public: char* echoString(const char* mesg); }; class Echo_i : public _sk_Echo { public: Echo_i(Echo_realImpl* p) : realImpl_ptr(p), _v(&m), _is_disposed(0), _n_concurrency(0) {} char* echoString(const char*mesg) { assertObjIsReady _a; return realImpl_ptr->echoString(mesg); } void _dispose() { _m.lock(); if (!_is_disposed) { _is_disposed = 1; while (_n_concurrency) { _v.wait(); } delete realImpl_ptr; _m.unlock(); _sk_Echo::_dispose(); } else { _m.unlock(); } return; } private: Echo_realImpl* realImpl_ptr; omni_mutex _m; omni_condition _v; CORBA::Boolean _is_disposed; CORBA::ULong _n_concurrency; class assertObjIsReady { public: assertObjIsReady() { _m.lock(); if (_is_disposed) { _m.unlock(); throw CORBA::OBJECT_NOT_EXIST(0,CORBA::COMPLETED_NO); } else { _n_concurrency++; _m.unlock(); } } ~assertObjIsReady() { _m.lock(); _n_concurrency--; if (_is_disposed) { _v.signal(); } _m.unlock(); } }; Echo_i(); // Do not allow the use of default ctor }; From S.Lo@orl.co.uk Thu Jul 17 14:21:58 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA03013; Thu, 17 Jul 1997 14:21:00 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id OAA02969; Thu, 17 Jul 1997 14:21:00 +0100 Date: Thu, 17 Jul 1997 14:21:00 +0100 Message-Id: <199707171321.OAA02969@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk CC: Hans-Joerg Kamm Subject: Re: HP-UX Port In-Reply-To: <199707160441_MC2-1AF2-ACD6@compuserve.com> References: <199707160441_MC2-1AF2-ACD6@compuserve.com> X-Mailer: VM 6.23 under Emacs 19.34.2 From: Sai-Lai Lo Content-Length: 1333 Status: OR >>>>> Hans-Joerg Kamm writes: > Does anyone know about omniORB2 under HP-UX 10.x (we're using HP-UX B 10.20 > A)? If so: where can I get the correct makefiles/configfiles or how can I > do it on my own? Several people have asked this question on the list and I have not heard from anyone directly that a port is in progress. If you are interested to give it a go, several points to note: 1. AFSIK, the pthread package that comes with HP-UX 10.x implements the rather dated pthread specification (draft version 4). This is the same draft version implemented by the pthread package on Digital Unix 3.2. You have to specify this in the make configuration file for HPUX. Consult /mk/alpha_osf1_3.2.mk for an example on how this is done. 2. The driver code in omniidl2 may need some attention. /src/tool/omniidl2/driver/{drv_fork,drv_preproc}.cc I'm not sure the code is using the fork() and wait() call on hpux correctly. 3. Use aC++. 4. Read the file /PORTING. Good luck. Sai-Lai Lo -- 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 emil-gerhard.frank@sea.ericsson.se Thu Jul 17 14:40:54 1997 Return-Path: Received: from glacier.wise.edt.ericsson.se by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA03278; Thu, 17 Jul 1997 14:40:11 +0100 From: emil-gerhard.frank@sea.ericsson.se Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by glacier.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-0.9) with ESMTP id PAA21943 for ; Thu, 17 Jul 1997 15:40:05 +0200 (MET DST) Received: from mira.sea.ericsson.se (root@mira.sea.ericsson.se [193.186.193.9]) by mailgate.ericsson.se (8.7.5/8.7.3/eri-0.9) with ESMTP id OAA09133 for ; Thu, 17 Jul 1997 14:36:39 +0200 (MET DST) Received: from localhost (root@localhost) by mira.sea.ericsson.se with SMTP (8.7.6/8.7.3) id PAA06202 for omniorb-list@orl.co.uk; Thu, 17 Jul 1997 15:39:46 +0200 (METDST) X-OpenMail-Hops: 1 Date: Thu, 17 Jul 97 15:39:38 +0200 Message-Id: Subject: OmniOrb2 on VxWorks TO: omniorb-list@orl.co.uk Encoding: 8 text Content-Length: 154 Status: OR Hi, I need OmniOrb2 for VxWorks platform ? Has anybody already done the port ? Emil Frank, Ericsson emil-gerhard.frank@sea.ericsson.se +43-1-81100-4795 From jrc@art.co.uk Thu Jul 17 15:44:49 1997 Return-Path: Received: from threebti.demon.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA04258; Thu, 17 Jul 1997 15:43:32 +0100 Received: (qmail 24587 invoked from smtpd); 17 Jul 1997 14:42:52 -0000 Received: from bragg.art.co.uk (root@192.168.1.129) by stefan.art.co.uk with SMTP; 17 Jul 1997 14:42:52 -0000 Received: from perot (perot.art.co.uk [192.168.1.194]) by bragg.art.co.uk (8.8.5/8.7.3) with SMTP id PAA24533; Thu, 17 Jul 1997 15:45:30 +0100 Sender: jrc@art.co.uk Message-ID: <33CE3009.79CBEB41@art.co.uk> Date: Thu, 17 Jul 1997 15:45:29 +0100 From: John Connett Organization: Advanced Rendering Technology X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: OmniORB mailing list CC: jrc@skylon.demon.co.uk Subject: VisiBroker for Java 2.5 client to omniORB? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2366 Status: OR As a first step towards teaching myself a bit more about CORBA and Java I tried to translate eg2_clt from C++ to Java. Unfortunately, my attempt blows up almost immediately somewhere deep down in the depths of code called from string_to_object. I'm using omniORB_2.2.0 running eg2_impl as the server, the demo version of vbj_2.5 for Java stubs and support, and jdk-1.1.1v3-2.i386.rpm as the source of the Java language tools. All of it running on Redhat Linux 4.2 on an Intel Pentium. The C++ version of eg2_clt responds as expected when given the IOR emitted by eg2_impl. Here's enough Java to demonstrate the problem: public class eg2_clt { public static void main(String args[]) { try { // Initialize the ORB. org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(); org.omg.CORBA.Object obj = orb.string_to_object(args[0]); System.out.println("Contacted object: " + obj); } catch(org.omg.CORBA.SystemException e) { System.err.println(e); } } } [jrc@skylon echo]$ javac eg2_clt.java [jrc@skylon echo]$ java eg2_clt 'IOR:01cc00400d00000049444c3a4563686f3a312e3000ab0d08010000000000000024000000010100000a0000003132372e302e302e31000a040c00000033cddc432c48c19e00000001' org.omg.CORBA.INTERNAL[completed=MAYBE, reason=Invalid delimiter "^@"] at com.visigenic.vbroker.ds.IStream.read_Resource(IStream.java:131) at com.visigenic.vbroker.ds.DSUser.doInvoke(DSUser.java:196) at com.visigenic.vbroker.ds.DSUser.invoke(DSUser.java:216) at com.visigenic.vbroker.ds.DSUser.login(DSUser.java:251) at com.visigenic.vbroker.CORBA.ORB.contactLocator(ORB.java:451) at com.visigenic.vbroker.CORBA.ORB.locator(ORB.java:468) at com.visigenic.vbroker.CORBA.ORB.iorToObject(ORB.java:1139) at com.visigenic.vbroker.CORBA.GiopInputStreamImpl.read_Object(GiopInputStreamImpl.java:57) at com.visigenic.vbroker.CORBA.dynamic.OrbHelperImpl.string_to_object(OrbHelperImpl.java:286) at com.visigenic.vbroker.CORBA.ORB.string_to_object(ORB.java:191) at eg2_clt.main(eg2_clt.java:17) Can anyone point me towards a solution? If I can't get it to work with vbj_2.5, I'll wait for Jorba (http://www.progsoc.uts.edu.au/~raz/jorba/) to be released and give that a try ... Thanks in anticipation -- John Connett Home: jrc@skylon.demon.co.uk Work: jrc@art.co.uk From alex@ipi.ac.ru Mon Jul 21 16:33:49 1997 Return-Path: Received: from demos.ipi.ac.ru by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA11663; Mon, 21 Jul 1997 16:31:54 +0100 Received: from vega (vega.ipi.ac.ru [193.233.25.86]) by demos.ipi.ac.ru (8.6.12/8.6.12) with ESMTP id TAA02404; Mon, 21 Jul 1997 19:31:35 +0400 Message-ID: <33D380BE.52B94373@ipi.ac.ru> Date: Mon, 21 Jul 1997 19:31:10 +0400 From: Alexey Ryaboshapko Organization: IPI RAS X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Error with modules? X-Priority: 3 (Normal) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 568 Status: OR Hi. I have following idl text: //file a.idl module A { interface B { void f(); }; }; It's compiled by omniidl2.exe into two files a.cpp and a.h after that I'm trying to compile it with MSVC5.0 to a.obj file, the following error messages come: CL /GR /nologo /MD /W3 /GX /O2 /D "WIN32" /D "_CONSOLE" /D "__NT__" /D " _X86_" -I. -Id:\omniORB2\include -c a.CPP a.CPP a.h(153) : error C2027: use of undefined type 'A' a.h(160) : error C2027: use of undefined type 'A' NMAKE : fatal error U1077: 'CL' : return code '0x2' Stop. What I have to do? Am I wrong? From alex@ipi.ac.ru Tue Jul 22 13:46:59 1997 Return-Path: Received: from demos.ipi.ac.ru by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA24700; Tue, 22 Jul 1997 13:45:39 +0100 Received: from vega (vega.ipi.ac.ru [193.233.25.86]) by demos.ipi.ac.ru (8.6.12/8.6.12) with ESMTP id QAA03838; Tue, 22 Jul 1997 16:42:29 +0400 Message-ID: <33D4AA96.687A87F4@ipi.ac.ru> Date: Tue, 22 Jul 1997 16:41:58 +0400 From: Alexey Ryaboshapko Organization: IPI RAS X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: valerie.castelain@sema.es, omniorb-list@orl.co.uk Subject: Re: Error with modules? X-Priority: 3 (Normal) References: <1.5.4.16.19970722100125.1c67208a@ortega> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Content-Length: 1622 Status: OR > >Hi. > >I have following idl text: > >//file a.idl > >module A { > > interface B { > > void f(); > > }; > > }; > > > >It's compiled by omniidl2.exe into two files a.cpp and a.h > >after that I'm trying to compile it with MSVC5.0 to a.obj file, > >the following error messages come: > >CL /GR /nologo /MD /W3 /GX /O2 /D "WIN32" /D "_CONSOLE" /D "__NT__" /D " > >_X86_" -I. -Id:\omniORB2\include -c a.CPP > >a.CPP > >a.h(153) : error C2027: use of undefined type 'A' > >a.h(160) : error C2027: use of undefined type 'A' > >NMAKE : fatal error U1077: 'CL' : return code '0x2' > >Stop. > > > >What I have to do? > >Am I wrong? > > > > > > Hi ... > > I also met the *use of undefined type 'A'* problem. > It seems omniidl2.exe generates something wrong: > in the lines the compiler tells you (l.153, l.160), you should have a > *static A::B_ptr __nil_B;* > or something like that. > Just leave the *A::* part in that two lines (all this is within the > *_CORBA_MODULE A * part, so it is not necessary to specify the module once > more, I think). > > Try it and tell me ... > > Valérie > > *++++++++++++++++++++++++++* > * Valérie CASTELAIN * > * SEMA GROUP sae * > * C/ Albarracín, 25 * > * 28037 MADRID * > * 327.28.28 * > * valerie.castelain@sema.es * > * +++++++++++++++++++++++++* Hi. I just leave the *A::* part in those lines and all work fine! I also try this sample under Solaris but there was no problems. It look like only Windows problem. The great thank, Alexey. From S.Lo@orl.co.uk Tue Jul 22 17:48:02 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA27827; Tue, 22 Jul 1997 17:46:53 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id RAA08710; Tue, 22 Jul 1997 17:46:53 +0100 Date: Tue, 22 Jul 1997 17:46:53 +0100 Message-Id: <199707221646.RAA08710@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: omniorb-list@orl.co.uk Subject: Re: echo examples refuse to run ! In-Reply-To: References: X-Mailer: VM 6.23 under Emacs 19.34.1 From: Sai-Lai Lo CC: Gerald Gutierrez Content-Length: 2695 Status: OR The first thing I suggest is to look into your tcp/ip setup. A number of users have previously reported similar problems with standalone linux machines. Here is what I suggest them do: 1. Setup the machine to have a valid host name and IP address, for instance, an IP address from the private address space allocated by IANA (RFC 1918). 2. Setup a (loopback) route to your machine. For instance, you can use the "dummy" interface on Linux to do that. You may have to recompile your kernel to include the interface. Remember, just having the 127.0.0.0 loopback is not enough. I suspect your problem is similar. 1. Does your machine have a valid IP and host name? 2. If you are not connected to the network via PPP, can you ping your machine, telnet to your machine? If not, it is an indication that the loopback is not working. 3. Is your ISP doing dynamic IP address allocation? Each time you connect, you are getting a different IP address? 4. You only need to run omninames with the -start *once*. When you rerun omninames you don't use the -start option. If you do so, the IOR should stay the same. If you check the above and still cannot get it working, do get back to us and send us the output of the programes. Regards, Sai-Lai Lo >>>>> Gerald Gutierrez writes: > Here's a summary of what I have done and what my results were : > - Installed package > - Ran omninames -start 12345, got the IOR and put it into omniorb.cfg > prefixed by the NAMESERVICE keyword > - Set environment variable OMNIORB_CONFIG to point to omniorb.cfg > - Made logdir and set environment variable OMNINAMES_LOGDIR to point to it > - Put IOR into the registry ( I believe in > HKEY_LOCAL_MACHINE/SOFTWARE/ORL/OmniORB/2.0/NAMESERVICE ) > - Started omninames ( I stopped the first one I ran and started again by > just typing omninames ) > I can get echo/eg1 to run just fine ( I suppose this means the runtime > libraries work partially, if not entirely ). I can get echo/eg2_impl to > run, and display the IOR. I CANNOT get eg2_clt to work properly -- it > reports a COMM_FAILURE exception. I CANNOT get eg3_impl to run -- it dies > with an abnormal program termination. Needless to say, eg3_clt doesn't run > either. It dies with an unknown exception caught. > Another symptom is that the first time I run omninames, it gives me one > IOR. When I quit, put that IOR into the cfg file and/or the registry and > rerun omninames, it comes out with ANOTHER IOR. Is this normal ? > I wondered if it was the TCP stack I was using, and ping'ed myself, which > worked. I hooked up to the internet through PPP and tried again, and it > worked. I cannot figure it out. From wenger@iam.unibe.ch Wed Jul 23 08:56:06 1997 Return-Path: Received: from arwen.unibe.ch by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA04645; Wed, 23 Jul 1997 08:45:19 +0100 Received: from asterix (actually asterix.unibe.ch) by arwen with SMTP (PP); Wed, 23 Jul 1997 09:43:23 +0200 Received: from kira.unibe.ch by asterix (5.x/SMI-SVR4) id AA06735; Wed, 23 Jul 1997 09:44:17 +0200 Received: by kira.unibe.ch (5.x/SMI-SVR4) id AA13523; Wed, 23 Jul 1997 09:43:59 +0200 Date: Wed, 23 Jul 1997 09:43:59 +0200 From: wenger@iam.unibe.ch (Thomas Wenger) Message-Id: <9707230743.AA13523@kira.unibe.ch> To: omniorb-list@orl.co.uk Subject: Bootstraping-IOR & SharedLib with GNU g++ Cc: wenger@iam.unibe.ch X-Sun-Charset: US-ASCII Content-Length: 1976 Status: OR Hello to all users of omniORB2, I am using omniORB2 for some time now. I have two questions that may be answered by someone of you: 1. How to get the IOR of omniNames into another ORB *************************************************** I am using JavaIDL-ORB (EA) for clients and omniORB for the serverobjects. My question is now: How do I get the IOR of omniNames into the JavaORB? I thought that IP-address and port-number (can be set as parameters) would be enough information for the Java-ORB to get contact to omniNames. But it did not work. As I see it at the moment, I have to write the stringified IOR of omniNames into a file, that is located on the webserver, so that it can be accessed by the JavaORB. The JavaORB then has to get an object by resolving the IOR it got via reading a textfile on the server. Does anybody have any suggestions or remarks to that? (For your information I inserted the "pragma omg.org stuff" in omniNames. So it is not this problem...) 2. How to build shared libraries with GNU g++ (under Solaris 2.5) ***************************************************************** I am running omniORB with GNU g++. But I was told, that GNU was only possible when not using shared libs. So I am using static libs now. But imagine if you have 10 server objects: you loose some MB of RAM, if every server-object has its statically linked libs. So my question: does anybody have makefiles/modifications/hints to offer, that enable me to build shared libs with omniORB and GNU g++? Thanks to everyone TOM -- ================================================================= Thomas Wenger wenger@iam.unibe.ch University: Institute of Computer Science and Applied Mathematics (IAM), Office 205 Neubrueckstr. 10, CH-3012 Bern +41 31 631 49 90 Private: Wydacherstrasse 4, CH-3113 Rubigen +41 31 721 41 18 ================================================================= From mamue@fbti.et-inf.fho-emden.de Wed Jul 23 10:23:54 1997 Return-Path: Received: from fbti.et-inf.fho-emden.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA05655; Wed, 23 Jul 1997 10:18:53 +0100 Received: by fbti.et-inf.fho-emden.de id (Debian /\oo/\ Smail3.1.29.1 #29.36); Wed, 23 Jul 97 11:18 MET DST Message-Id: From: mamue@fbti.et-inf.fho-emden.de (Malte Mueller) Subject: Re: Bootstraping-IOR To: omniorb-list@orl.co.uk Date: Wed, 23 Jul 1997 11:18:38 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Content-Length: 2009 Status: OR Hello, > 1. How to get the IOR of omniNames into another ORB > *************************************************** > > I am using JavaIDL-ORB (EA) for clients and omniORB for the serverobjects. My question is now: How do I get the IOR of omniNames into the JavaORB? > I thought that IP-address and port-number (can be set as parameters) would be enough information for the Java-ORB to get contact to omniNames. But it did not work. > As I see it at the moment, I have to write the stringified IOR of omniNames into a file, that is located on the webserver, so that it can be accessed by the JavaORB. The JavaORB then has to get an object by resolving the IOR it got via reading a textfile on the server. > > Does anybody have any suggestions or remarks to that? > (For your information I inserted the "pragma omg.org stuff" in omniNames. So it is not this problem...) > We use the second approach. It looks something like that: public String readIOR() { InputStream iorInputStream = null; String input=null; try { iorInputStream = iorURL.openStream(); } catch(IOException ioe) { ioe.printStackTrace(System.out); } DataInputStream iorDataInputStream = new DataInputStream(iorInputStream); try { input = iorDataInputStream.readLine(); } catch(IOException ioe) { ioe.printStackTrace(System.out); } return input; } For convenience we write the Stringified IOR of the server and the nameserver to a defined file at startup with a little script like that: #!/bin/sh /usr/local/JavaIDL/bin/nameserv -ORBInitialPort 8088 > /home/mamue/javaIDL.log & sleep 4 grep IOR /home/mamue/javaIDL.log > /home/mamue/javaIDL.ior cd /home/mamue/programming/corba/java /usr/local/jdk1.1.1/bin/java -classpath /usr/local/jdk1.1.1/lib/classes.zip:/usr /local/JavaIDL/lib/classes.zip:. pictureServer -ORBInitialPort 8088 & cd - Hope this helped Malte Mueller mamue@server.et-inf.fho-emden.de http://info.et-inf.fho-emden.de/~mamue From Mark.Whalley@NS.PNG.LE.gpt.co.uk Thu Jul 24 11:32:53 1997 Return-Path: Received: from ms.gpt.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id LAA19429; Thu, 24 Jul 1997 11:27:52 +0100 From: Mark.Whalley@NS.PNG.LE.gpt.co.uk Received: from cvhp99 (cvhp99.gpt.co.uk) by ms.gpt.co.uk with ESMTP (1.37.109.17/ms-04) id AA070490167; Thu, 24 Jul 1997 11:29:28 +0100 Received: from cvvx43.gpt.co.uk. (cvvx43.gpt.co.uk) by cvhp99 with ESMTP (1.37.109.17/99-15) id AA178219891; Thu, 24 Jul 1997 11:24:51 +0100 Received: from mhs-in by cvvx43 (PMDF V5.0-4 #8246) id <01ILM36CXM8W00BZUO@cvvx43> for omniorb-list@orl.co.uk; Thu, 24 Jul 1997 11:26:25 -0300 (BST) Date: Thu, 24 Jul 1997 11:27:25 -0300 (BST) Subject: Memory leaks To: omniorb-list@orl.co.uk Cc: John.Howells@NS.PNG.LE.gpt.co.uk Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 7BIT Posting-Date: Thu, 24 Jul 1997 11:27:36 +0100 Priority: normal Hop-Count: 2 Content-Length: 637 Status: OR The following code fragment appears to leak memory ... CORBA::Object_var obj; for (int i=0; i<9999; i++) { obj = rootContext->resolve(name); } ... I'm assuming that the object reference is not being released when the Object_var is assigned a new (in this case the same) object reference. The C++ language mappings state "the object reference variable type (A_var) will automatically release its object reference when it is deallocated or when assigned a new object reference". I'm running this on Solaris, an monitoring the memory usage using ps -l. Is this a known problem or am I doing something daft. From gutier@unixg.ubc.ca Thu Jul 24 17:50:36 1997 Return-Path: Received: from mail.unixg.ubc.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA25059; Thu, 24 Jul 1997 17:41:48 +0100 Received: from netinfo1.ubc.ca [137.82.27.45] (gutier) by mail.unixg.ubc.ca with smtp (Exim 1.61 #1) id 0wrQxW-0006z4-00; Thu, 24 Jul 1997 09:41:46 -0700 Date: Thu, 24 Jul 1997 09:41:45 -0700 (PDT) From: Gerald Gutierrez X-Sender: gutier@netinfo1.ubc.ca To: omniorb-list@orl.co.uk Subject: Linux linuxthreads vs pthreads 1.0.0 -- omninames core dump ! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 750 Status: OR Hi all. I've decided to switch over to Linux to try out OmniORB. Getting the precompiled version, I ran omninames and was told I needed libpthreads.so.0. I didn't have a threads package installed and could not find the linuxthreads package as was mentioned in the documentation, so I got myself th PCThreads 1.0 package, which is supposed to be the first release of the POSIX compliant threads library. It installed to /usr/lib/libpthreads.so.1. Seeing as the last number was different, I took the chance and linked the .1 to .0. Now omninames cores. Am I using the wrong threads library ? If so, could someone please point me to the correct package ? If not, well, then I must have some other problem. What could it be ? Thanks for any help. From gutier@unixg.ubc.ca Tue Jul 22 17:02:16 1997 Return-Path: Received: from mail.unixg.ubc.ca by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA27304; Tue, 22 Jul 1997 17:00:20 +0100 Received: from netinfo1.ubc.ca [137.82.27.45] (gutier) by mail.unixg.ubc.ca with smtp (Exim 1.61 #1) id 0wqhMI-0004Yx-00; Tue, 22 Jul 1997 09:00:18 -0700 Date: Tue, 22 Jul 1997 09:00:18 -0700 (PDT) From: Gerald Gutierrez X-Sender: gutier@netinfo1.ubc.ca To: omniorb-list@orl.co.uk Subject: echo examples refuse to run ! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1898 Status: OR Hi all. I have been a user of Orbix for Solaris for a while when I discovered that there was a free CORBA implementation for Win32. I decided to try it and downloaded the distribution. Everything installed fine and all the utils in the bin directory seem to work. I have read all the documentation and done the configuration. However, I cannot seem to get the echo examples to run properly ! If anyone can help me, it would be just superb because I'd really like to make use of this package. Here's a summary of what I have done and what my results were : - Installed package - Ran omninames -start 12345, got the IOR and put it into omniorb.cfg prefixed by the NAMESERVICE keyword - Set environment variable OMNIORB_CONFIG to point to omniorb.cfg - Made logdir and set environment variable OMNINAMES_LOGDIR to point to it - Put IOR into the registry ( I believe in HKEY_LOCAL_MACHINE/SOFTWARE/ORL/OmniORB/2.0/NAMESERVICE ) - Started omninames ( I stopped the first one I ran and started again by just typing omninames ) I can get echo/eg1 to run just fine ( I suppose this means the runtime libraries work partially, if not entirely ). I can get echo/eg2_impl to run, and display the IOR. I CANNOT get eg2_clt to work properly -- it reports a COMM_FAILURE exception. I CANNOT get eg3_impl to run -- it dies with an abnormal program termination. Needless to say, eg3_clt doesn't run either. It dies with an unknown exception caught. Another symptom is that the first time I run omninames, it gives me one IOR. When I quit, put that IOR into the cfg file and/or the registry and rerun omninames, it comes out with ANOTHER IOR. Is this normal ? I wondered if it was the TCP stack I was using, and ping'ed myself, which worked. I hooked up to the internet through PPP and tried again, and it worked. I cannot figure it out. If anyone can help me out, I would be extremely grateful. Thanks. From pooh@msu.ru Fri Aug 1 13:16:46 1997 Return-Path: Received: from forest.nmd.msu.ru by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA01930; Fri, 1 Aug 1997 13:00:16 +0100 Received: from forest (forest.nmd.msu.ru [193.232.112.56]) by forest.nmd.msu.ru (AIX4.2/UCB 8.7/8.7) with SMTP id QAA17570 for ; Fri, 1 Aug 1997 16:01:07 +0400 (MEDT) Sender: pooh@forest.nmd.msu.ru Message-ID: <33E1D002.167E@msu.ru> Date: Fri, 01 Aug 1997 16:01:06 +0400 From: Andrey Slepuhin Organization: Moscow State University X-Mailer: Mozilla 3.0 (X11; I; AIX 2) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Patches for AIX Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 10683 Status: OR Below there are patches needed to compile omniORB 2.2.0 on AIX 4.2 with C Set++ 3.1.4 (with some comments) Notes: 1) When shared libraries are to be created, they overwrite static versions, because in AIX shared objects can be inserted into archives. 2) I think that libraries can be build with GNU C without problems, but to compile multithreaded programs on AIX crt0_r.o must be linked instead crt0.o. C Set++ does this automatically if compiler invoked with _r suffix (xlC_r for example). For GNU C it can be done manually, but this is not convenient. 3) I don't know if these patches work for AIX version <4.2 (and I have not any machine such AIX version installed) 4) Please, read the patches carefully, may be you can find other solutions Best wishes, Andrey **************************************** First, makefiles: mk/powerpc_aix_4.2.mk: ---------------------------------------- # # powerpc_aix_4.2.mk - make variables and rules specific to AIX 4.2 on # PowerPC. # PLATFORM = powerpc_aix_4.2 LIBDIR = $(TOP)/lib BINDIR = $(TOP)/bin # # C preprocessor macro definitions for this architecture # PLATFORM_CPPFLAGS = -D__aix__ -D__powerpc__ -D__OSVERSION__=4.2 # # Standard programs # AR = ar cq RANLIB = ranlib MKDIRHIER = /usr/bin/X11/mkdirhier CP = cp MV = mv -f RM = rm -f CXX = xlc_r CXXFLAGS = $(CXXDEBUGFLAGS) $(CXXOPTIONS) $(CPPFLAGS) CXXDEBUGFLAGS = CXXOPTIONS = CXXLINK = xlC_r CXXLINKOPTIONS = $(CXXDEBUGFLAGS) $(CXXOPTIONS) CPPFLAGS = $(DIR_CPPFLAGS) $(PLATFORM_CPPFLAGS) .SUFFIXES: .o .cc .C .cpp .cxx .cc.o: $(CXX) -c $(CXXFLAGS) -o $@ $< .C.o: $(CXX) -c $(CXXFLAGS) -o $@ $< .cpp.o: $(CXX) -c $(CXXFLAGS) -o $@ $< .cxx.o: $(CXX) -c $(CXXFLAGS) -o $@ $< # I can't find pthread version anywhere, but after some attempts # all compiles fine with -DPthreadDraftVersion=8 OMNITHREAD_POSIX_CPPFLAGS = -DNoNanoSleep -DPthreadDraftVersion=8 OMNITHREAD_CPPFLAGS = -I$(TOP)/include -D_REENTRANT OMNITHREAD_LIB = -lomnithread -lpthreads OMNITHREAD_STATIC_LIB = -lomnithread -lpthreads # Default location of the omniORB2 configuration file [falls back to this if # the environment variable OMNIORB_CONFIG is not set] : OMNIORB_CONFIG_DEFAULT_LOCATION = \"/etc/omniORB.cfg\" OMNIORB_CPPFLAGS = -D__OMNIORB2__ $(OMNITHREAD_CPPFLAGS) OMNIORB_LIB = -lomniORB2 $(OMNITHREAD_LIB) OMNIORB_STATIC_LIB = -lomniORB2 $(OMNITHREAD_STATIC_LIB) # Default directory for the omniNames log files. OMNINAMES_LOG_DEFAULT_LOCATION = \"/var/omninames\" ---------------------------------------- src/lib/omnithread/sharedlib/powerpc_aix_4.2.mk: ---------------------------------------- OBJS = posix.o LIBS = -lpthread DIR_CPPFLAGS = $(OMNITHREAD_CPPFLAGS) $(OMNITHREAD_POSIX_CPPFLAGS) all:: libomnithread.so.1.0 libomnithread.so.1.0: $(OBJS) (set -x; \ $(RM) $@; \ makeC++SharedLib \ -o $@ \ -lpthreads -lC -lc_r -lc -p 40 $(OBJS); \ ) clean:: $(RM) *.o core $(RM) libomnithread.so.1.0 install:: libomnithread.so.1.0 @(set -x; \ $(MKDIRHIER) $(LIBDIR); \ $(CP) libomnithread.so.1.0 $(LIBDIR); \ cd $(LIBDIR); \ $(RM) libomnithread.a; \ ar -rv -s libomnithread.a libomnithread.so.1.0; \ $(RM) libomnithread.so.1.0; \ ) posix.o: ../posix.cc $(CXX) -c $(CXXFLAGS) -o $@ ../posix.cc ---------------------------------------- src/lib/omniORB2/sharedlib/powerpc_aix_4.2.mk: ---------------------------------------- all:: libomniORB2.so.2.0 libomniORB2.so.2.0: $(ORB2_OBJS) (set -x; \ $(RM) $@; \ makeC++SharedLib \ -o $@ \ -L$(LIBDIR) $(OMNITHREAD_LIB) \ -lpthreads -lC -lc_r -lc -p 40 $(ORB2_OBJS); \ ) clean:: $(RM) *.o core $(RM) libomniORB2.so.2.0 install:: libomniORB2.so.2.0 @(set -x; \ $(MKDIRHIER) $(LIBDIR); \ $(CP) libomniORB2.so.2.0 $(LIBDIR); \ cd $(LIBDIR); \ $(RM) libomniORB2.a; \ ar -rv libomniORB2.a libomniORB2.so.2.0; \ $(RM) libomniORB2.so.2.0; \ ) ---------------------------------------- Patches to sources: AIX uses POSIX threads: ---------------------------------------- diff -r omniORB_2.2.0/include/omnithread.h omniORB_2.2.0.orig/include/omnithread.h 70,71d69 < #if defined(__powerpc__) && defined(__aix__) < #include "omnithread/posix.h" 73c71 < #elif defined(__arm__) && defined(__atmos__) --- > #if defined(__arm__) && defined(__atmos__) ---------------------------------------- PowerPC is BIG_ENDIAN: ---------------------------------------- diff -r omniORB_2.2.0/include/omniORB2/CORBA_sysdep.h omniORB_2.2.0.orig/include/omniORB2/CORBA_sysdep.h 115,116d114 < #elif defined(__powerpc__) < #define _OMNIORB_HOST_BYTE_ORDER_ 0 ---------------------------------------- Only in omniORB_2.2.0/mk: powerpc_aix_4.2.1.mk This is needed because C Set++ does not like expressions such as OSLEVEL == (it says that this is invalid constant expression) ---------------------------------------- diff -r omniORB_2.2.0/src/appl/omniNames/log.cc omniORB_2.2.0.orig/src/appl/omniNames/log.cc 271d270 < #ifndef __aix__ 276d274 < #endif 505d502 < #ifndef __aix__ 510d506 < #endif 518d513 < #ifndef __aix__ 522d516 < #endif 536d529 < #ifndef __aix__ 539d531 < #endif ---------------------------------------- This is because compiler can't recognize which call of operator<< is used (operator<<(const void*) or operator<<(const char*)): ---------------------------------------- diff -r omniORB_2.2.0/src/appl/utils/nameclt/nameclt.cc omniORB_2.2.0.orig/src/appl/utils/nameclt/nameclt.cc 191,192c191,192 < cerr << "(" << (char*)((*bl)[i].binding_name[0].id) << "," < << (char*)((*bl)[i].binding_name[0].kind) << ") binding type " --- > cerr << "(" << (*bl)[i].binding_name[0].id << "," > << (*bl)[i].binding_name[0].kind << ") binding type " ---------------------------------------- The same reason: ---------------------------------------- diff -r omniORB_2.2.0/src/examples/echo/greeting.cc omniORB_2.2.0.orig/src/examples/echo/greeting.cc 28,29c28,29 < cerr << "I said,\"" << (char*)src << "\"." < << " The Object said,\"" << (char*)dest <<"\"" << endl; --- > cerr << "I said,\"" << src << "\"." > << " The Object said,\"" << dest <<"\"" << endl; ---------------------------------------- In AIX third parameter of accept() also of size_t type: ---------------------------------------- diff -r omniORB_2.2.0/src/lib/omniORB2/tcpSocket_UNIX.cc omniORB_2.2.0.orig/src/lib/omniORB2/tcpSocket_UNIX.cc 53d52 < #if !defined(__aix__) 57d55 < #endif 662c660 < #if defined(__aix__) || (defined(__GLIBC__) && __GLIBC__ >= 2) --- > #if defined(__GLIBC__) && __GLIBC__ >= 2 729c727 < #if defined(__aix__) || (defined(__GLIBC__) && __GLIBC__ >= 2) --- > #if defined(__GLIBC__) && __GLIBC__ >= 2 ---------------------------------------- I can't understand why $< needed, but this cause errors: ---------------------------------------- diff -r omniORB_2.2.0/src/lib/omniORB2/sharedlib/Makefile omniORB_2.2.0.orig/src/lib/omniORB2/sharedlib/Makefile 49c49 < $(CXX) -c $(CXXFLAGS) -o $@ ../NamingSK.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../NamingSK.cc 73c73 < $(CXX) -c $(CXXFLAGS) -o $@ ../constants.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../constants.cc 98c98 < $(CXX) -c $(CXXFLAGS) -o $@ ../corbaBoa.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../corbaBoa.cc 123c123 < $(CXX) -c $(CXXFLAGS) -o $@ ../corbaObject.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../corbaObject.cc 148c148 < $(CXX) -c $(CXXFLAGS) -o $@ ../corbaOrb.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../corbaOrb.cc 173c173 < $(CXX) -c $(CXXFLAGS) -o $@ ../corbaString.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../corbaString.cc 198c198 < $(CXX) -c $(CXXFLAGS) -o $@ ../exception.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../exception.cc 223c223 < $(CXX) -c $(CXXFLAGS) -o $@ ../giopClient.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../giopClient.cc 248c248 < $(CXX) -c $(CXXFLAGS) -o $@ ../giopServer.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../giopServer.cc 273c273 < $(CXX) -c $(CXXFLAGS) -o $@ ../initFile.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../initFile.cc 298c298 < $(CXX) -c $(CXXFLAGS) -o $@ ../ior.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../ior.cc 324c324 < $(CXX) -c $(CXXFLAGS) -o $@ ../libcWrapper.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../libcWrapper.cc 349c349 < $(CXX) -c $(CXXFLAGS) -o $@ ../mbufferedStream.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../mbufferedStream.cc 374c374 < $(CXX) -c $(CXXFLAGS) -o $@ ../nbufferedStream.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../nbufferedStream.cc 399c399 < $(CXX) -c $(CXXFLAGS) -o $@ ../object.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../object.cc 424c424 < $(CXX) -c $(CXXFLAGS) -o $@ ../objectKey.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../objectKey.cc 450c450 < $(CXX) -c $(CXXFLAGS) -o $@ ../objectRef.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../objectRef.cc 476c476 < $(CXX) -c $(CXXFLAGS) -o $@ ../orb.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../orb.cc 501c501 < $(CXX) -c $(CXXFLAGS) -o $@ ../strand.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../strand.cc 528c528 < $(CXX) -c $(CXXFLAGS) -o $@ ../tcpSocket_UNIX.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../tcpSocket_UNIX.cc 555c555 < $(CXX) -c $(CXXFLAGS) -o $@ ../unshared.cc --- > $(CXX) -c $< $(CXXFLAGS) -o $@ ../unshared.cc ---------------------------------------- AIX hasn't nanosleep() but has usleep() (there is also nsleep() which is similar to nanosleep()): ---------------------------------------- diff -r omniORB_2.2.0/src/lib/omnithread/posix.cc omniORB_2.2.0.orig/src/lib/omnithread/posix.cc 931c931 < #elif defined(__linux__) || defined (__aix__) --- > #elif defined(__linux__) 956c956 < #if defined(__linux__) || defined(__aix__) --- > #ifdef __linux__ ---------------------------------------- ---------------------------------------- diff -r omniORB_2.2.0/src/tool/omniidl2/driver/drv_fork.cc omniORB_2.2.0.orig/src/tool/omniidl2/driver/drv_fork.cc 100,104d99 < #if defined(__aix__) < #include // POSIX standard types < #include // POSIX definition of wait() < #endif < ---------------------------------------- From pooh@msu.ru Fri Aug 1 11:01:05 1997 Return-Path: Received: from forest.nmd.msu.ru by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA00115; Fri, 1 Aug 1997 10:41:12 +0100 Received: from forest (forest.nmd.msu.ru [193.232.112.56]) by forest.nmd.msu.ru (AIX4.2/UCB 8.7/8.7) with SMTP id NAA21556 for ; Fri, 1 Aug 1997 13:42:02 +0400 (MEDT) Sender: pooh@forest.nmd.msu.ru Message-ID: <33E1AF69.41C6@msu.ru> Date: Fri, 01 Aug 1997 13:42:01 +0400 From: Andrey Slepuhin Organization: Moscow State University X-Mailer: Mozilla 3.0 (X11; I; AIX 2) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omniORB: AIX port Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 274 Status: OR Hi, Yesterday I have successfully compiled omniORB 2.2.0 on AIX 4.2 with C Set++ 3.1.4. All examples (both in thread and echo subdirectories) work fine. Shared libs are also Ok. If anybody interested I can send appropriate patches. Andrey Slepuhin, Moscow State University From ewc@orl.co.uk Fri Aug 1 17:18:19 1997 Return-Path: Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA04771; Fri, 1 Aug 1997 17:08:36 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id RAA06438; Fri, 1 Aug 1997 17:08:36 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199708011608.RAA06438@casabel.cam-orl.co.uk> Subject: Re: Patches for AIX To: omniorb-list@orl.co.uk Date: Fri, 1 Aug 1997 17:08:35 +0100 (BST) In-Reply-To: <33E1D002.167E@msu.ru> from "Andrey Slepuhin" at Aug 1, 97 04:01:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 439 Status: OR Hi, Andrey's patches are now available from our web site at http://www.orl.co.uk/omniORB/omniORBNews.html Could anyone who applies the patches please report on how they got on (send e-mail to the list or to omniorb@orl.co.uk) - we don't have any AIX platforms to test the patches. Regards, Eoin Carroll -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Lab Cambridge, UK From gdd0@lion.gte.com Fri Aug 1 17:43:45 1997 Return-Path: Received: from lion.gte.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA05126; Fri, 1 Aug 1997 17:30:43 +0100 Received: from localhost (localhost [127.0.0.1]) by lion.gte.com (AIX4.2/UCB 8.7/8.7) with SMTP id MAA24014; Fri, 1 Aug 1997 12:30:26 -0400 (EDT) Message-Id: <199708011630.MAA24014@lion.gte.com> X-Authentication-Warning: lion.gte.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ewc@orl.co.uk (Eoin Carroll) Cc: omniorb-list@orl.co.uk Subject: Re: Patches for AIX Date: Fri, 01 Aug 1997 12:30:20 -0400 From: "Gary D. Duzan" Content-Length: 679 Status: OR In Message <199708011608.RAA06438@casabel.cam-orl.co.uk> , ewc@orl.co.uk (Eoin Carroll) wrote: =>Hi, => =>Andrey's patches are now available from our web site at =>http://www.orl.co.uk/omniORB/omniORBNews.html => Now you tell me. I just got it working on AIX, myself... Gary D. Duzan GTE Laboratories =>Could anyone who applies the patches please report on how they got on =>(send e-mail to the list or to omniorb@orl.co.uk) - we don't have any =>AIX platforms to test the patches. => =>Regards, => =>Eoin Carroll => =>-- =>Eoin Carroll ewc@orl.co.uk =>Research Engineer =>Olivetti & Oracle Research Lab =>Cambridge, UK From lennart.holen@agresso.no Mon Aug 4 15:49:35 1997 Return-Path: Received: from agrwall.agresso.no by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA07852; Mon, 4 Aug 1997 15:23:40 +0100 Received: from [195.1.61.2] (HELO localhost) by agrwall.agresso.no (AltaVista Mail V1.0/1.0 BL18 listener) id 0000_004c_33e5_e565_4b2d; Mon, 04 Aug 1997 16:21:25 +0200 Message-ID: From: Lennart Holen To: "'omniorb-list@orl.co.uk'" Subject: Netscape-client Date: Mon, 4 Aug 1997 16:26:25 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 845 Status: OR Hi! I'm trying to use a Java applet client in Netscape's Navigator communicating with an ORB on server. The "problem" is that Netscape have CORBA classes locally with the browser installation (It is very fine if we get this thing working!). The applet get these parameters: And the code is: public static org.omg.CORBA.ORB theOrb; // create and initialize the ORB theOrb = org.omg.CORBA.ORB.init(this, null); // get the root naming context org.omg.CORBA.Object objRef = theOrb.resolve_initial_references("NameService"); And here it jumps out with invalidName exception. Does someone have any clues? This code works fine with Internet explorer naturally, because classloader loads all CORBA-classes from the webserver. Lennart From arao@compuware.com Mon Aug 4 21:58:17 1997 Return-Path: Received: from stargate.compuware.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id VAA12239; Mon, 4 Aug 1997 21:55:12 +0100 Received: by stargate.compuware.com id AA00601 (InterLock SMTP Gateway 3.0 for omniorb-list@orl.co.uk); Mon, 4 Aug 1997 16:55:03 -0400 Message-Id: <199708042055.AA00601@stargate.compuware.com> Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-2); Mon, 4 Aug 1997 16:55:03 -0400 From: arao@compuware.com (Anant Rao) Received: by stargate.compuware.com (Protected-side Proxy Mail Agent-1); Mon, 4 Aug 1997 16:55:03 -0400 Date: Mon, 4 Aug 1997 13:54:33 -0700 To: omniorb-list@orl.co.uk Subject: Re: omniORB2 in Production Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: pHuTFEuShUB3btMIjJI/7g== Content-Length: 293 Status: OR Hi, Has anybody deployed omniORB2 in a production environment? If so, could you share your experience on whether there were any omni-related run-time problems and how you solved them i.e., did you effectively start fixing the CORBA source code or did ORL help you? Thanks very much! From ruff@Comsys.DoFN.DE Tue Aug 5 13:26:20 1997 Return-Path: Received: from inet_srv.comsys.dofn.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA21371; Tue, 5 Aug 1997 13:17:29 +0100 Received: from wias-p3 (ruff@sak486 [193.141.78.74]) by inet_srv.comsys.dofn.de (8.7/8.7) with SMTP id OAA11359; Tue, 5 Aug 1997 14:17:28 +0200 (MET DST) Sender: ruff@Comsys.DoFN.DE Message-ID: <33E719C6.29E5D15E@comsys.dofn.de> Date: Tue, 05 Aug 1997 14:17:10 +0200 From: Marcel Ruff X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omniORB on Linux 2.0.30 / gcc 2.7.2.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1830 Status: OR Hi, I compiled omniORB 2.2.0 on Linux 2.0.30 with gcc 2.7.2.2 and glibc 2.0.4 (with linuxthreads etc.) The main problem was for me to get the newest gcc to work with glibc 2.04 (the installation was quite a hack) I made minor changes to omniORB sources so that gcc is satisfied: In ./omniORB_2.2.0/src/tool/omniidl2/driver/drv_fork.cc and in ./omniORB_2.2.0/src/tool/omniidl2/driver/drv_preproc.cc adding: #if defined(__linux__) #include // POSIX standard types #include // POSIX definition of wait() #endif diff output from ./omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_name.cc: 70c70 < if ((id = internal_search_pragma(pd_decl,"ID")) != 0) { --- > if (id = internal_search_pragma(pd_decl,"ID")) { 73c73 < else if ((id = internal_search_pragma(pd_decl,"version")) != 0) { --- > else if (id = internal_search_pragma(pd_decl,"version")) { I wonder if following is a serious warning: idl.ll:1694: warning: aggregate has a partly bracketed initializer Thanks for the free omniORB! so long, Marcel ------------------------------------------------------------------ _/_/_/ _/ _/ _/_/_/ _/_/_/ Dipl.-Ing. Marcel Ruff _/ _/ _/ _/ _/ _/ Nortel Dasa Network Systems _/_/_/ _/ _/ _/_/_/ _/_/_/ GmbH & Co KG, ND252 _/ _/ _/ _/ _/ _/ An der Bundesstrasse 31 _/ _/ _/_/_/ _/ _/ D-88090 Immenstaad/Bodensee Postfach: D-88039 Friedrichshafen ------------------------------------------------------------------- Tel.: 07545/8-4689 Fax : 07545/8-5811 Tel.: +49/7556/96780 (priv) email: ruff@comsys.dofn.de email: Marcel.Ruff@t-online.de (priv) ------------------------------------------------------------------- From jk@leo.tools.de Wed Aug 6 17:49:18 1997 Return-Path: Received: from karl.tools.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id RAA10206; Wed, 6 Aug 1997 17:29:58 +0100 Received: from leo.tools.de (leo.TooLs.DE [192.76.135.71]) by karl.tools.de (8.7.3/8.7.3) with SMTP id SAA09909 for ; Wed, 6 Aug 1997 18:30:22 +0200 (MET DST) Received: by leo.tools.de (SMI-8.6/SMI-SVR4) id SAA01471; Wed, 6 Aug 1997 18:30:21 +0200 Date: Wed, 6 Aug 1997 18:30:21 +0200 From: jk@leo.tools.de (Juergen Keil) Message-Id: <199708061630.SAA01471@leo.tools.de> To: omniorb-list@orl.co.uk Subject: Fix: omniidl2 generates bad code for user exceptions X-Sun-Charset: US-ASCII Content-Length: 2850 Status: OR After adding the #pragma prefix "omg.org" line to Naming.idl, so that omniORB can talk to the JavaIDL nameserver, I had some problems with the echo/eg3_impl example. It ran fine when eg3_impl was started for the first time, but after killing eg3_impl and running if for a second time it always crashed with a system exception. When running eg3_impl for the second time, the object is still bound on the nameserver from a previous invocation and the bind method invocation should get a CosNaming::NamingContext::AlreadyBound exception, so that eg3_impl tries to rebind the object instead. But instead of the AlreadyBound exception, a CORBA::MARSHAL exception occurs! The problem is caused by omniidl2, which generates bad code for the proxy stubs when user exceptions have to be handled: The length of the longest repository id for all exceptions that can occur (the 49 in the code below) is mis-calculated. Here's the relevant code from NamingSK.cc, generated for Naming.idl with the added #pragma prefix "omg.org" line: case GIOP::USER_EXCEPTION: { CORBA::Char _excId[49]; CORBA::ULong _len; _len <<= _c; if (_len > 49) { _c.RequestCompleted(1); throw CORBA::MARSHAL(0,CORBA::COMPLETED_MAYBE); } else { _c.get_char_array(_excId,_len); } Since ``IDL:omg.org/CosNaming/NamingContext/AlreadyBound:1.0'' has a length of 53 bytes (including the terminating \0) the AlreadyBound exception cannot be processed by the proxy stubs because the local _excId buffer is to small and a CORBA::MARSHAL exception is thrown instead. The bogus number 49 is calculated by omniidl2 as the maximum of all excpt->repoIdConstLen() for all exceptions that can occur, but excpt->repoIdConstLen() returns the length of the pre-processor macro (!) that contains the repository id for the exception (aka CosNaming_NamingContext_AlreadyBound_IntfRepoID). The following patch to omniidl2 fixes the problem: diff -rc3 omniORB_2.2.0-orig/src/tool/omniidl2/omniORB2_be/o2be_exception.cc omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc *** omniORB_2.2.0-orig/src/tool/omniidl2/omniORB2_be/o2be_exception.cc Tue May 6 15:54:52 1997 --- omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc Wed Aug 6 17:18:06 1997 *************** *** 45,51 **** pd_repoid = new char[strlen(_fqname())+strlen(IRREPOID_POSTFIX)+1]; strcpy(pd_repoid,_fqname()); strcat(pd_repoid,IRREPOID_POSTFIX); ! pd_repoidsize = strlen(pd_repoid)+1; } void --- 45,51 ---- pd_repoid = new char[strlen(_fqname())+strlen(IRREPOID_POSTFIX)+1]; strcpy(pd_repoid,_fqname()); strcat(pd_repoid,IRREPOID_POSTFIX); ! pd_repoidsize = strlen(repositoryID()) + 1; } void -- Juergen Keil jk@tools.de ...!{uunet,mcsun}!unido!tools!jk From gdd0@lion.gte.com Thu Aug 7 19:28:10 1997 Return-Path: Received: from lion.gte.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id TAA27582; Thu, 7 Aug 1997 19:19:00 +0100 Received: from localhost (localhost [127.0.0.1]) by lion.gte.com (AIX4.2/UCB 8.7/8.7) with SMTP id OAA20922 for ; Thu, 7 Aug 1997 14:18:56 -0400 (EDT) Message-Id: <199708071818.OAA20922@lion.gte.com> X-Authentication-Warning: lion.gte.com: Host localhost [127.0.0.1] didn't use HELO protocol To: omniorb-list@orl.co.uk Subject: OmniORB Indicator Macro Date: Thu, 07 Aug 1997 14:18:54 -0400 From: "Gary D. Duzan" Content-Length: 346 Status: OR From what I have seen in the headers, it doesn't look like OmniORB defines any macros specifically for the purpose of identifying that we are compiling for OmniORB as opposed to some other ORB. Is this something that would be generally useful? I'll probably just use __OMNIORB_H__ in the mean time. Gary D. Duzan GTE Laboratories From M.C.Little@ncl.ac.uk Thu Aug 7 16:16:17 1997 Return-Path: Received: from cheviot.ncl.ac.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA25318; Thu, 7 Aug 1997 16:09:04 +0100 Received: from langley.ncl.ac.uk by cheviot.ncl.ac.uk id (8.7.6/ for ncl.ac.uk) with ESMTP; Thu, 7 Aug 1997 16:09:04 +0100 (BST) Sender: nmcl@ncl.ac.uk Message-ID: <33E9E50F.D47DD348@ncl.ac.uk> Date: Thu, 07 Aug 1997 16:09:03 +0100 From: Mark Little Organization: Arjuna Project X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: "omniorb-list@orl.co.uk" Subject: ORB_init signature X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 627 Status: OR I don't know if this has already been mentioned, but the signature to ORB_init is wrong in the version of omniOrb we have. It should be: ORB_ptr ORB_init(int&, char**, ORBid); where ORBid is defined by omniOrb to be a Char* (unsigned char*) but is: ORB_ptr ORB_init(int&, char**, const char*). Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From M.C.Little@ncl.ac.uk Thu Aug 7 15:52:12 1997 Return-Path: Received: from cheviot.ncl.ac.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA25055; Thu, 7 Aug 1997 15:46:11 +0100 Received: from langley.ncl.ac.uk by cheviot.ncl.ac.uk id (8.7.6/ for ncl.ac.uk) with ESMTP; Thu, 7 Aug 1997 15:46:10 +0100 (BST) Sender: nmcl@ncl.ac.uk Message-ID: <33E9DFB2.669353CD@ncl.ac.uk> Date: Thu, 07 Aug 1997 15:46:10 +0100 From: Mark Little Organization: Arjuna Project X-Mailer: Mozilla 4.01b6C [en] (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: "omniorb-list@orl.co.uk" Subject: omniidl2 includes X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 828 Status: OR I have 2 idl files which are located in different subdirectories: A.idl, located in the commonIdl directory, say: interface foo { } and B.idl, located in the myIdl directory: #include interface bar : foo { } I want the "compiled" header files to be located in the same directories as the idl file. When I pass B.idl to omniidl2 it generates code which says: #include whereas what I really want is: #include Is this possible? Thanks in advance, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From tikki@dei.unipd.it Thu Aug 7 13:40:40 1997 Return-Path: Received: from anna.dei.unipd.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA22625; Thu, 7 Aug 1997 13:30:57 +0100 Received: from leila (leila.dei.unipd.it) by anna.dei.unipd.it with SMTP id AA13230 (5.67b/IDA-1.5 for ); Thu, 7 Aug 1997 14:27:03 +0200 Date: Thu, 7 Aug 1997 14:27:00 +0200 (MET DST) From: Nalin Stefano 308885/IF X-Sender: tikki@leila To: Lennart Holen Cc: "'omniorb-list@orl.co.uk'" Subject: Re: Netscape-client In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1290 Status: OR On Mon, 4 Aug 1997, Lennart Holen wrote: > Hi! > I'm trying to use a Java applet client in Netscape's Navigator > communicating with an ORB on server. The "problem" is that Netscape have > CORBA classes locally with the browser installation (It is very fine if > we get this thing working!). > The applet get these parameters: > > > > And the code is: > public static org.omg.CORBA.ORB theOrb; > > // create and initialize the ORB > theOrb = org.omg.CORBA.ORB.init(this, null); > > // get the root naming context > org.omg.CORBA.Object objRef = > theOrb.resolve_initial_references("NameService"); > > And here it jumps out with invalidName exception. Does someone have any > clues? > > This code works fine with Internet explorer naturally, because > classloader loads all CORBA-classes from the webserver. > > Lennart > > > > Hi, to use the embedded ORB of Netscape, you have to use the VisiBroker for Java to make the stub classes. But I don't know if there is a way to load the appropriate classes, if the ORB used by the client is not that from Visigenic. I'm trying to use the JavaIDL because it's free, but with Netscape 4.01 it doesn't work. Bye. Stefano From basjes@nlr.nl Fri Aug 8 08:36:55 1997 Return-Path: Received: from nlrgup.nlr.nl by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA04888; Fri, 8 Aug 1997 08:31:26 +0100 Received: from sunnygirl.nlr.nl (sunnygirl.nlr.nl [137.17.196.43]) by nlrgup.nlr.nl (8.8.5/8.8.5/NLR 04/02/97) with SMTP id JAA01845; Fri, 8 Aug 1997 09:31:21 +0200 (DST) Disclaimer: "The National Aerospace Laboratory NLR DOES NOT ACCEPT ANY FINANCIAL COMMITMENT derived from this message." Received: from localhost by sunnygirl.nlr.nl (SMI-8.6/SMI-SVR4) id JAA00263; Fri, 8 Aug 1997 09:31:17 +0200 Date: Fri, 8 Aug 1997 09:31:16 +0200 (MET DST) From: Niels Basjes To: "Gary D. Duzan" cc: omniorb-list@orl.co.uk Subject: Re: OmniORB Indicator Macro In-Reply-To: <199708071818.OAA20922@lion.gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 902 Status: OR On Thu, 7 Aug 1997, Gary D. Duzan wrote: > From what I have seen in the headers, it doesn't look like > OmniORB defines any macros specifically for the purpose of identifying > that we are compiling for OmniORB as opposed to some other ORB. Is this > something that would be generally useful? I'll probably just use > __OMNIORB_H__ in the mean time. I just include the config.mk for my platform (solaris) in my own makefile. In config.mk __OMNIORB2__ is defined, so that is what I use. Ragards, Niels ================================================================ | ir. Niels Basjes | National Aerospace Laboratory | | Phone : +31-20-5113626 | Anthony Fokkerweg 2 | | E-Mail@NLR : Basjes@NLR.nl | 1059 CM Amsterdam | | E-Mail@Home: Niels@Basjes.nl | The Netherlands | ================================================================ From jan@c-lab.de Fri Aug 8 12:26:05 1997 Return-Path: Received: from mailserver.c-lab.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA07891; Fri, 8 Aug 1997 12:19:25 +0100 Received: from bolg.c-lab.de (bolg.c-lab.de [131.234.80.130]) by mailserver.c-lab.de (8.7.5/8.7.3) with ESMTP id NAA11723 for ; Fri, 8 Aug 1997 13:19:24 +0200 (MET DST) Received: from bolg (localhost [127.0.0.1]) by bolg.c-lab.de (8.7.5/8.7.3) with SMTP id NAA13045 for ; Fri, 8 Aug 1997 13:19:22 +0200 (MET DST) Sender: jan@c-lab.de Message-ID: <33EB00B8.451@c-lab.de> Date: Fri, 08 Aug 1997 13:19:20 +0200 From: Jan Lessner Organization: C-LAB X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Using omniORB accross network boundaries Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 262 Status: OR Hello omniORB'ers I'm currently thinking over how to bind to objects in server application which are located outside my local area network. Is there a way to contact different name services on different (potentially remote) sites? Regards, Jan Lessner, C-LAB From S.Lo@orl.co.uk Fri Aug 8 16:41:44 1997 Return-Path: Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id QAA11057; Fri, 8 Aug 1997 16:33:37 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id QAA02392; Fri, 8 Aug 1997 16:33:37 +0100 Date: Fri, 8 Aug 1997 16:33:37 +0100 Message-Id: <199708081533.QAA02392@santaka.cam-orl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "omniorb-list@orl.co.uk" Subject: Re: ORB_init signature In-Reply-To: <33E9E50F.D47DD348@ncl.ac.uk> References: <33E9E50F.D47DD348@ncl.ac.uk> X-Mailer: VM 6.23 under Emacs 19.34.1 From: Sai-Lai Lo Content-Length: 951 Status: OR Just to clarify: ------ According to CORBA 2.0 spec. 17.12.4 ORB Initialization: // C++ typedef char* ORBid; static ORB_ptr ORB_init(int& argc, char** argv,const char*orb_identifier); ----- omniORB has it as: typedef Char* ORBid; static ORB_ptr ORB_init(int& argc, char** argv,const char*orb_identifier=0); This is obviously wrong. (However, I had a feeling that this signature was actually used in an earlier version of the C++ mapping.) ------ The new POA spec. changes the mapping to: // C++ typedef char* ORBid; static ORB_ptr ORB_init(int& argc, char** argv,const char*orb_identifier=""); ----- >>>>> Mark Little writes: > I don't know if this has already been mentioned, but the signature to > ORB_init is wrong in the version of omniOrb we have. It should be: > ORB_ptr ORB_init(int&, char**, ORBid); > where ORBid is defined by omniOrb to be a Char* (unsigned char*) > but is: > ORB_ptr ORB_init(int&, char**, const char*). From anil@ittc.ukans.edu Sat Aug 9 04:44:17 1997 Return-Path: Received: from stephens.ittc.ukans.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id EAA17664; Sat, 9 Aug 1997 04:38:36 +0100 Received: from mauchly.ittc.ukans.edu by stephens.ittc.ukans.edu (8.6.10/KU-3.0) id WAA24948; Fri, 8 Aug 1997 22:29:27 -0500 Received: from localhost by mauchly.ittc.ukans.edu (5.65v3.2/KU-4.0-client) id AA30890; Fri, 8 Aug 1997 22:29:27 -0500 Date: Fri, 8 Aug 1997 22:29:26 -0500 (CDT) From: "Anil K. Gopinath" To: omniorb-list@orl.co.uk Subject: problems with running omniORB2 on Linux. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 501 Status: OR Hi Folks, Iam having problems running the example program (eg1) on Linux. The program gives a segmentation fault on execution. I tried to debug the code and it seg. faults in a header file (IIOP.h)!. The configuration that Iam using : - Kernel 2.0.27 (Redhat 4.2) on i586 - Gnu C++ 2.7.2.1-2 - Binutils 2.7.0.2-4 - Linux C Library 5.3.12-18 - Linux C++ Library 2.7.1.4-5 - Linuxthreads 0.5-1 Any pointers/help to fix the problem will be greatly appreciated... Anil From Edward.Scott@prismtech.co.uk Mon Aug 11 18:20:38 1997 Return-Path: Received: from alpha3.prismtech.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA20209; Mon, 11 Aug 1997 18:16:37 +0100 Received: from alpha3 (localhost.prismtech.co.uk [127.0.0.1]) by alpha3.prismtech.co.uk (8.6.9/8.6.9) with SMTP id SAA26233; Mon, 11 Aug 1997 18:24:02 +0100 Sender: eas@prismtech.co.uk Message-ID: <33EF4AB2.1CFB@prismtech.co.uk> Date: Mon, 11 Aug 1997 18:24:02 +0100 From: Edward Scott Organization: Prism Technologies Ltd X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: Niels Basjes CC: omniORB2 Mailing list Subject: Re: Porting Orbix specific code to omniORB. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1982 Status: OR The follow is an excerpt from some code which does what you trying to do: CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv,"omniORB2"); CORBA::BOA_ptr boa = orb->BOA_init(argc,argv,"omniORB2_BOA"); // more code ... #if defined OMNIORB PT_Persistence::PersistentStore_var myRef = store->_this(); CORBA::String_var p = orb->object_to_string(myRef); #elif defined ORBIX CORBA::Orbix.setServerName ("PersistentStore"); char *p = CORBA::string_dupl( store-> _object_to_string(CORBA::IT_INTEROPERABLE_OR_KIND)); // more code... As you can see you need to invoke object_to_string on an instance of CORBA::ORB. Regards, Edward Niels Basjes wrote: > > Hi, > > I have some code here which was written using the Orbix specific > function CORBA::Object::_object_to_string(). > This was done to obtain a unique ID for an object. > > What I'm trying to do is port this code to work with omniORB2. > > I know that the CORBA compliant version is > CORBA::ORB::object_to_string(Object_ptr) > > I've tried giving the mentioned class a member function > that does "return CORBA::ORB::object_to_string(this);" but that didn't > work (compiler errors). > > Can anyone give me hint or solution how I can port this the easiest way ?? > > Regards, > > Niels Basjes > > ================================================================ > | ir. Niels Basjes | National Aerospace Laboratory | > | Phone : +31-20-5113626 | Anthony Fokkerweg 2 | > | E-Mail@NLR : Basjes@NLR.nl | 1059 CM Amsterdam | > | E-Mail@Home: Niels@Basjes.nl | The Netherlands | > ================================================================ -- ----------------------------------------------------------------------- Edward Scott ................Prism Technologies Ltd., Kingfisher House, http://www.prismtech.co.uk ..Kingsway, Tyne & Wear, NE11 0JQ, England Edward.Scott@prismtech.co.uk Tel +44(0)1914913983 Fax +44(0)1914913973 From basjes@nlr.nl Mon Aug 11 15:34:45 1997 Return-Path: Received: from nlrgup.nlr.nl by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA17009; Mon, 11 Aug 1997 15:01:24 +0100 Received: from sunnygirl.nlr.nl (sunnygirl.nlr.nl [137.17.196.43]) by nlrgup.nlr.nl (8.8.5/8.8.5/NLR 04/02/97) with SMTP id QAA14676 for ; Mon, 11 Aug 1997 16:01:20 +0200 (DST) Disclaimer: "The National Aerospace Laboratory NLR DOES NOT ACCEPT ANY FINANCIAL COMMITMENT derived from this message." Received: from localhost by sunnygirl.nlr.nl (SMI-8.6/SMI-SVR4) id QAA12132; Mon, 11 Aug 1997 16:01:13 +0200 Date: Mon, 11 Aug 1997 16:01:13 +0200 (MET DST) From: Niels Basjes To: omniORB2 Mailing list Subject: Porting Orbix specific code to omniORB. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 960 Status: OR Hi, I have some code here which was written using the Orbix specific function CORBA::Object::_object_to_string(). This was done to obtain a unique ID for an object. What I'm trying to do is port this code to work with omniORB2. I know that the CORBA compliant version is CORBA::ORB::object_to_string(Object_ptr) I've tried giving the mentioned class a member function that does "return CORBA::ORB::object_to_string(this);" but that didn't work (compiler errors). Can anyone give me hint or solution how I can port this the easiest way ?? Regards, Niels Basjes ================================================================ | ir. Niels Basjes | National Aerospace Laboratory | | Phone : +31-20-5113626 | Anthony Fokkerweg 2 | | E-Mail@NLR : Basjes@NLR.nl | 1059 CM Amsterdam | | E-Mail@Home: Niels@Basjes.nl | The Netherlands | ================================================================ From owner-omniorb-list@orl.co.uk Tue Aug 12 15:10:25 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA03055; Tue, 12 Aug 1997 14:59:06 +0100 Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA03050; Tue, 12 Aug 1997 14:59:03 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id OAA24904; Tue, 12 Aug 1997 14:59:03 +0100 Received: from casabel.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id OAA02998; Tue, 12 Aug 1997 14:55:38 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id OAA24869; Tue, 12 Aug 1997 14:55:37 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199708121355.OAA24869@casabel.cam-orl.co.uk> Subject: ADMIN: Majordomo, archives on the web. To: omniorb-list@orl.co.uk Date: Tue, 12 Aug 1997 14:55:37 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 730 omniorb-list is now administered by majordomo. Subscribe and unsubscribe instructions are the same as before: To subscribe, send a message to omniorb-list-request@orl.co.uk containing the command "subscribe" in the body of the e-mail. To unsubscribe, send an message to omniorb-list-request@orl.co.uk containing the command "unsubscribe" in the body of the e-mail. For a list of majordomo commands, send a message to majordomo@orl.co.uk containing the command "help" in the body of the e-mail. The archives of the mailing list are now available at: http://www.orl.co.uk/omniORB/archives/ -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Lab Cambridge, UK From owner-omniorb-list@orl.co.uk Wed Aug 13 08:03:06 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id HAA12657; Wed, 13 Aug 1997 07:05:01 +0100 Received: from stephens.ittc.ukans.edu by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id HAA12653; Wed, 13 Aug 1997 07:04:44 +0100 Received: from houston.ittc.ukans.edu by stephens.ittc.ukans.edu (8.6.10/KU-3.0) id BAA04734; Wed, 13 Aug 1997 01:04:32 -0500 Received: from localhost by houston.ittc.ukans.edu (8.8.5/KU-4.0-client) id BAA20214; Wed, 13 Aug 1997 01:04:32 -0500 Date: Wed, 13 Aug 1997 01:04:31 -0500 (CDT) From: "Anil K. Gopinath" X-Sender: anil@houston.ittc.ukans.edu.(none) To: omniorb-list@orl.co.uk Subject: Re: problems with running omniORB2 on Linux. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 632 Folks, We were able to install and run omniORB2 on Linux. The culprit was the gcc compiler version 2.7.2.2.f.2 . It gives a segmentation fault when running the following code : ------------------test.cc-------------------- #include #include struct hostent *hp; extern int h_errno; int main() { hp = gethostbyname("www.orl.co.uk"); printf("\n host name = %s\n" , hp->h_name); return 0; } ---------------end of test.cc------------------ As a result omniORB2 would seg. fault because it uses the function gethostbyname. We used an older version of gcc (2.7.2.1) and things are OK now. Cheers, Anil From owner-omniorb-list@orl.co.uk Wed Aug 13 10:23:38 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA14666; Wed, 13 Aug 1997 10:06:42 +0100 Received: from synet.symbolic.it by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id KAA14661; Wed, 13 Aug 1997 10:06:34 +0100 Received: from bix.symbolic.it (bix.symbolic.it [195.103.76.48]) by synet.symbolic.it (8.8.5/8.8.5) with SMTP id LAA23174 for ; Wed, 13 Aug 1997 11:06:24 +0200 (MDT) Message-ID: <33F179B2.71E909F8@symbolic.it> Date: Wed, 13 Aug 1997 11:09:06 +0200 From: gigi Organization: symbolic X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Novice question about sequence Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 657 Hi, I need help about sequence: I've written an IDL interface like this: typedef sequence Octetseq; interface PListener { void PktRecv (in uint tvSec, in uint tvUSec, in uint Clen, in uint Len, in Octetseq PktData ); }; now, my implementation looks like: . . . for(;;) { . . . Voyeur::ByteStream pd = Voyeur::ByteStream(DEFSNAPLEN); pd.length(DEFSNAPLEN); for(unsigned long t = 0; t < (DEFSNAPLEN); t++) { pd[t] = pkt[t]; } plCurrent->PktRecv(ts.tv_sec, ts.tv_usec, clen, len, pd); } but every time I run it the program crashes after few loops. Any suggestion ? Best Regards, Luigi From owner-omniorb-list@orl.co.uk Wed Aug 13 22:54:06 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id WAA24334; Wed, 13 Aug 1997 22:51:22 +0100 Received: from tumbleweed1.tumbleweed.com by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id WAA24330; Wed, 13 Aug 1997 22:51:20 +0100 Received: from dev1 ([199.220.220.201]) by tumbleweed1.tumbleweed.com (post.office MTA v2.0 0813 ID# 0-11773) with ESMTP id AAA269 for ; Wed, 13 Aug 1997 14:14:50 -0700 Message-ID: <33F22486.7A8A713C@tumbleweed.com> Date: Wed, 13 Aug 1997 14:17:58 -0700 From: saintlou@tumbleweed.com (Emmanuel Saint-Loubert) Organization: Tumbleweed Software Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: Omniorb List Subject: namespace vs class X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 408 Hello, Has anyone tried to change OmniORB IDL compiler to map module to namepsace instead of class ? If so, could we get the patch published ? Thanks a bunch, -- Emmanuel R. Saint-Loubert saintlou@tumbleweed.com Tumbleweed Software Corp. http://www.tumbleweed.com 2010 Broadway Tel 650-569-3676 Redwood City, CA 94063 Fax 650-369-7197 From owner-omniorb-list@orl.co.uk Thu Aug 14 15:54:02 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA05678; Thu, 14 Aug 1997 15:48:18 +0100 Received: from dxmint.cern.ch by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA05674; Thu, 14 Aug 1997 15:48:16 +0100 Received: from cmsmail.cern.ch (cmsmail.cern.ch [137.138.81.187]) by dxmint.cern.ch with SMTP id QAA18082 for ; Thu, 14 Aug 1997 16:48:16 +0200 (MET DST) Received: from suncms42.cern.ch by cmsmail.cern.ch (SMI-8.6/SMI-SVR4) id QAA04245; Thu, 14 Aug 1997 16:48:14 +0200 Received: from suncms42 by suncms42.cern.ch (SMI-8.6/SMI-SVR4) id QAA28999; Thu, 14 Aug 1997 16:48:12 +0200 Message-ID: <33F31AA9.4B38@cern.ch> Date: Thu, 14 Aug 1997 16:48:09 +0200 From: Johannes Gutleber Organization: CERN - European Lab. for Particle Physics X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omniORB2 performance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 1025 Hi! Does omniorb implement some special detection if objects reside on the same node or communication is done between the same hardware architecture? I ask this, because I get very good performance numbers compared to other orbs, especially when I make communication within the same machine (factor 10 faster than some other orbs). When it comes to communication over networks speeds of omniorb compared to some other orbs get more comparable. Does anyone have a explanation for this effect? Hannes -- +--------------------------------------------------------------+ | Johannes Gutleber | | CERN, European Laboratory for Particle Physics | | Division ECP, Compact Muon Solenoid experiment | | CH-1211 Geneva 23, Switzerland | | e-mail: Johannes.Gutleber@cern.ch | | FAX: +41 (22) 767 89 40 | +--------------------------------------------------------------+ From owner-omniorb-list@orl.co.uk Thu Aug 14 16:56:02 1997 Return-Path: Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id QAA29793; Thu, 14 Aug 1997 16:56:01 +0100 Received: by casabel.cam-orl.co.uk (SMI-8.6/SMI-SVR4-ORL-0.2) id QAA29789; Thu, 14 Aug 1997 16:55:59 +0100 From: ewc@orl.co.uk (Eoin Carroll) Message-Id: <199708141555.QAA29789@casabel.cam-orl.co.uk> Subject: Re: omniORB2 performance To: Johannes.Gutleber@cern.ch (Johannes Gutleber) Date: Thu, 14 Aug 1997 16:55:59 +0100 (BST) Cc: omniorb-list@orl.co.uk In-Reply-To: <33F31AA9.4B38@cern.ch> from "Johannes Gutleber" at Aug 14, 97 04:48:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 2432 Hi, > Does omniorb implement some special detection if objects reside on > the same node or communication is done between the same hardware > architecture? > I ask this, because I get very good performance numbers > compared to other orbs, especially when I make communication > within the same machine (factor 10 faster than some other orbs). > When it comes to communication over networks speeds of omniorb compared > to some other orbs get more comparable. Does anyone have a explanation > for this effect? > omniORB2 doesn't (yet) do anything special if objects reside in different address spaces on the same node or on different nodes of the same architecture. We are, however, working on a shared memory transport. There are a number of reasons for the effects you have noticed: 1. If the machines are of the same endian, then no byte swapping is required. This explains why omniORB2 performance is better between machines of the same architecture than between machines of different architecture (if the machines are of different endian). Mind you, this is also true for any ORB - but perhaps the ORBs you have tested have less efficient unmarshalling functions than omniORB2. 2. Threading. Different ORBs have different threading policies. If an ORB uses several threads when sending and servicing a request, then there can be a lot of overhead from thread scheduling. This is particularly the case when the client and server object are on the same machine. If they are on different machines, then not all of the thread switching takes place on the same machine. In omniORB2, there is no thread switching along the call chain. On the client side, the thread that invokes on the object directly sends the GIOP request, and then blocks, waiting for the reply. On the server side, a dedicated thread blocks for requests. When it receives one, it unmarshalls the request and arguments, performs the upcall, and sends the reply. This policy should be more efficient then using several threads to service each request, particularly when the objects are on the same machine. omniORB2 also has several other optimizations which may contribute to the superior performance in the situations you observed. Regards, Eoin Carroll -- Eoin Carroll ewc@orl.co.uk Research Engineer Olivetti & Oracle Research Lab Cambridge, UK From owner-omniorb-list@orl.co.uk Tue Aug 19 12:45:52 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA07346; Tue, 19 Aug 1997 12:28:38 +0100 Received: from mailserver.c-lab.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id MAA07340; Tue, 19 Aug 1997 12:28:35 +0100 Received: from bolg.c-lab.de (bolg.c-lab.de [131.234.80.130]) by mailserver.c-lab.de (8.7.5/8.7.3) with ESMTP id NAA15803 for ; Tue, 19 Aug 1997 13:28:34 +0200 (MET DST) Received: from bolg (localhost [127.0.0.1]) by bolg.c-lab.de (8.7.5/8.7.3) with SMTP id NAA24882 for ; Tue, 19 Aug 1997 13:28:30 +0200 (MET DST) Message-ID: <33F98347.7657@c-lab.de> Date: Tue, 19 Aug 1997 13:28:29 +0200 From: Jan Lessner Organization: C-LAB X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Application shut down References: <33EB00B8.451@c-lab.de> <199708081545.QAA02432@santaka.cam-orl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 836 Hello I'd like to write a client application which causes a server to shut down. For this purpose, the server has a function like this: long stop(in long force); The function is supposed to return a value differing from 0 if force is not set and the server is busy. Otherwise it should shut down, returning 0 as a commitment. My question now is how to implement this functionality in the server. If I just call exit in the server code, the stop function doesn't properly return at all. I thought I could just check for this case by catching CORBA::COMM_FAILURE exceptions, but this isn't the case. In fact on client side the function returns a non-zero value (25, but this is probably just unspecified) so that I can't tell the propper shutdown from a rejection. Does anybody have a solution for that? Regards, Jan Lessner, C-LAB From owner-omniorb-list@orl.co.uk Wed Aug 20 08:56:43 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA24938; Wed, 20 Aug 1997 08:54:53 +0100 Received: from inet_srv.comsys.dofn.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id IAA24934; Wed, 20 Aug 1997 08:54:51 +0100 Received: from wias-p11 (narr@[134.92.247.114]) by inet_srv.comsys.dofn.de (8.7/8.7) with SMTP id JAA23177 for ; Wed, 20 Aug 1997 09:54:46 +0200 (MET DST) Message-ID: <33FAA2AC.453DDE75@comsys.dofn.de> Date: Wed, 20 Aug 1997 09:54:20 +0200 From: Jörg Narr X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i486) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omniORB's NamingService Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 996 Hi! I'm quite new to CORBA and I'm actually busy implementing a client-server application. Since my objects are required to be server or client at a time I'm not sure how to implement this. I did the following: I bound the server with a special name like aaa* where * is a unique number to a NamingContext. Before this I look up the context for other servers with aaa and a unique number to retrieve their IOR's respectively their object implementation. Unfortunately I often got stringified IOR's I couldn't find in the omninames*.log file (with grep) and so calls to the retrieved objects failed. My question now is: Can anybody tell me what the numbers IOR:*1 IOR:*2 in the log-file are? I saw that the first (*1) second (*2) IOR are different. When I print out the retrieved object with orb->object_to_string(retrieved_object) I get another IOR I can't find in the log-file, too. Has anybody an idea what my error could be? Thanks a lot! Cheers, Joerg. From owner-omniorb-list@orl.co.uk Wed Aug 20 15:25:59 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA29533; Wed, 20 Aug 1997 15:17:34 +0100 Received: from p-voyageur.issy.cnet.fr by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id PAA29528; Wed, 20 Aug 1997 15:17:32 +0100 Received: from C-MHS by p-voyageur.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id Q7XTVV87; Wed, 20 Aug 1997 16:10:28 +0200 Received: from scoop20.caen.cnet.fr by c-mhs.caen.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id R2QCN0C6; Wed, 20 Aug 1997 16:26:17 +0200 Message-ID: <33FAF9A3.3ABA0A86@cnet.francetelecom.fr> Date: Wed, 20 Aug 1997 16:05:23 +0200 From: Yvan Peter Organization: Centre Nationnal d'Etude des Telecommunications X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: omniORB mailing list Subject: Problem when invoking name service from Visibroker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 1065 Hello, I am trying to use omniORB's name service from Visibroker 2.5 C++ and still have some problems. I have recompiled omniBroker with #pragma prefix "omg.org" in IDL. I used this IDL to generate the stub for Visibroker and I can now successfully invoke the name service. However, I have a problems when an exception is raised by the name service. The exception is not recognized by the client. for example, the following code would run fine the first time and return with a SystemException of minor code 0 if I run it a second time: ... try { testContext = naming->bind_new_context(contextName); } catch ( CosNaming::NamingContext::AlreadyBound& ex) { fprintf(stderr, "user\n"); } catch ( CORBA::SystemException& ex) { fprintf(stderr, "system = %d\n", ex.minor()); } Any help would be greatly appreciated. Regards, Yvan -- Yvan PETER France Telecom/CNET 42, rue des Coutures - BP6243 F-14066 CAEN Cedex phone (+33) 2.31.75.91.39 / fax (+33) 2.31.73.56.26 email: Yvan.Peter@cnet.francetelecom.fr From owner-omniorb-list@orl.co.uk Wed Aug 20 18:10:31 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA02259; Wed, 20 Aug 1997 18:09:14 +0100 Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA02254; Wed, 20 Aug 1997 18:09:12 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id SAA15561; Wed, 20 Aug 1997 18:09:11 +0100 To: omniorb-list@orl.co.uk Subject: Re: Problem when invoking name service from Visibroker References: <33FAF9A3.3ABA0A86@cnet.francetelecom.fr> From: Sai-Lai Lo In-Reply-To: Yvan Peter's message of Wed, 20 Aug 1997 14:05:23 GMT CC: Yvan Peter Date: 20 Aug 1997 18:09:11 +0100 Message-ID: <3o90xwrdc8.fsf@santaka.cam-orl.co.uk> Lines: 85 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 2779 Hi! I hope when you say "omniBroker", you mean omniORB :-) The problem you have experienced is caused by a bug in omniidl2 (omniORB_2.2.0): The stub code to unmarshal user exception allocates the wrong size buffer for the repository ID string. This causes marshalling failures when the exception has a #pragma prefix defined. This bug has been reported by several users. The following patch to omniidl2 fix the problem: ------------------------- Cut here ------------------------------------ *** omniORB_2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc Tue May 6 14:54:52 1997 --- /project/omni/develop/src/tool/omniidl2/omniORB2_be/o2be_exception.cc Wed Aug 13 10:23:45 1997 *************** *** 25,30 **** --- 25,35 ---- /* $Log: o2be_exception.cc,v $ + Revision 1.5 1997/08/13 09:23:38 sll + o2be_exception::repoIdConstLen() now returns the correct length of the + repository ID. Previously, it wrongly returns the length of the header macro + name. + // Revision 1.4 1997/05/06 13:54:46 sll // Public release. // *************** *** 45,51 **** pd_repoid = new char[strlen(_fqname())+strlen(IRREPOID_POSTFIX)+1]; strcpy(pd_repoid,_fqname()); strcat(pd_repoid,IRREPOID_POSTFIX); ! pd_repoidsize = strlen(pd_repoid)+1; } void --- 50,56 ---- pd_repoid = new char[strlen(_fqname())+strlen(IRREPOID_POSTFIX)+1]; strcpy(pd_repoid,_fqname()); strcat(pd_repoid,IRREPOID_POSTFIX); ! pd_repoidsize = strlen(repositoryID())+1; } void --------------------------------- End--------------------- Yvan Peter writes: > > I am trying to use omniORB's name service from Visibroker 2.5 C++ and > still have some problems. > > I have recompiled omniBroker with #pragma prefix "omg.org" in IDL. > I used this IDL to generate the stub for Visibroker and I can now > successfully invoke the name service. > > However, I have a problems when an exception is raised by the > name service. The exception is not recognized by the client. > > for example, the following code would run fine the first time > and return with a SystemException of minor code 0 if I run it > a second time: > > ... > try { > testContext = naming->bind_new_context(contextName); > } > catch ( CosNaming::NamingContext::AlreadyBound& ex) { > fprintf(stderr, "user\n"); > } > catch ( CORBA::SystemException& ex) { > fprintf(stderr, "system = %d\n", ex.minor()); > } > -- 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 owner-omniorb-list@orl.co.uk Wed Aug 20 18:21:29 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA02431; Wed, 20 Aug 1997 18:20:19 +0100 Received: from santaka.cam-orl.co.uk by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id SAA02427; Wed, 20 Aug 1997 18:20:16 +0100 Received: by santaka.cam-orl.co.uk (8.8.5//ident-1.0) id SAA15591; Wed, 20 Aug 1997 18:20:16 +0100 To: omniorb-list@orl.co.uk CC: Jörg Narr Subject: Re: omniORB's NamingService References: <33FAA2AC.453DDE75@comsys.dofn.de> From: Sai-Lai Lo In-Reply-To: Jörg Narr's message of Wed, 20 Aug 1997 07:54:20 GMT Date: 20 Aug 1997 18:20:16 +0100 Message-ID: <3o67t0rctr.fsf@santaka.cam-orl.co.uk> Lines: 38 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 1683 Jörg Narr writes: > I did the following: I bound the server with a special name like aaa* > where * is a unique number to a NamingContext. Before this > I look up the context for other servers with aaa and a unique number to > retrieve their IOR's respectively their object implementation. > Unfortunately I often got stringified IOR's I couldn't find in the > omninames*.log file (with grep) and so calls to the retrieved > objects failed. My question now is: Can anybody tell me what the numbers > IOR:*1 IOR:*2 in the log-file > are? It is not a good idea to try to decode what is in omninames*.log. Why not getting the same information though the proper interface of the naming service? > I saw that the first (*1) second (*2) IOR are different. When I > print out the retrieved object with > orb->object_to_string(retrieved_object) I get another IOR I can't find > in the log-file, too. To satisfy the alignment requirements of CDR, there are padding bytes inside an IOR. These bytes are not initialised and are ignored by any compliant ORB. Given 2 IORs that refers to the same object, the padding bytes in the IORs may differ. The stringified form of an IOR is a hex dump of an IOR and includes the padding bytes. Therefore, the stringified version of 2 IORs may differ even if they are referring to the same object. Regards, Sai-Lai -- 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 owner-omniorb-list@orl.co.uk Fri Aug 22 13:35:05 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA26394; Fri, 22 Aug 1997 13:21:51 +0100 Received: from inet_srv.comsys.dofn.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA26390; Fri, 22 Aug 1997 13:21:41 +0100 Received: from wias-p11 (narr@[134.92.247.114]) by inet_srv.comsys.dofn.de (8.7/8.7) with SMTP id OAA06489 for ; Fri, 22 Aug 1997 14:21:31 +0200 (MET DST) Message-ID: <33FD8456.3AE83C0@comsys.dofn.de> Date: Fri, 22 Aug 1997 14:21:42 +0200 From: Jörg Narr X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i486) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: omniORB IDL-Types Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 727 Hi! Today I've got two questions and I wonder if somebody will help me again. 1.) I am required to adapt an existent distributed system to CORBA. I might have to use existing messaging classes to pass as parameters between the CORBA-Objects. Is that possible and if yes, how do I have to declare their datatypes in IDL? Is there a kind of forward declaration?=20 2.) By now I just implemented simple test-applications running on one machine so it was no problem for the naming service and the ORB to=20 find the appropriate Objects. The second thing I just don't know yet is: Is there also a CORBA-Damon for omniORB2 like the Damon with ORBIX? Thank you very much in advance. Regards, J=F6rg Narr From owner-omniorb-list@orl.co.uk Mon Aug 25 14:06:27 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA20734; Mon, 25 Aug 1997 13:40:35 +0100 Received: from mailserver.c-lab.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id NAA20729; Mon, 25 Aug 1997 13:40:33 +0100 Received: from bolg.c-lab.de (bolg.c-lab.de [131.234.80.130]) by mailserver.c-lab.de (8.7.5/8.7.3) with ESMTP id OAA00777 for ; Mon, 25 Aug 1997 14:40:28 +0200 (MET DST) Received: from bolg (localhost [127.0.0.1]) by bolg.c-lab.de (8.7.5/8.7.3) with SMTP id OAA04106 for ; Mon, 25 Aug 1997 14:40:25 +0200 (MET DST) Message-ID: <34017D35.5CD4@c-lab.de> Date: Mon, 25 Aug 1997 14:40:22 +0200 From: Jan Lessner Organization: C-LAB X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: omniorb-list@orl.co.uk Subject: Timeout for method invocation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 817 Hello everybody I'd like to implement an asynchronous communication between two servers which should be combined with a timeout facility. I.e. server A calls server B and then waits until either server B calls back by invoking a method in server A in turn or until a certain period of time has elapsed. Up to now I was using Orbix or CoolORB which both provided functionality to interupt the impl_is_ready method making it pretty easy to implement the scenario above. In omniORB I didn't find something similar yet. The natural way is to throw an exception in the callback procedure which causes impl_is_ready to return. But this doesn't help in omniORB since the executions of the callback and impl_is_ready are located in different threads (I guess). So, does anybody have an idea for that? Regards, Jan Lessner From owner-omniorb-list@orl.co.uk Tue Aug 26 01:16:35 1997 Return-Path: Received: by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id BAA24776; Tue, 26 Aug 1997 01:15:08 +0100 Received: from kira.ici.net by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5) id BAA24772; Tue, 26 Aug 1997 01:15:05 +0100 Received: from supercow (resendes@d-ma-fallriver-80.ici.net [207.180.10.89]) by kira.ici.net (8.8.5/8.8.5) with SMTP id UAA14550; Mon, 25 Aug 1997 20:14:50 -0400 (EDT) Date: Mon, 25 Aug 1997 20:25:34 -0400 (EDT) From: Robert Resendes To: "OmniORB User's List" cc: resendes@ici.net, Robert Resendes Subject: Source code modifications used to quiet gcc [long message] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-omniorb-list@orl.co.uk Precedence: bulk content-length: 16503 -----BEGIN PGP SIGNED MESSAGE----- Hello all, I am trying to package omniORB for a Linux distribution and one of the requirements is to eliminate warning/error messages. I have enclosed the modifications (below, in a patch format) that I used for the following system configuration: - - Kernel 2.0.29 - - Gnu C++ 2.7.2.1 - - Binutils 2.7.0.9 - - Linux C Library 5.4.33 - - Linux C++ Library 2.7.2.1 - - Linuxthreads 0.5 - - Architecture __i86__ Note: 1 - I still have one warning left in the example application code that I can't seem to get rid of. 2 - I had to modify the makefiles in some cases to turn off warnings (used -Wno-reorder to remove benign reordering messages overall and used special compile rule for lex.yy.cc to remove numerous warnings). 3 - My patches include all the patches available at the ominORB "news" page (http://www.orl.co.uk/omniORB/omniORBNews.html). - ------------------------- Cut here ------------------------------------ - --- omniorb-2.2.0.orig/src/lib/omnithread/posix.cc +++ omniorb-2.2.0/src/lib/omnithread/posix.cc @@ -50,7 +50,11 @@ #include #include "omnithread.h" - -#ifdef __linux__ +#if defined(__linux__) +#include +#endif + +#if defined(__linux__) && defined(_MIT_POSIX_THREADS) #include #endif - --- omniorb-2.2.0.orig/src/lib/omniORB2/orb.cc +++ omniorb-2.2.0/src/lib/omniORB2/orb.cc @@ -708,7 +708,7 @@ } return 0; } - - if (sscanf(argv[idx+1],"%u",&omniORB::traceLevel) != 1) { + if (sscanf(argv[idx+1],"%lu",&omniORB::traceLevel) != 1) { if (omniORB::traceLevel > 0) { cerr << "CORBA::ORB_init failed: invalid -ORBtraceLevel parameter." << endl; @@ -817,7 +817,7 @@ return 0; } CORBA::ULong port; - - if (sscanf(argv[idx+1],"%u",&port) != 1 || + if (sscanf(argv[idx+1],"%lu",&port) != 1 || (port == 0 || port >= 65536)) { if (omniORB::traceLevel > 0) { cerr << "BOA_init failed: invalid -BOAiiop_port parameter." << endl; - --- omniorb-2.2.0.orig/src/lib/omniORB2/corbaString.cc +++ omniorb-2.2.0/src/lib/omniORB2/corbaString.cc @@ -104,7 +104,7 @@ char & CORBA::String_var::operator[] (CORBA::ULong index) { - - if (!_data || strlen(_data) < (int)index) { + if (!_data || strlen(_data) < index) { _CORBA_bound_check_error(); // never return } return _data[index]; @@ -113,7 +113,7 @@ char CORBA::String_var::operator[] (CORBA::ULong index) const { - - if (!_data || strlen(_data) < (int)index) { + if (!_data || strlen(_data) < index) { _CORBA_bound_check_error(); // never return } return _data[index]; - --- omniorb-2.2.0.orig/src/lib/omniORB2/objectKey.cc +++ omniorb-2.2.0/src/lib/omniORB2/objectKey.cc @@ -153,7 +153,7 @@ omniORB::seqOctets* result = new omniORB::seqOctets; result->length(sizeof(omniORB::objectKey)); const CORBA::Octet* p = (const CORBA::Octet*) &k1; - - for (int i=0; i< sizeof(omniORB::objectKey); i++) { + for (unsigned int i=0; i< sizeof(omniORB::objectKey); i++) { result->operator[](i) = p[i]; } return result; @@ -167,7 +167,7 @@ } omniORB::objectKey result; CORBA::Octet* p = (CORBA::Octet*) &result; - - for (int i=0; i< sizeof(omniORB::objectKey); i++) { + for (unsigned int i=0; i< sizeof(omniORB::objectKey); i++) { p[i] = seq[i]; } return result; - --- omniorb-2.2.0.orig/src/tool/omniidl2/ast/ast_array.cc +++ omniorb-2.2.0/src/tool/omniidl2/ast/ast_array.cc @@ -105,7 +105,7 @@ { AST_Expression **result; UTL_ExprlistActiveIterator *l; - - long i; + unsigned long i; if (ds == NULL) return NULL; @@ -134,7 +134,7 @@ void AST_Array::dump(ostream &o) { - - long i; + unsigned long i; pd_base_type->dump(o); o << " "; - --- omniorb-2.2.0.orig/src/tool/omniidl2/ast/ast_constant.cc +++ omniorb-2.2.0/src/tool/omniidl2/ast/ast_constant.cc @@ -115,6 +115,16 @@ return "void"; case AST_Expression::EV_none: return "none"; + case AST_Expression::EV_wstring: + return "wstring"; + case AST_Expression::EV_wchar: + return "wchar"; + case AST_Expression::EV_longdouble: + return "longdouble"; + case AST_Expression::EV_ulonglong: + return "ulonglong"; + case AST_Expression::EV_longlong: + return "longlong"; } return 0; // for MSVC++ 4.2 } - --- omniorb-2.2.0.orig/src/tool/omniidl2/ast/ast_decl.cc +++ omniorb-2.2.0/src/tool/omniidl2/ast/ast_decl.cc @@ -100,12 +100,12 @@ AST_Decl::AST_Decl(NodeType nt, UTL_ScopedName *n, UTL_StrList *p) : pd_node_type(nt), pd_line(idl_global->lineno()), - - pd_local_name(n == NULL ? NULL : n->last_component()), + pd_local_name(n == NULL ? (Identifier *)NULL : n->last_component()), pd_file_name(idl_global->filename()), pd_pragmas(p), pd_defined_in(idl_global->scopes()->depth() > 0 ? idl_global->scopes()->top() - - : NULL), + : (UTL_Scope *)NULL), pd_imported(idl_global->imported()), pd_in_main_file(idl_global->in_main_file()), pd_added(I_FALSE) - --- omniorb-2.2.0.orig/src/tool/omniidl2/ast/ast_expression.cc +++ omniorb-2.2.0/src/tool/omniidl2/ast/ast_expression.cc @@ -86,7 +86,7 @@ { pd_defined_in = idl_global->scopes()->depth() > 0 ? idl_global->scopes()->top() - - : NULL; + : (UTL_Scope *)NULL; pd_line = idl_global->lineno(); pd_file_name = idl_global->filename(); } @@ -376,6 +376,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_ushort: switch (ev->et) { @@ -430,6 +432,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_long: switch (ev->et) { @@ -478,6 +482,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_ulong: switch (ev->et) { @@ -530,6 +536,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_bool: switch (ev->et) { @@ -572,6 +580,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_float: switch (ev->et) { @@ -616,6 +626,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_double: switch (ev->et) { @@ -658,6 +670,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_char: switch (ev->et) { @@ -714,6 +728,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_octet: switch (ev->et) { @@ -770,6 +786,8 @@ case AST_Expression::EV_void: case AST_Expression::EV_none: return NULL; + default: + return NULL; } case AST_Expression::EV_any: switch (ev->et) { @@ -794,6 +812,8 @@ default: return NULL; } + default: + return NULL; } return 0; // for MSVC++ 4.2 } @@ -1097,6 +1117,8 @@ case EV_string: copy->u.strval = pd_ev->u.strval; break; + default: + return NULL; } return coerce_value(copy, t); @@ -1225,6 +1247,8 @@ case EV_void: case EV_none: return I_FALSE; + default: + return I_FALSE; } return 0; // for MSVC++ 4.2 } @@ -1273,6 +1297,8 @@ case EV_void: case EV_none: return I_FALSE; + default: + return I_FALSE; } return 0; // for MSVC++ 4.2 } @@ -1346,6 +1372,9 @@ case AST_Expression::EV_any: case AST_Expression::EV_none: case AST_Expression::EV_void: + break; + default: + o << "Unexpected/unknown value"; break; } } - --- omniorb-2.2.0.orig/src/tool/omniidl2/driver/drv_fork.cc +++ omniorb-2.2.0/src/tool/omniidl2/driver/drv_fork.cc @@ -97,6 +97,11 @@ #include // POSIX definition of wait() #endif // defined(hpux) || defined(__hpux) +#if defined(__linux__) +#include // POSIX standard types +#include // +#include // POSIX definition of wait() +#endif // defined(__linux__) #ifndef __NT__ - --- omniorb-2.2.0.orig/src/tool/omniidl2/driver/drv_preproc.cc +++ omniorb-2.2.0/src/tool/omniidl2/driver/drv_preproc.cc @@ -109,6 +109,12 @@ #include // POSIX definition of wait() #endif // defined(hpux) || defined(__hpux) +#if defined(__linux__) +#include // POSIX definitions +#include // +#include // POSIX definition of wait() +#endif // defined(__linux__) + #ifdef __NT__ #include #include - --- omniorb-2.2.0.orig/src/tool/omniidl2/fe/lex.yy.cc +++ omniorb-2.2.0/src/tool/omniidl2/fe/lex.yy.cc @@ -181,6 +181,7 @@ static char *__yytext = (char *) yytext; # define YYNEWLINE 10 +int yylex(){ int nstr; extern int yyprevious; #ifdef __cplusplus @@ -678,7 +679,7 @@ char *r = buf; char *h; char *j; - - int count=0,jcount=0; + unsigned int count=0,jcount=0; UTL_String *nm; /* Skip initial '#' */ - --- omniorb-2.2.0.orig/src/tool/omniidl2/fe/Makefile +++ omniorb-2.2.0/src/tool/omniidl2/fe/Makefile @@ -30,6 +30,9 @@ $(RANLIB) $@; \ ) +lex.yy.o: lex.yy.cc + $(CXX) -c $(CPPFLAGS) -o $@ $< + # # We don't seem to be able to regenerate y.tab.cc y.tab.hh and lex.yy.cc # (at least on OSF) - --- omniorb-2.2.0.orig/src/tool/omniidl2/util/utl_scope.cc +++ omniorb-2.2.0/src/tool/omniidl2/util/utl_scope.cc @@ -331,7 +331,7 @@ if (a == NULL) return NULL; a->set_added(I_TRUE); if (!a->field_type()->added()) { - - return add_type(a->field_type()) ? a : NULL; + return add_type(a->field_type()) ? a : (AST_Attribute *)NULL; } else return a; } @@ -341,7 +341,7 @@ if (o == NULL) return NULL; o->set_added(I_TRUE); if (!o->return_type()->added()) { - - return add_type(o->return_type()) ? o : NULL; + return add_type(o->return_type()) ? o : (AST_Operation *)NULL; } else return o; } @@ -351,7 +351,7 @@ if (a == NULL) return NULL; a->set_added(I_TRUE); if (!a->field_type()->added()) { - - return add_type(a->field_type()) ? a : NULL; + return add_type(a->field_type()) ? a : (AST_Argument *)NULL; } else return a; } @@ -368,7 +368,7 @@ if (u == NULL) return NULL; u->set_added(I_TRUE); if (!u->field_type()->added()) { - - return add_type(u->field_type()) ? u : NULL; + return add_type(u->field_type()) ? u : (AST_UnionBranch *)NULL; } else return u; } @@ -385,7 +385,7 @@ if (f == NULL) return NULL; f->set_added(I_TRUE); if (!f->field_type()->added()) { - - return add_type(f->field_type()) ? f : NULL; + return add_type(f->field_type()) ? f : (AST_Field *)NULL; } else return f; } @@ -409,7 +409,7 @@ if (t == NULL) return NULL; t->set_added(I_TRUE); if (!t->base_type()->added()) { - - return add_type(t->base_type()) ? t : NULL; + return add_type(t->base_type()) ? t : (AST_Typedef *)NULL; } else return t; } @@ -419,7 +419,7 @@ if (s == NULL) return NULL; s->set_added(I_TRUE); if (!s->base_type()->added()) { - - return add_type(s->base_type()) ? s : NULL; + return add_type(s->base_type()) ? s : (AST_Sequence *)NULL; } else return s; } @@ -436,7 +436,7 @@ if (a == NULL) return NULL; a->set_added(I_TRUE); if (!a->base_type()->added()) { - - return add_type(a->base_type()) ? a : NULL; + return add_type(a->base_type()) ? a : (AST_Array *)NULL; } else return a; } - --- omniorb-2.2.0.orig/src/tool/omniidl2/util/utl_string.cc +++ omniorb-2.2.0/src/tool/omniidl2/util/utl_string.cc @@ -134,7 +134,7 @@ void UTL_String::canonicalize() { - - long i; + unsigned long i; for (i = 0; i < len; i++) c_str[i] = isalpha(p_str[i]) ? toupper(p_str[i]) : p_str[i]; - --- omniorb-2.2.0.orig/src/tool/omniidl2/util/utl_error.cc +++ omniorb-2.2.0/src/tool/omniidl2/util/utl_error.cc @@ -193,6 +193,8 @@ return "void"; case AST_Expression::EV_none: return "none"; + default: + return "unexpectedType"; } return 0; // for MSVC++ 4.2 } - --- omniorb-2.2.0.orig/src/tool/omniidl2/omniORB2_be/o2be_name.cc +++ omniorb-2.2.0/src/tool/omniidl2/omniORB2_be/o2be_name.cc @@ -67,10 +67,10 @@ // Check the pragmas attached to this node to see if // pragma ID is defined to override the default repositoryID. UTL_String* id; - - if (id = internal_search_pragma(pd_decl,"ID")) { + if ((id = internal_search_pragma(pd_decl,"ID"))) { return id->get_string(); } - - else if (id = internal_search_pragma(pd_decl,"version")) { + else if ((id = internal_search_pragma(pd_decl,"version"))) { // Check if pragma version is defined to override the // version number in the default repositoryID. char* p = strrchr(pd_repositoryID,':') + 1; - --- omniorb-2.2.0.orig/src/tool/omniidl2/omniORB2_be/o2be_exception.cc +++ omniorb-2.2.0/src/tool/omniidl2/omniORB2_be/o2be_exception.cc @@ -25,6 +25,11 @@ /* $Log: o2be_exception.cc,v $ + Revision 1.5 1997/08/13 09:23:38 sll + o2be_exception::repoIdConstLen() now returns the correct length of the + repository ID. Previously, it wrongly returns the length of the header macro + name. + // Revision 1.4 1997/05/06 13:54:46 sll // Public release. // @@ -45,7 +50,7 @@ pd_repoid = new char[strlen(_fqname())+strlen(IRREPOID_POSTFIX)+1]; strcpy(pd_repoid,_fqname()); strcat(pd_repoid,IRREPOID_POSTFIX); - - pd_repoidsize = strlen(pd_repoid)+1; + pd_repoidsize = strlen(repositoryID())+1; } void - --- omniorb-2.2.0.orig/src/tool/omniidl2/omniORB2_be/o2be_array.cc +++ omniorb-2.2.0/src/tool/omniidl2/omniORB2_be/o2be_array.cc @@ -123,7 +123,7 @@ { size_t dim = 1; AST_Expression **d = dims(); - - int i; + unsigned int i; for (i=0; i < n_dims(); i++) { AST_Expression::AST_ExprValue *v = d[i]->ev(); - --- omniorb-2.2.0.orig/src/tool/omniidl2/omniORB2_be/o2be_union.cc +++ omniorb-2.2.0/src/tool/omniidl2/omniORB2_be/o2be_union.cc @@ -2037,7 +2037,7 @@ return I_TRUE; break; case AST_PredefinedType::PT_boolean: - - if (bv->u.bval == v.b_val) + if ((long)bv->u.bval == v.b_val) return I_TRUE; break; default: - --- omniorb-2.2.0.orig/src/appl/utils/catior/catior.cc +++ omniorb-2.2.0/src/appl/utils/catior/catior.cc @@ -28,6 +28,10 @@ #include #include + +#if defined(__linux__) +#include +#endif @@ -165,7 +169,7 @@ cerr << "Type ID: \"" << (char*) repoID << "\"" << endl; cerr << "Profiles:" << endl; - - for (long count=0; count < profiles->length(); count++) + for (unsigned long count=0; count < profiles->length(); count++) { cout << count+