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