From dharter@sopragroup.com Wed Jun 2 04:52:20 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by menubar.gnome.org (Postfix) with ESMTP id 35D8E3B078A for ; Wed, 2 Jun 2004 04:52:20 -0400 (EDT) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i528qIr4010704 for ; Wed, 2 Jun 2004 10:52:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4487E.E8CC79F4" Date: Wed, 2 Jun 2004 10:52:18 +0200 Message-ID: <51043592743D154DA9C89694EDA1DD09016390BE@WEXCHBE02-VS.ptx.fr.sopra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Orbit NamingService Example Thread-Index: AcRIfui7sVIWDhgGQaemfbsv6Qq+sw== From: "Harter Damien" To: X-OriginalArrivalTime: 02 Jun 2004 08:52:56.0421 (UTC) FILETIME=[FF946150:01C4487E] X-Scanned-By: MIMEDefang 2.38 X-Mailman-Approved-At: Thu, 03 Jun 2004 00:29:25 -0400 Subject: Orbit NamingService Example X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 08:52:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4487E.E8CC79F4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, Does anyone have an example (a server and a remote client) using the = orbit Naming Service ?=20 Thks for help ------_=_NextPart_001_01C4487E.E8CC79F4 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Orbit NamingService Example

Hello,
Does anyone have an example (a server and a remote client) using the = orbit Naming Service ?
Thks for help

------_=_NextPart_001_01C4487E.E8CC79F4-- From dharter@sopragroup.com Wed Jun 2 10:36:56 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by menubar.gnome.org (Postfix) with ESMTP id DA9653B06DF for ; Wed, 2 Jun 2004 10:36:55 -0400 (EDT) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i52Eaor4016885 for ; Wed, 2 Jun 2004 16:36:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C448AF.0A3D3D6E" Date: Wed, 2 Jun 2004 16:36:50 +0200 Message-ID: <51043592743D154DA9C89694EDA1DD09016390C2@WEXCHBE02-VS.ptx.fr.sopra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Java client - Orbit : Can it work ? Thread-Index: AcRIrwo4dBngv8ybRq2RoFouj6FvyA== From: "Harter Damien" To: X-OriginalArrivalTime: 02 Jun 2004 14:37:28.0843 (UTC) FILETIME=[214DA5B0:01C448AF] X-Scanned-By: MIMEDefang 2.38 X-Mailman-Approved-At: Thu, 03 Jun 2004 00:29:25 -0400 Subject: Java client - Orbit : Can it work ? X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 14:36:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C448AF.0A3D3D6E Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I want make my Java client and my C server communicate. I want to user = sun's orb and orbit but I don't find any example... Does anyone have one = ? Thanks for help ------_=_NextPart_001_01C448AF.0A3D3D6E Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Java client - Orbit : Can it work ?

Hello,
I want make my Java client and my C server communicate. I want to user = sun's orb and orbit but I don't find any example... Does anyone have one = ?
Thanks for help

------_=_NextPart_001_01C448AF.0A3D3D6E-- From michael@ximian.com Fri Jun 4 11:40:18 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 4D0883B0ED8 for ; Fri, 4 Jun 2004 11:40:18 -0400 (EDT) Received: (qmail 10598 invoked from network); 4 Jun 2004 15:40:17 -0000 Received: from localhost (HELO linux00061bd92e62.dnsdhcp.provo.novell.com) (michael@127.0.0.1) by localhost with SMTP; 4 Jun 2004 15:40:17 -0000 From: Michael Meeks To: Harter Damien In-Reply-To: <51043592743D154DA9C89694EDA1DD09016390C2@WEXCHBE02-VS.ptx.fr.sopra> References: <51043592743D154DA9C89694EDA1DD09016390C2@WEXCHBE02-VS.ptx.fr.sopra> Content-Type: text/plain Organization: Ximian. Date: Fri, 04 Jun 2004 09:36:17 -0600 Message-Id: <1086363378.19147.28.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.8 Content-Transfer-Encoding: 7bit Cc: Bill Haneman , orbit Subject: ORBit2/Java X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 15:40:18 -0000 On Wed, 2004-06-02 at 16:36 +0200, Harter Damien wrote: > I want make my Java client and my C server communicate. I want to user > sun's orb and orbit but I don't find any example... Does anyone have > one ? This is one of the things that is frequently tested; quite possibly you can get some stuff out of the a11y work; I'm sure Bill can point you in the right direction. Regards, Michael. -- michael@ximian.com <><, Pseudo Engineer, itinerant idiot From Bill.Haneman@Sun.COM Fri Jun 4 11:43:26 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by menubar.gnome.org (Postfix) with ESMTP id 5257C3B0EC6 for ; Fri, 4 Jun 2004 11:43:26 -0400 (EDT) Received: from phys-eris-1 ([129.156.85.25]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i54FhPcP002702 for ; Fri, 4 Jun 2004 09:43:25 -0600 (MDT) Received: from conversion-daemon.eris-mail1.uk.sun.com by eris-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0HYS00E01JK2FS@eris-mail1.uk.sun.com> (original mail from Bill.Haneman@Sun.COM) for orbit-list@gnome.org; Fri, 04 Jun 2004 16:43:24 +0100 (BST) Received: from linux.local (dbl-isdn-100.Ireland.Sun.COM [129.156.227.100]) by eris-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0HYS00C1EJO929@eris-mail1.uk.sun.com>; Fri, 04 Jun 2004 16:43:21 +0100 (BST) Date: Fri, 04 Jun 2004 16:42:00 +0100 From: Bill Haneman In-reply-to: <1086363378.19147.28.camel@linux.site> To: Michael Meeks Message-id: <1086363720.18988.13.camel@linux.local> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Content-type: text/plain Content-transfer-encoding: 7BIT References: <51043592743D154DA9C89694EDA1DD09016390C2@WEXCHBE02-VS.ptx.fr.sopra> <1086363378.19147.28.camel@linux.site> Cc: orbit , Harter Damien Subject: Re: ORBit2/Java X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 15:43:26 -0000 On Fri, 2004-06-04 at 16:36, Michael Meeks wrote: > On Wed, 2004-06-02 at 16:36 +0200, Harter Damien wrote: > > I want make my Java client and my C server communicate. I want to user > > sun's orb and orbit but I don't find any example... Does anyone have > > one ? Hi Harter: Why don't you have a look in cvs module "java-access-bridge"... it has both client and server code in Java which talks to ORBit2. Note that you need a not-too-old Sun JVM for this to work; I believe it began working properly in 1.3.1 but 1.4 is probably required to build java-access-bridge (configure will tell you ;-)) Let me know if you have specific questions from that point. - Bill > > This is one of the things that is frequently tested; quite possibly you > can get some stuff out of the a11y work; I'm sure Bill can point you in > the right direction. > > Regards, > > Michael. > > -- > michael@ximian.com <><, Pseudo Engineer, itinerant idiot > > From dharter@sopragroup.com Mon Jun 7 02:58:17 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by menubar.gnome.org (Postfix) with ESMTP id 6FB4B3B0ADD for ; Mon, 7 Jun 2004 02:58:17 -0400 (EDT) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i576wGr4021090 for ; Mon, 7 Jun 2004 08:58:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44C5C.CE91F460" Date: Mon, 7 Jun 2004 08:58:15 +0200 Message-ID: <51043592743D154DA9C89694EDA1DD09016390D3@WEXCHBE02-VS.ptx.fr.sopra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Orbit2 Name Service Problems Thread-Index: AcRMXM6N9r+9wax1RcyGfKB29qceHw== From: "Harter Damien" To: X-OriginalArrivalTime: 07 Jun 2004 06:59:04.0093 (UTC) FILETIME=[EB429CD0:01C44C5C] X-Scanned-By: MIMEDefang 2.38 Subject: Orbit2 Name Service Problems X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 06:58:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C44C5C.CE91F460 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KQXMgSSBzYWlkIHRvIEJpbGwsIEkndmUgYSBwcm9ibGVtIHdpdGggdGhlIE9yYml0MiBu YW1lIHNlcnZpY2UsIHRoZSBzYW1lIGFzIDoNCm1haWwuZ25vbWUub3JnL2FyY2hpdmVzL29yYml0 LWxpc3QvMjAwMy1qdWx5L21zZzAwMDQ5Lmh0bWwuDQpJIHRyaWVkIHRvIHJ1biB0aGUgTmFtZSBS ZXNvbHZlIGV4YW1wbGUgdW5kZXIgUmVkaGF0IDkgYW5kIDcuMiA6DQokb3JiaXQtbmFtZS1zZXJ2 ZXIgPiB+L2lvci5yZWYNCiQuL25hbWUtcmVzb2x2ZS1zZXJ2ZXIgLU9SQkluaXRSZWYgTmFtZVNl cnZpY2U9YGNhdCB+L2lvci5yZWZgDQpCaW5kaW5nIHNlcnZpY2UgcmVmZXJlbmNlIGF0IG5hbWUg c2VydmljZSBhZ2FpbnN0IGlkOiBFeGFtcGxlcy9OYW1lUmVzb2x2ZS9TZXJ2aWNlDQogDQoqKiBF UlJPUiAqKjogZmFpbGVkIGJpbmRpbmcgb2Ygc2VydmljZSBPREw6b21nLm9yZy9DT1JCQS9JTlZf T0JKUkVGOjEuMA0KYWJvcnRpbmcuLi4NCmFiYW5kb24NCiANCkkndmUgdGhlIHNhbWUgaXNzdWUg aWYgSSB3cm90ZSB0aGUgbmFtZSBzZXJ2aWNlIGlvciBwcmludGVkIGJ5IG9yYml0IG5hbWUgc2Vy dmVyIGluc3RlYWQgb2YgYGNhdCB+L2lvci5yZWZgLg0KIA0KSGVyZSBzb21lIGluZm9ybWF0aW9u IHRoYXQgbWF5IGhlbHAgOg0KJGNhdCB+Ly5vcmJpdHJjDQpPUkJJSU9QVVNvY2s9MQ0KT1JCSUlP UElQdjQ9MQ0KT1JCSUlPUElQdjY9MA0KIA0KJGlvci1kZWNvZGUtMiBgY2F0IH4vaW9yLnJlZmAN Ck9iamVjdCBJRDogSURMOm9tZy5vcmcvQ29zTmFtaW5nL05hbWluZ0NvbnRleHQ6MS4wDQpJT1Bf VEFHX0lOVEVSTkVUX0lPUDogR0lPUCAxLjAgMTkyLjE2OC4uLi4uMTQzOjM1NDU0DQogICAgICAg IG9iamVjdF9rZXkgKDI0KSAnMDAwMDAwMDBkNTVmMzRiNzIxYS4uLmMzYicNCiRpb3ItZGVjb2Rl IGBjYXQgfi9pb3IucmVmYA0KVGFncyBrbm93bjoNClRBR19JTlRFUk5FVF9JT1A6IDB4MA0KVEFH X01VTFRJUExFX0NPTVBPTkVOVFM6IDB4MQ0KVEFHX09SQklUX1NQRUNJRklDOiAweGJhZGZhZWNh DQoNCk9iamVjdCBJRDogSURMOm9tZy5vcmcvQ29zTmFtaW5nL05hbWluZ0NvbnRleHQ6MS4wDQpQ cm9maWxlIGNvdW50OiAxDQoNClByb2ZpbGUgdHlwZTogVEFHX0lOVEVSTkVUX0lPUA0KT2JqZWN0 IGVuZGlhbjogTGl0dGxlDQpJSU9QIHZlcnNpb246IDEuMA0KSG9zdDogMTkyLjE2OC4yMDIuMTQz DQpQb3J0OiAzNTQ1NA0KT2JqZWN0IGtleTogIi4uLi4uXzQuIS5day4uLi4uZS4uM05MOyINCg0K VGhhbmtzIGZvciBoZWxwDQpEYW1pZW4NCiANCiANCg== ------_=_NextPart_001_01C44C5C.CE91F460 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj48SFRNTD48SEVBRD48TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PC9IRUFEPjxCT0RZPjxESVY+QWxsLDwvRElWPgo8 RElWPkFzIEkgc2FpZCB0byBCaWxsLCBJJ3ZlIGEgcHJvYmxlbSB3aXRoIHRoZSBPcmJpdDIgbmFt ZSBzZXJ2aWNlLCB0aGUgc2FtZSBhcyAKOjwvRElWPgo8RElWPm1haWwuZ25vbWUub3JnL2FyY2hp dmVzL29yYml0LWxpc3QvMjAwMy1qdWx5L21zZzAwMDQ5Lmh0bWwuPC9ESVY+CjxESVY+SSB0cmll ZCB0byBydW4gdGhlIE5hbWUgUmVzb2x2ZSBleGFtcGxlIHVuZGVyIFJlZGhhdCA5IGFuZCA3LjIg OjwvRElWPgo8RElWPjxTVFJPTkc+JG9yYml0LW5hbWUtc2VydmVyICZndDsgfi9pb3IucmVmPC9T VFJPTkc+PC9ESVY+CjxESVY+PFNUUk9ORz4kLi9uYW1lLXJlc29sdmUtc2VydmVyIC1PUkJJbml0 UmVmIE5hbWVTZXJ2aWNlPWBjYXQgCn4vaW9yLnJlZmA8L1NUUk9ORz48L0RJVj4KPERJVj48U1RS T05HPkJpbmRpbmcgc2VydmljZSByZWZlcmVuY2UgYXQgbmFtZSBzZXJ2aWNlIGFnYWluc3QgaWQ6 IApFeGFtcGxlcy9OYW1lUmVzb2x2ZS9TZXJ2aWNlPC9TVFJPTkc+PC9ESVY+CjxESVY+PFNUUk9O Rz48L1NUUk9ORz4mbmJzcDs8L0RJVj4KPERJVj48U1RST05HPioqIEVSUk9SICoqOiBmYWlsZWQg YmluZGluZyBvZiBzZXJ2aWNlIApPREw6b21nLm9yZy9DT1JCQS9JTlZfT0JKUkVGOjEuMDwvU1RS T05HPjwvRElWPgo8RElWPjxTVFJPTkc+YWJvcnRpbmcuLi48L1NUUk9ORz48L0RJVj4KPERJVj48 U1RST05HPmFiYW5kb248L1NUUk9ORz48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JJ3Zl IHRoZSBzYW1lIGlzc3VlIGlmIEkgd3JvdGUgdGhlIG5hbWUgc2VydmljZSBpb3IgcHJpbnRlZCBi eSBvcmJpdCBuYW1lIApzZXJ2ZXIgaW5zdGVhZCBvZiBgY2F0IH4vaW9yLnJlZmAuPC9ESVY+CjxE SVY+Jm5ic3A7PC9ESVY+CjxESVY+SGVyZSBzb21lIGluZm9ybWF0aW9uIHRoYXQgbWF5IGhlbHAg OjwvRElWPgo8RElWPjxTVFJPTkc+JGNhdCB+Ly5vcmJpdHJjPC9TVFJPTkc+PC9ESVY+CjxESVY+ PFNUUk9ORz5PUkJJSU9QVVNvY2s9MTwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+T1JCSUlP UElQdjQ9MTwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+T1JCSUlPUElQdjY9MDwvU1RST05H PjwvRElWPgo8RElWPjxTVFJPTkc+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+CjxESVY+PFNUUk9ORz4k aW9yLWRlY29kZS0yIGBjYXQgfi9pb3IucmVmYDwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+ T2JqZWN0IElEOiBJREw6b21nLm9yZy9Db3NOYW1pbmcvTmFtaW5nQ29udGV4dDoxLjA8L1NUUk9O Rz48L0RJVj4KPERJVj48U1RST05HPklPUF9UQUdfSU5URVJORVRfSU9QOiBHSU9QIDEuMCAxOTIu MTY4Li4uLi4xNDM6MzU0NTQ8L1NUUk9ORz48L0RJVj4KPERJVj48U1RST05HPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvYmplY3Rfa2V5ICgyNCkgCicwMDAwMDAw MGQ1NWYzNGI3MjFhLi4uYzNiJzwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+JGlvci1kZWNv ZGUgYGNhdCB+L2lvci5yZWZgPC9TVFJPTkc+PC9ESVY+CjxESVY+PFBSRT48U1RST05HPlRhZ3Mg a25vd246ClRBR19JTlRFUk5FVF9JT1A6IDB4MApUQUdfTVVMVElQTEVfQ09NUE9ORU5UUzogMHgx ClRBR19PUkJJVF9TUEVDSUZJQzogMHhiYWRmYWVjYQoKT2JqZWN0IElEOiBJREw6b21nLm9yZy9D b3NOYW1pbmcvTmFtaW5nQ29udGV4dDoxLjAKUHJvZmlsZSBjb3VudDogMQoKUHJvZmlsZSB0eXBl OiBUQUdfSU5URVJORVRfSU9QCk9iamVjdCBlbmRpYW46IExpdHRsZQpJSU9QIHZlcnNpb246IDEu MApIb3N0OiAxOTIuMTY4LjIwMi4xNDMKUG9ydDogMzU0NTQKT2JqZWN0IGtleTogIi4uLi4uXzQu IS5day4uLi4uZS4uM05MOyI8L1NUUk9ORz4KClRoYW5rcyBmb3IgaGVscDwvUFJFPjxQUkU+RGFt aWVuPC9QUkU+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZ PjwvSFRNTD4= ------_=_NextPart_001_01C44C5C.CE91F460-- From fta@cube.opentransit.net Wed Jun 9 09:18:56 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from cube.opentransit.net (cube.opentransit.net [193.251.151.83]) by menubar.gnome.org (Postfix) with ESMTP id 5A7043B0D1A for ; Wed, 9 Jun 2004 09:18:56 -0400 (EDT) Received: from cube.opentransit.net (nobody@localhost [127.0.0.1]) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) with ESMTP id i59DIrl8006776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2004 15:18:53 +0200 Received: (from fta@localhost) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) id i59DIqbe006775; Wed, 9 Jun 2004 15:18:52 +0200 Date: Wed, 9 Jun 2004 15:18:52 +0200 From: Fabien Tassin To: orbit-list@gnome.org Message-ID: <20040609131852.GC4335@opentransit.net> References: <20040531142520.GA2160@opentransit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040531142520.GA2160@opentransit.net> User-Agent: Mutt/1.5.6+20040523i Subject: Re: problems with remote NameService calls X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 13:18:56 -0000 Anyone to help me with that ? /Fabien According to Fabien Tassin: > Date: Mon, 31 May 2004 16:25:21 +0200 > > Hi, > > I have an Orbit2 client talking to a remote non-Orbit server. > It works well when used with a (fixed) IOR read with > client_import_service_from_stream(). > I now wish to use the NameService on the remote ORB to get the IOR > dynamically.. but it doesn't work. > > Here is a minimalistic piece of code. > > == > /* ... */ > orb = CORBA_ORB_init(&argc, argv, "orbit-local-orb", ev); > abort_if_exception(ev, "CORBA_ORB_init() failed"); > > nameservice = CORBA_ORB_resolve_initial_references(orb, "NameService", ev); > abort_if_exception(ev, "resolve_initial_references(NameService) failed"); > > context = (CosNaming_NamingContext) nameservice; > g_assert(!CORBA_Object_is_nil(context, ev)); > > CosNaming_NamingContext_list(context, 0, &bl, &bi, ev); > abort_if_exception(ev, "list() failed"); > g_assert(!CORBA_Object_is_nil(bi, ev)); > /* ... */ > == > > I invoke this using -ORBInitRef NameService=corbaloc::remote:port/NameService > It goes into an infinite loop in CosNaming_NamingContext_list(). > > ethereal+strace show that the CORBA_ORB_resolve_initial_references() call is > not made against the remote ORB but against the local one (from my > Gnome2 desktop, reading /tmp/orbit-myuser). > CosNaming_NamingContext_list() talks to the remote ORB but loops.. > [ Request (two-way): list -> Reply: Location Forward ] > I assume this is because 'nameservice' is wrong. > > I'm quite sure it is a problem with my client code (or Orbit2) > as 'nameclt' from omniorb4 works perfectly. > (nameclt -ORBInitRef NameService=corbaloc::remote:port/NameService list) > > Maybe I missed something or did something wrong.. > > $ orbit2-config --version > ORBit2 2.10.2 > > Thoughts ? > > /Fabien > _______________________________________________ > orbit-list mailing list > orbit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/orbit-list From fta@cube.opentransit.net Wed Jun 9 10:16:59 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from cube.opentransit.net (cube.opentransit.net [193.251.151.83]) by menubar.gnome.org (Postfix) with ESMTP id 127AB3B0D83 for ; Wed, 9 Jun 2004 10:16:59 -0400 (EDT) Received: from cube.opentransit.net (nobody@localhost [127.0.0.1]) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) with ESMTP id i59EGovs008176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2004 16:16:50 +0200 Received: (from fta@localhost) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) id i59EGoT3008175; Wed, 9 Jun 2004 16:16:50 +0200 Date: Wed, 9 Jun 2004 16:16:50 +0200 From: Fabien Tassin To: Olivier Andrieu Message-ID: <20040609141650.GD4335@opentransit.net> References: <20040531142520.GA2160@opentransit.net> <20040609131852.GC4335@opentransit.net> <20040609.155540.77832197.andrieu@ijm.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040609.155540.77832197.andrieu@ijm.jussieu.fr> User-Agent: Mutt/1.5.6+20040523i Cc: orbit-list@gnome.org Subject: Re: problems with remote NameService calls X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 14:16:59 -0000 According to Olivier Andrieu: > > Fabien Tassin [Wed, 9 Jun 2004 15:18:52 +0200]: > > Anyone to help me with that ? > > reading ORBit code, I see that ORBit_object_by_corbaloc starts by a > strcmp with "corbaloc::/". So maybe it doesn't like your corbaloc > syntax ? nope, both works. Otherwise, I'll get 'WARNING **: Option ORBInitRef has invalid object reference' All those are accepted and behave the same.. ie wrongly -ORBInitRef NameService=corbaloc::remote_host:remote_port/NameService -ORBInitRef NameService=corbaloc::/remote_host:remote_port/NameService -ORBInitRef NameService=corbaloc:://remote_host:remote_port/NameService -ORBInitRef NameService=corbaloc:iiop:remote_host:remote_port/NameService -ORBInitRef NameService=corbaloc:iiop:/remote_host:remote_port/NameService -ORBInitRef NameService=corbaloc:iiop://remote_host:remote_port/NameService CosNaming_NamingContext_list() talks to remote_host:remote_port but not CORBA_ORB_resolve_initial_references(). That's my problem. I've tried all variations of -ORBIIOPIPv4 and -ORBIIOPUNIX, no change. /Fabien From Frank.Rehberger@web.de Wed Jun 9 12:43:40 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by menubar.gnome.org (Postfix) with ESMTP id 45A843B0CD2 for ; Wed, 9 Jun 2004 12:43:40 -0400 (EDT) Received: from pd9e81321.dip0.t-ipconnect.de ([217.232.19.33] helo=web.de) by smtp06.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #91) id 1BY6Ao-0000gl-00; Wed, 09 Jun 2004 18:43:34 +0200 Message-ID: <40C73E25.5060205@web.de> Date: Wed, 09 Jun 2004 18:43:17 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harter Damien References: <51043592743D154DA9C89694EDA1DD09016390D3@WEXCHBE02-VS.ptx.fr.sopra> In-Reply-To: <51043592743D154DA9C89694EDA1DD09016390D3@WEXCHBE02-VS.ptx.fr.sopra> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Frank.Rehberger@web.de Cc: orbit-list@gnome.org Subject: Re: Orbit2 Name Service Problems X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 16:43:40 -0000 Harter Damien wrote: > All, > As I said to Bill, I've a problem with the Orbit2 name service, the > same as : > mail.gnome.org/archives/orbit-list/2003-july/msg00049.html. > I tried to run the Name Resolve example under Redhat 9 and 7.2 : > *$orbit-name-server > ~/ior.ref* > *$./name-resolve-server -ORBInitRef NameService=`cat ~/ior.ref`* > *Binding service reference at name service against id: > Examples/NameResolve/Service* > ** > *** ERROR **: failed binding of service ODL:omg.org/CORBA/INV_OBJREF:1.0* > *aborting...* > *abandon* > This error shows up, if and only if you call remote operation with NULL-Object, please verify operation string_to_object returns valid binary object reference. My feeling is, the content of ~/ior.ref is not read completely, please can you change the implementation of *name-resolve-server.c so that it prints read content to terminal, Regards, Frank * > I've the same issue if I wrote the name service ior printed by orbit > name server instead of `cat ~/ior.ref`. > > Here some information that may help : > *$cat ~/.orbitrc* > *ORBIIOPUSock=1* > *ORBIIOPIPv4=1* > *ORBIIOPIPv6=0* > ** > *$ior-decode-2 `cat ~/ior.ref`* > *Object ID: IDL:omg.org/CosNaming/NamingContext:1.0* > *IOP_TAG_INTERNET_IOP: GIOP 1.0 192.168.....143:35454* > * object_key (24) '00000000d55f34b721a...c3b'* > *$ior-decode `cat ~/ior.ref`* > >*Tags known: >TAG_INTERNET_IOP: 0x0 >TAG_MULTIPLE_COMPONENTS: 0x1 >TAG_ORBIT_SPECIFIC: 0xbadfaeca > >Object ID: IDL:omg.org/CosNaming/NamingContext:1.0 >Profile count: 1 > >Profile type: TAG_INTERNET_IOP >Object endian: Little >IIOP version: 1.0 >Host: 192.168.202.143 >Port: 35454 >Object key: "....._4.!.]k.....e..3NL;"* > >Thanks for help > >Damien > > > > >------------------------------------------------------------------------ > >_______________________________________________ >orbit-list mailing list >orbit-list@gnome.org >http://mail.gnome.org/mailman/listinfo/orbit-list > > From andrieu@ijm.jussieu.fr Wed Jun 9 09:55:43 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by menubar.gnome.org (Postfix) with ESMTP id 4A68C3B0D74 for ; Wed, 9 Jun 2004 09:55:43 -0400 (EDT) Received: from localhost (akasha.ijm.jussieu.fr [134.157.173.57]) by shiva.jussieu.fr (8.12.11/jtpda-5.4) with ESMTP id i59DtgcP082838 ; Wed, 9 Jun 2004 15:55:42 +0200 (CEST) X-Ids: 165 Date: Wed, 09 Jun 2004 15:55:40 +0200 (CEST) Message-Id: <20040609.155540.77832197.andrieu@ijm.jussieu.fr> To: fta+orbit@sofaraway.org From: Olivier Andrieu In-Reply-To: <20040609131852.GC4335@opentransit.net> References: <20040531142520.GA2160@opentransit.net> <20040609131852.GC4335@opentransit.net> X-Mailer: Mew version 4.0.64 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at shiva.jussieu.fr with ID 40C716DE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr X-Mailman-Approved-At: Thu, 10 Jun 2004 02:38:53 -0400 Cc: orbit-list@gnome.org Subject: Re: problems with remote NameService calls X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 13:55:44 -0000 Fabien Tassin [Wed, 9 Jun 2004 15:18:52 +0200]: > Anyone to help me with that ? reading ORBit code, I see that ORBit_object_by_corbaloc starts by a strcmp with "corbaloc::/". So maybe it doesn't like your corbaloc syntax ? > > I invoke this using -ORBInitRef NameService=corbaloc::remote:port/NameService > > It goes into an infinite loop in CosNaming_NamingContext_list(). -- Oliv From dharter@sopragroup.com Thu Jun 10 03:25:30 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by menubar.gnome.org (Postfix) with ESMTP id 66FE93B0701 for ; Thu, 10 Jun 2004 03:25:29 -0400 (EDT) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i5A7PPr4003753; Thu, 10 Jun 2004 09:25:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44EBC.18F379AC" Date: Thu, 10 Jun 2004 09:25:25 +0200 Message-ID: <51043592743D154DA9C89694EDA1DD09016390F7@WEXCHBE02-VS.ptx.fr.sopra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Orbit2 Name Service Problems Thread-Index: AcROQO0moUf5Oq/eQFe2yaLidufj3QAeQ5eO From: "Harter Damien" To: "Frank Rehberger" X-OriginalArrivalTime: 10 Jun 2004 07:26:18.0343 (UTC) FILETIME=[38969F70:01C44EBC] X-Scanned-By: MIMEDefang 2.38 Cc: orbit-list@gnome.org Subject: =?utf-8?q?RE=C2=A0=3A_Orbit2_Name_Service_Problems?= X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 07:25:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C44EBC.18F379AC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB1cGRhdGVkIHRoZSBuYW1lLXJlc29sdmUtc2VydmVyIGNvZGUgYXMgeW91IHNhaWQgOg0KSSBo YWQgdGhlIDMgZm9sbG93aW5nIGxpbmVzIGludCBoZSBtYWluKCksIGp1c3QgYmVmb3JlIGV0a19n ZXRfbmFtZV9zZXJ2aWNlKCkgOg0KcHJpbnRmKCJJT1IgU3RyaW5nID0gJXNcbiIsIGFyZ3ZbMl0p IDsNCnByaW50ZigiT1JCIHJlZiA9ICVwXG4sIGdsb2JhbF9vcmIpIDsNCnByaW50ZigiTlMgUmVm ID0gJXBcbiIsIHN0cmluZ190b19vYmplY3QoZ2xvYmFsX29yYiwgYXJndlsyXSwgZXYpKSA7DQou Li4NCkkgYWxzbyBoYWQgaW4gZXRrX2dldF9uYW1lX3NlcnZpY2UoLi4uKSBmcm9tIGV4YW1wbGVz X3Rvb2xraXQuYyA6DQouLi4NCmlmIChldGtfcmFpc2VkX2V4Y2VwdGlvbihldikpDQp7DQogICAg cHJpbnRmKCJDb3JiYSBOSUwuLi4gTm9vb28hXG4iKSA7DQogICAgcmV0dXJuIENPUkJBX09CSkVD VF9OSUwgOw0KfQ0KLi4uDQogDQphbmQgdGhlIHRlcm1pbmFsIHByaW50cyA6DQokLi9uYW1lX3Jl c29sdmVfc2VydmVyIC1PUkJJbml0UmVmIE5hbWVTZXJ2aWNlPWBjYXQgfi9pb3IucmVmYA0KSU9S IFN0cmluZyA6IE5hbWVTZXJ2aWNlPUlPUjowMTAwMDAwMDI4MDAwMDAwNDk0NDRjM2E2ZjZkNjcy ZTZmNzI2NzJmNDM2ZjczNGU2MTZkNjk2ZTY3MmY0ZTYxNmQ2OTZlNjc0MzZmNmU3NDY1Nzg3NDNh MzEyZTMwMDAwMjAwMDAwMGNhYWVkZmJhNTQwMDAwMDAwMTAxMDAwMDJiMDAwMDAwMmY3NDZkNzAy ZjZmNzI2MjY5NzQyZDY0Njg2MTcyNzQ2NTcyMmY2ZjcyNjIyZDMxMzIzNjMzMzAzMzMxMzkzNjM4 MzQzOTM1MzkzOTM5MzgzOTM2MDAwMDAwMDAwMDAwMTgwMDAwMDAwMDAwMDAwMDlmY2M4NTQwMmRh ZTQxOTYwMTAwMDAwMGIzMGQzYWI1YmQzZDkwM2EwMDAwMDAwMDM4MDAwMDAwMDEwMTAwMDAxMDAw MDAwMDMxMzkzMjJlMzEzNjM4MmUzMjMwMzIyZTMxMzQzMzAwOTljZjAwMDAxODAwMDAwMDAwMDAw MDAwOWZjYzg1NDAyZGFlNDE5NjAxMDAwMDAwYjMwZDNhYjViZDNkOTAzYQ0KDQpPUkIgUmVmIDog MHg4MDUxMmY4DQpOUyBSZWYgOiAobmlsKQ0KQmluZGluZyBzZXJ2aWNlIHJlZmVyZW5jZSBhdCBu YW1lIHNlcnZpY2UgYWdhaW5zdCBpZDogRXhhbXBsZXMvTmFtZVJlc29sdmUvU2VydmljZQ0KDQpD b3JiYSBOaWwuLi4gTm9vbyAhDQokY2F0IH4vaW9yLnJlZg0KSU9SOjAxMDAwMDAwMjgwMDAwMDA0 OTQ0NGMzYTZmNmQ2NzJlNmY3MjY3MmY0MzZmNzM0ZTYxNmQ2OTZlNjcyZjRlNjE2ZDY5NmU2NzQz NmY2ZTc0NjU3ODc0M2EzMTJlMzAwMDAyMDAwMDAwY2FhZWRmYmE1NDAwMDAwMDAxMDEwMDAwMmIw MDAwMDAyZjc0NmQ3MDJmNmY3MjYyNjk3NDJkNjQ2ODYxNzI3NDY1NzIyZjZmNzI2MjJkMzEzMjM2 MzMzMDMzMzEzOTM2MzgzNDM5MzUzOTM5MzkzODM5MzYwMDAwMDAwMDAwMDAxODAwMDAwMDAwMDAw MDAwOWZjYzg1NDAyZGFlNDE5NjAxMDAwMDAwYjMwZDNhYjViZDNkOTAzYTAwMDAwMDAwMzgwMDAw MDAwMTAxMDAwMDEwMDAwMDAwMzEzOTMyMmUzMTM2MzgyZTMyMzAzMjJlMzEzNDMzMDA5OWNmMDAw MDE4MDAwMDAwMDAwMDAwMDA5ZmNjODU0MDJkYWU0MTk2MDEwMDAwMDBiMzBkM2FiNWJkM2Q5MDNh DQpUaGUgc3RyaW5ncyBhcmUgdGhlIHNhbWUuLi4gc28sIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0 IGhhcHBlbnMgKG9yIHdoYXQgZG9lc24ndCBoYXBwZW5zLi4uKSA/DQpUaGFua3MgZm9yIGFueSBo ZWxwDQoNCgktLS0tLS0tLSBNZXNzYWdlIGQnb3JpZ2luZS0tLS0tLS0tIA0KCURlOiBGcmFuayBS ZWhiZXJnZXIgW21haWx0bzpGcmFuay5SZWhiZXJnZXJAd2ViLmRlXSANCglEYXRlOiBtZXIuIDA5 LzA2LzIwMDQgMTg6NDMgDQoJw4A6IEhhcnRlciBEYW1pZW4gDQoJQ2M6IG9yYml0LWxpc3RAZ25v bWUub3JnIA0KCU9iamV0OiBSZTogT3JiaXQyIE5hbWUgU2VydmljZSBQcm9ibGVtcw0KCQ0KCQ0K DQoJSGFydGVyIERhbWllbiB3cm90ZToNCgkNCgk+IEFsbCwNCgk+IEFzIEkgc2FpZCB0byBCaWxs LCBJJ3ZlIGEgcHJvYmxlbSB3aXRoIHRoZSBPcmJpdDIgbmFtZSBzZXJ2aWNlLCB0aGUNCgk+IHNh bWUgYXMgOg0KCT4gbWFpbC5nbm9tZS5vcmcvYXJjaGl2ZXMvb3JiaXQtbGlzdC8yMDAzLWp1bHkv bXNnMDAwNDkuaHRtbC4NCgk+IEkgdHJpZWQgdG8gcnVuIHRoZSBOYW1lIFJlc29sdmUgZXhhbXBs ZSB1bmRlciBSZWRoYXQgOSBhbmQgNy4yIDoNCgk+ICokb3JiaXQtbmFtZS1zZXJ2ZXIgPiB+L2lv ci5yZWYqDQoJPiAqJC4vbmFtZS1yZXNvbHZlLXNlcnZlciAtT1JCSW5pdFJlZiBOYW1lU2Vydmlj ZT1gY2F0IH4vaW9yLnJlZmAqDQoJPiAqQmluZGluZyBzZXJ2aWNlIHJlZmVyZW5jZSBhdCBuYW1l IHNlcnZpY2UgYWdhaW5zdCBpZDoNCgk+IEV4YW1wbGVzL05hbWVSZXNvbHZlL1NlcnZpY2UqDQoJ PiAqKg0KCT4gKioqIEVSUk9SICoqOiBmYWlsZWQgYmluZGluZyBvZiBzZXJ2aWNlIE9ETDpvbWcu b3JnL0NPUkJBL0lOVl9PQkpSRUY6MS4wKg0KCT4gKmFib3J0aW5nLi4uKg0KCT4gKmFiYW5kb24q DQoJPiANCgkNCglUaGlzIGVycm9yIHNob3dzIHVwLCBpZiBhbmQgb25seSBpZiB5b3UgY2FsbCBy ZW1vdGUgb3BlcmF0aW9uIHdpdGgNCglOVUxMLU9iamVjdCwNCglwbGVhc2UgdmVyaWZ5IG9wZXJh dGlvbiBzdHJpbmdfdG9fb2JqZWN0IHJldHVybnMgdmFsaWQgYmluYXJ5IG9iamVjdA0KCXJlZmVy ZW5jZS4NCgkNCglNeSBmZWVsaW5nIGlzLCB0aGUgY29udGVudCBvZiB+L2lvci5yZWYgaXMgbm90 IHJlYWQgY29tcGxldGVseSwNCglwbGVhc2UgY2FuIHlvdSBjaGFuZ2UgdGhlIGltcGxlbWVudGF0 aW9uIG9mICpuYW1lLXJlc29sdmUtc2VydmVyLmMgc28NCgl0aGF0IGl0IHByaW50cyByZWFkIGNv bnRlbnQgdG8gdGVybWluYWwsDQoJDQoJUmVnYXJkcywgRnJhbmsNCgkNCgkqDQoJDQoJPiBJJ3Zl IHRoZSBzYW1lIGlzc3VlIGlmIEkgd3JvdGUgdGhlIG5hbWUgc2VydmljZSBpb3IgcHJpbnRlZCBi eSBvcmJpdA0KCT4gbmFtZSBzZXJ2ZXIgaW5zdGVhZCBvZiBgY2F0IH4vaW9yLnJlZmAuDQoJPiAN Cgk+IEhlcmUgc29tZSBpbmZvcm1hdGlvbiB0aGF0IG1heSBoZWxwIDoNCgk+ICokY2F0IH4vLm9y Yml0cmMqDQoJPiAqT1JCSUlPUFVTb2NrPTEqDQoJPiAqT1JCSUlPUElQdjQ9MSoNCgk+ICpPUkJJ SU9QSVB2Nj0wKg0KCT4gKioNCgk+ICokaW9yLWRlY29kZS0yIGBjYXQgfi9pb3IucmVmYCoNCgk+ ICpPYmplY3QgSUQ6IElETDpvbWcub3JnL0Nvc05hbWluZy9OYW1pbmdDb250ZXh0OjEuMCoNCgk+ ICpJT1BfVEFHX0lOVEVSTkVUX0lPUDogR0lPUCAxLjAgMTkyLjE2OC4uLi4uMTQzOjM1NDU0Kg0K CT4gKiAgICAgICAgb2JqZWN0X2tleSAoMjQpICcwMDAwMDAwMGQ1NWYzNGI3MjFhLi4uYzNiJyoN Cgk+ICokaW9yLWRlY29kZSBgY2F0IH4vaW9yLnJlZmAqDQoJPg0KCT4qVGFncyBrbm93bjoNCgk+ VEFHX0lOVEVSTkVUX0lPUDogMHgwDQoJPlRBR19NVUxUSVBMRV9DT01QT05FTlRTOiAweDENCgk+ VEFHX09SQklUX1NQRUNJRklDOiAweGJhZGZhZWNhDQoJPg0KCT5PYmplY3QgSUQ6IElETDpvbWcu b3JnL0Nvc05hbWluZy9OYW1pbmdDb250ZXh0OjEuMA0KCT5Qcm9maWxlIGNvdW50OiAxDQoJPg0K CT5Qcm9maWxlIHR5cGU6IFRBR19JTlRFUk5FVF9JT1ANCgk+T2JqZWN0IGVuZGlhbjogTGl0dGxl DQoJPklJT1AgdmVyc2lvbjogMS4wDQoJPkhvc3Q6IDE5Mi4xNjguMjAyLjE0Mw0KCT5Qb3J0OiAz NTQ1NA0KCT5PYmplY3Qga2V5OiAiLi4uLi5fNC4hLl1rLi4uLi5lLi4zTkw7IioNCgk+DQoJPlRo YW5rcyBmb3IgaGVscA0KCT4NCgk+RGFtaWVuDQoJPg0KCT4gDQoJPiANCgk+DQoJPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KCT4NCgk+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCgk+b3JiaXQtbGlzdCBtYWlsaW5nIGxpc3QNCgk+b3JiaXQtbGlzdEBnbm9tZS5vcmcN Cgk+aHR0cDovL21haWwuZ25vbWUub3JnL21haWxtYW4vbGlzdGluZm8vb3JiaXQtbGlzdA0KCT4g DQoJPg0KCQ0KCQ0KCQ0KDQo= ------_=_NextPart_001_01C44EBC.18F379AC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY1NTYuMCI+CjxUSVRMRT5SZTogT3JiaXQyIE5hbWUg U2VydmljZSBQcm9ibGVtczwvVElUTEU+CjwvSEVBRD4KPEJPRFkgZGlyPWx0cj4KPERJVj5JIHVw ZGF0ZWQgdGhlIG5hbWUtcmVzb2x2ZS1zZXJ2ZXIgY29kZSBhcyB5b3Ugc2FpZCA6PC9ESVY+CjxE SVY+SSBoYWQgdGhlIDMgZm9sbG93aW5nIGxpbmVzIGludCBoZSBtYWluKCksIGp1c3QgYmVmb3Jl IApldGtfZ2V0X25hbWVfc2VydmljZSgpJm5ic3A7OjwvRElWPgo8RElWPjxTVFJPTkc+cHJpbnRm KCJJT1IgU3RyaW5nID0gJXNcbiIsIGFyZ3ZbMl0pIDs8L1NUUk9ORz48L0RJVj4KPERJVj48U1RS T05HPnByaW50ZigiT1JCIHJlZiA9ICVwXG4sIGdsb2JhbF9vcmIpIDs8L1NUUk9ORz48L0RJVj4K PERJVj48U1RST05HPnByaW50ZigiTlMgUmVmID0gJXBcbiIsIHN0cmluZ190b19vYmplY3QoZ2xv YmFsX29yYiwgYXJndlsyXSwgZXYpKSAKOzwvU1RST05HPjwvRElWPgo8RElWPi4uLjwvRElWPgo8 RElWPkkgYWxzbyBoYWQgaW4gZXRrX2dldF9uYW1lX3NlcnZpY2UoLi4uKSBmcm9tIGV4YW1wbGVz X3Rvb2xraXQuYyA6PC9ESVY+CjxESVY+Li4uPC9ESVY+CjxESVY+aWYgKGV0a19yYWlzZWRfZXhj ZXB0aW9uKGV2KSk8L0RJVj4KPERJVj57PC9ESVY+CjxESVY+PFNUUk9ORz4mbmJzcDsmbmJzcDsm bmJzcDsgcHJpbnRmKCJDb3JiYSBOSUwuLi4gTm9vb28hXG4iKSA7PC9TVFJPTkc+PC9ESVY+CjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybiBDT1JCQV9PQkpFQ1RfTklMIDs8L0RJVj4KPERJ Vj59PC9ESVY+CjxESVY+Li4uPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+YW5kIHRoZSB0 ZXJtaW5hbCBwcmludHMgOjwvRElWPgo8RElWPjxQUkU+JC4vbmFtZV9yZXNvbHZlX3NlcnZlciAt T1JCSW5pdFJlZiBOYW1lU2VydmljZT1gY2F0IH4vaW9yLnJlZmA8L1BSRT48UFJFPklPUiBTdHJp bmcgOiBOYW1lU2VydmljZT1JT1I6MDEwMDAwMDAyODAwMDAwMDQ5NDQ0YzNhNmY2ZDY3MmU2Zjcy NjcyZjQzNmY3MzRlNjE2ZDY5NmU2NzJmNGU2MTZkNjk2ZTY3NDM2ZjZlNzQ2NTc4NzQzYTMxMmUz MDAwMDIwMDAwMDBjYWFlZGZiYTU0MDAwMDAwMDEwMTAwMDAyYjAwMDAwMDJmNzQ2ZDcwMmY2Zjcy NjI2OTc0MmQ2NDY4NjE3Mjc0NjU3MjJmNmY3MjYyMmQzMTMyMzYzMzMwMzMzMTM5MzYzODM0Mzkz NTM5MzkzOTM4MzkzNjAwMDAwMDAwMDAwMDE4MDAwMDAwMDAwMDAwMDA5ZmNjODU0MDJkYWU0MTk2 MDEwMDAwMDBiMzBkM2FiNWJkM2Q5MDNhMDAwMDAwMDAzODAwMDAwMDAxMDEwMDAwMTAwMDAwMDAz MTM5MzIyZTMxMzYzODJlMzIzMDMyMmUzMTM0MzMwMDk5Y2YwMDAwMTgwMDAwMDAwMDAwMDAwMDlm Y2M4NTQwMmRhZTQxOTYwMTAwMDAwMGIzMGQzYWI1YmQzZDkwM2EKCk9SQiBSZWYgOiAweDgwNTEy ZjgKTlMgUmVmIDogKG5pbCkKQmluZGluZyBzZXJ2aWNlIHJlZmVyZW5jZSBhdCBuYW1lIHNlcnZp Y2UgYWdhaW5zdCBpZDogRXhhbXBsZXMvTmFtZVJlc29sdmUvU2VydmljZQoKQ29yYmEgTmlsLi4u IE5vb28gIQo8L1BSRT48UFJFPiRjYXQgfi9pb3IucmVmPC9QUkU+PFBSRT48UFJFPklPUjowMTAw MDAwMDI4MDAwMDAwNDk0NDRjM2E2ZjZkNjcyZTZmNzI2NzJmNDM2ZjczNGU2MTZkNjk2ZTY3MmY0 ZTYxNmQ2OTZlNjc0MzZmNmU3NDY1Nzg3NDNhMzEyZTMwMDAwMjAwMDAwMGNhYWVkZmJhNTQwMDAw MDAwMTAxMDAwMDJiMDAwMDAwMmY3NDZkNzAyZjZmNzI2MjY5NzQyZDY0Njg2MTcyNzQ2NTcyMmY2 ZjcyNjIyZDMxMzIzNjMzMzAzMzMxMzkzNjM4MzQzOTM1MzkzOTM5MzgzOTM2MDAwMDAwMDAwMDAw MTgwMDAwMDAwMDAwMDAwMDlmY2M4NTQwMmRhZTQxOTYwMTAwMDAwMGIzMGQzYWI1YmQzZDkwM2Ew MDAwMDAwMDM4MDAwMDAwMDEwMTAwMDAxMDAwMDAwMDMxMzkzMjJlMzEzNjM4MmUzMjMwMzIyZTMx MzQzMzAwOTljZjAwMDAxODAwMDAwMDAwMDAwMDAwOWZjYzg1NDAyZGFlNDE5NjAxMDAwMDAwYjMw ZDNhYjViZDNkOTAzYQo8L1BSRT48UFJFPlRoZSBzdHJpbmdzIGFyZSB0aGUgc2FtZS4uLiBzbywg SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgaGFwcGVucyAob3Igd2hhdCBkb2Vzbid0IGhhcHBlbnMu Li4pID88L1BSRT48UFJFPlRoYW5rcyBmb3IgYW55IGhlbHA8L1BSRT48L1BSRT48L0RJVj4KPEJM T0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgogIDxESVY+PEZPTlQg c2l6ZT0yPi0tLS0tLS0tIE1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0tLS0gPEJSPjxCPkRlOjwvQj4g RnJhbmsgCiAgUmVoYmVyZ2VyIFttYWlsdG86RnJhbmsuUmVoYmVyZ2VyQHdlYi5kZV0gPEJSPjxC PkRhdGU6PC9CPiBtZXIuIDA5LzA2LzIwMDQgCiAgMTg6NDMgPEJSPjxCPsOAOjwvQj4gSGFydGVy IERhbWllbiA8QlI+PEI+Q2M6PC9CPiBvcmJpdC1saXN0QGdub21lLm9yZyAKICA8QlI+PEI+T2Jq ZXQ6PC9CPiBSZTogT3JiaXQyIE5hbWUgU2VydmljZSBQcm9ibGVtczxCUj48QlI+PC9GT05UPjwv RElWPgogIDxQPjxGT05UIHNpemU9Mj5IYXJ0ZXIgRGFtaWVuIHdyb3RlOjxCUj48QlI+Jmd0OyBB bGwsPEJSPiZndDsgQXMgSSBzYWlkIHRvIAogIEJpbGwsIEkndmUgYSBwcm9ibGVtIHdpdGggdGhl IE9yYml0MiBuYW1lIHNlcnZpY2UsIHRoZTxCUj4mZ3Q7IHNhbWUgYXMgCiAgOjxCUj4mZ3Q7IG1h aWwuZ25vbWUub3JnL2FyY2hpdmVzL29yYml0LWxpc3QvMjAwMy1qdWx5L21zZzAwMDQ5Lmh0bWwu PEJSPiZndDsgCiAgSSB0cmllZCB0byBydW4gdGhlIE5hbWUgUmVzb2x2ZSBleGFtcGxlIHVuZGVy IFJlZGhhdCA5IGFuZCA3LjIgOjxCUj4mZ3Q7IAogICokb3JiaXQtbmFtZS1zZXJ2ZXIgJmd0OyB+ L2lvci5yZWYqPEJSPiZndDsgKiQuL25hbWUtcmVzb2x2ZS1zZXJ2ZXIgCiAgLU9SQkluaXRSZWYg TmFtZVNlcnZpY2U9YGNhdCB+L2lvci5yZWZgKjxCUj4mZ3Q7ICpCaW5kaW5nIHNlcnZpY2UgcmVm ZXJlbmNlIGF0IAogIG5hbWUgc2VydmljZSBhZ2FpbnN0IGlkOjxCUj4mZ3Q7IEV4YW1wbGVzL05h bWVSZXNvbHZlL1NlcnZpY2UqPEJSPiZndDsgCiAgKio8QlI+Jmd0OyAqKiogRVJST1IgKio6IGZh aWxlZCBiaW5kaW5nIG9mIHNlcnZpY2UgCiAgT0RMOm9tZy5vcmcvQ09SQkEvSU5WX09CSlJFRjox LjAqPEJSPiZndDsgKmFib3J0aW5nLi4uKjxCUj4mZ3Q7IAogICphYmFuZG9uKjxCUj4mZ3Q7Jm5i c3A7PEJSPjxCUj5UaGlzIGVycm9yIHNob3dzIHVwLCBpZiBhbmQgb25seSBpZiB5b3UgY2FsbCAK ICByZW1vdGUgb3BlcmF0aW9uIHdpdGg8QlI+TlVMTC1PYmplY3QsPEJSPnBsZWFzZSB2ZXJpZnkg b3BlcmF0aW9uIAogIHN0cmluZ190b19vYmplY3QgcmV0dXJucyB2YWxpZCBiaW5hcnkgb2JqZWN0 PEJSPnJlZmVyZW5jZS48QlI+PEJSPk15IGZlZWxpbmcgCiAgaXMsIHRoZSBjb250ZW50IG9mIH4v aW9yLnJlZiBpcyBub3QgcmVhZCBjb21wbGV0ZWx5LDxCUj5wbGVhc2UgY2FuIHlvdSBjaGFuZ2Ug CiAgdGhlIGltcGxlbWVudGF0aW9uIG9mICpuYW1lLXJlc29sdmUtc2VydmVyLmMgc288QlI+dGhh dCBpdCBwcmludHMgcmVhZCBjb250ZW50IAogIHRvIHRlcm1pbmFsLDxCUj48QlI+UmVnYXJkcywg RnJhbms8QlI+PEJSPio8QlI+PEJSPiZndDsgSSd2ZSB0aGUgc2FtZSBpc3N1ZSBpZiAKICBJIHdy b3RlIHRoZSBuYW1lIHNlcnZpY2UgaW9yIHByaW50ZWQgYnkgb3JiaXQ8QlI+Jmd0OyBuYW1lIHNl cnZlciBpbnN0ZWFkIG9mIAogIGBjYXQgfi9pb3IucmVmYC48QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7 IEhlcmUgc29tZSBpbmZvcm1hdGlvbiB0aGF0IG1heSBoZWxwIAogIDo8QlI+Jmd0OyAqJGNhdCB+ Ly5vcmJpdHJjKjxCUj4mZ3Q7ICpPUkJJSU9QVVNvY2s9MSo8QlI+Jmd0OyAKICAqT1JCSUlPUElQ djQ9MSo8QlI+Jmd0OyAqT1JCSUlPUElQdjY9MCo8QlI+Jmd0OyAqKjxCUj4mZ3Q7ICokaW9yLWRl Y29kZS0yIGBjYXQgCiAgfi9pb3IucmVmYCo8QlI+Jmd0OyAqT2JqZWN0IElEOiAKICBJREw6b21n Lm9yZy9Db3NOYW1pbmcvTmFtaW5nQ29udGV4dDoxLjAqPEJSPiZndDsgKklPUF9UQUdfSU5URVJO RVRfSU9QOiBHSU9QIAogIDEuMCAxOTIuMTY4Li4uLi4xNDM6MzU0NTQqPEJSPiZndDsgKiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBvYmplY3Rfa2V5ICgyNCkg JzAwMDAwMDAwZDU1ZjM0YjcyMWEuLi5jM2InKjxCUj4mZ3Q7ICokaW9yLWRlY29kZSBgY2F0IAog IH4vaW9yLnJlZmAqPEJSPiZndDs8QlI+Jmd0OypUYWdzIGtub3duOjxCUj4mZ3Q7VEFHX0lOVEVS TkVUX0lPUDogCiAgMHgwPEJSPiZndDtUQUdfTVVMVElQTEVfQ09NUE9ORU5UUzogMHgxPEJSPiZn dDtUQUdfT1JCSVRfU1BFQ0lGSUM6IAogIDB4YmFkZmFlY2E8QlI+Jmd0OzxCUj4mZ3Q7T2JqZWN0 IElEOiAKICBJREw6b21nLm9yZy9Db3NOYW1pbmcvTmFtaW5nQ29udGV4dDoxLjA8QlI+Jmd0O1By b2ZpbGUgY291bnQ6IAogIDE8QlI+Jmd0OzxCUj4mZ3Q7UHJvZmlsZSB0eXBlOiBUQUdfSU5URVJO RVRfSU9QPEJSPiZndDtPYmplY3QgZW5kaWFuOiAKICBMaXR0bGU8QlI+Jmd0O0lJT1AgdmVyc2lv bjogMS4wPEJSPiZndDtIb3N0OiAxOTIuMTY4LjIwMi4xNDM8QlI+Jmd0O1BvcnQ6IAogIDM1NDU0 PEJSPiZndDtPYmplY3Qga2V5OiAiLi4uLi5fNC4hLl1rLi4uLi5lLi4zTkw7Iio8QlI+Jmd0OzxC Uj4mZ3Q7VGhhbmtzIGZvciAKICBoZWxwPEJSPiZndDs8QlI+Jmd0O0RhbWllbjxCUj4mZ3Q7PEJS PiZndDsmbmJzcDs8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7PEJSPiZndDstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 QlI+Jmd0OzxCUj4mZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188QlI+Jmd0O29yYml0LWxpc3QgCiAgbWFpbGluZyBsaXN0PEJSPiZndDtvcmJpdC1saXN0 QGdub21lLm9yZzxCUj4mZ3Q7PEEgCiAgaHJlZj0iaHR0cDovL21haWwuZ25vbWUub3JnL21haWxt YW4vbGlzdGluZm8vb3JiaXQtbGlzdCI+aHR0cDovL21haWwuZ25vbWUub3JnL21haWxtYW4vbGlz dGluZm8vb3JiaXQtbGlzdDwvQT48QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7PEJSPjxCUj48QlI+PC9G T05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C44EBC.18F379AC-- From Frank.Rehberger@web.de Thu Jun 10 07:02:58 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp08.web.de (smtp08.web.de [217.72.192.226]) by menubar.gnome.org (Postfix) with ESMTP id 6F2053B0732 for ; Thu, 10 Jun 2004 07:02:58 -0400 (EDT) Received: from pd9e81588.dip0.t-ipconnect.de ([217.232.21.136] helo=web.de) by smtp08.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #91) id 1BYNKf-0004Wp-00; Thu, 10 Jun 2004 13:02:53 +0200 Message-ID: <40C829DB.6080804@web.de> Date: Thu, 10 Jun 2004 11:28:59 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harter Damien References: <51043592743D154DA9C89694EDA1DD09016390F7@WEXCHBE02-VS.ptx.fr.sopra> In-Reply-To: <51043592743D154DA9C89694EDA1DD09016390F7@WEXCHBE02-VS.ptx.fr.sopra> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Frank.Rehberger@web.de Cc: "orbit-list@gnome.org" Subject: Re: RE : Orbit2 Name Service Problems X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 11:02:58 -0000 Harter Damien wrote: > I updated the name-resolve-server code as you said : > I had the 3 following lines int he main(), just before > etk_get_name_service() : > *printf("IOR String = %s\n", argv[2]) ;* > *printf("ORB ref = %p\n, global_orb) ;* > *printf("NS Ref = %p\n", string_to_object(global_orb, argv[2], ev)) ;* The example had been developed on RH9, testing on Fedora-1 the example runs fine out of the box, too (as described in README), even with your ~/.orbitrc settings ;) I did Testing with ORBit2-2.8.2-1 and ORBit2-2.10.1 Did you change implementation of name-resolve-server? Please, can you send me your code? Regards, Frank From Frank.Rehberger@web.de Thu Jun 10 07:03:17 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp08.web.de (smtp08.web.de [217.72.192.226]) by menubar.gnome.org (Postfix) with ESMTP id 2378A3B0755 for ; Thu, 10 Jun 2004 07:03:17 -0400 (EDT) Received: from pd9e81588.dip0.t-ipconnect.de ([217.232.21.136] helo=web.de) by smtp08.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #91) id 1BYNKe-0004WR-00; Thu, 10 Jun 2004 13:02:52 +0200 Message-ID: <40C81D86.4030301@web.de> Date: Thu, 10 Jun 2004 10:36:22 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Lunzenauer References: <40AC2F01.5000702@csiro.au> In-Reply-To: X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Frank.Rehberger@web.de Cc: orbit-list@gnome.org Subject: Re: [orbit] object_to_string & string_to_object X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 11:03:17 -0000 Marcus Lunzenauer wrote: >I have some problems using the methods CORBA_ORB_object_to_string and CORBA_ORB_string_to_object. > > here you find help: http://www.gnome.org/projects/ORBit2/orbit-docs/orbit/book1.html http://www.gnome.org/projects/ORBit2 >Last question: > >One of my objects has a oneway method. What happens if I invokef that method, that object is then processing this method but gets another method call? What happens if that object gets 10000 calls while processing the first one? > > this depends on your ConcurrencyModel, have a look at the example "threaded-calculator" in orbit "beginners guide" The trick is to setup Object Adapter (POA) with correct ConcurrencyPolicy. If you init ORBit2 as mutlithreaded mode (default mode) you can choose between modes "sequential" "thread per object" "thread per connection" and "thread per request" (AFAIK). Hope this helps, Regards, Frank -- Frank Rehberger Gnome Deutschland e.V. i.Gr. From dharter@sopragroup.com Thu Jun 10 09:04:23 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by menubar.gnome.org (Postfix) with ESMTP id 6C1013B0747 for ; Thu, 10 Jun 2004 09:04:23 -0400 (EDT) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i5AD4Kr4014623; Thu, 10 Jun 2004 15:04:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44EEB.68D83F25" Date: Thu, 10 Jun 2004 15:04:05 +0200 Message-ID: <51043592743D154DA9C89694EDA1DD0901639102@WEXCHBE02-VS.ptx.fr.sopra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : Orbit2 Name Service Problems Thread-Index: AcRO2n5yzIn3PUt6RPChVVUANP1ddgAEGMC0 From: "Harter Damien" To: "Frank Rehberger" X-OriginalArrivalTime: 10 Jun 2004 13:05:07.0328 (UTC) FILETIME=[8D9B9000:01C44EEB] X-Scanned-By: MIMEDefang 2.38 Cc: orbit-list@gnome.org Subject: RE : RE : Orbit2 Name Service Problems X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 13:04:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C44EEB.68D83F25 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I 'm under redhat 9.0 I do : rpm -e --nodeps Orbit rpm -e --nodeps Orbit2 rpm -i Orbit2-2.6... rpm -i Orbit2-devel-2.6... rpm -i Orbit-0.5... rpm -i Orbit-devel-0.5... unzip orbit-docs.tar.gz Compile and run echo example : everything ok Compile name-resolve example : ok Run name-resolve-server : Still get the same error ./name-resolve-server -ORBInitRef = NameService=3DIOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696= e672f4e616d696e67436f6e746578743a312e300002000000caaedfba5400000001010000= 2c0000002f746d702f6f726269742d64686172746572322f6f72622d33353434393930323= 5313038353038363030320000000000180000000000000065bf360eed45d6580100000080= 5b96a123bf5c22000000003800000001010000100000003139322e3136382e3230322e313= 7340088800000180000000000000065bf360eed45d65801000000805b96a123bf5c22 Binding service reference at name service against id: = Examples/NameResolve/Service =20 =20 ** ERROR **: failed binding of service IDL:omg.org/CORBA/INV_OBJREF:1.0 aborting... Abandon Don't know what to do now...! Thanks fro any help Damien -------- Message d'origine-------- De: Frank Rehberger [mailto:Frank.Rehberger@web.de] Date: jeu. 10/06/2004 11:28 =C0: Harter Damien Cc: orbit-list@gnome.org Objet: Re: RE : Orbit2 Name Service Problems Harter Damien wrote: > I updated the name-resolve-server code as you said : > I had the 3 following lines int he main(), just before=20 > etk_get_name_service() : > *printf("IOR String =3D %s\n", argv[2]) ;* > *printf("ORB ref =3D %p\n, global_orb) ;* > *printf("NS Ref =3D %p\n", string_to_object(global_orb, argv[2], ev)) = ;* The example had been developed on RH9, testing on Fedora-1 the example=20 runs fine out of the box, too (as described in README), even with your=20 ~/.orbitrc settings ;) I did Testing with ORBit2-2.8.2-1 and ORBit2-2.10.1 Did you change implementation of name-resolve-server? Please, can you send me your code? Regards, Frank ------_=_NextPart_001_01C44EEB.68D83F25 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE : RE : Orbit2 Name Service Problems

I 'm under redhat 9.0
I do :
rpm -e --nodeps Orbit
rpm -e --nodeps Orbit2
rpm -i Orbit2-2.6...
rpm -i Orbit2-devel-2.6...
rpm -i Orbit-0.5...
rpm -i Orbit-devel-0.5...

unzip orbit-docs.tar.gz
Compile and run echo example : everything ok

Compile name-resolve example : ok
Run name-resolve-server : Still get the same error

./name-resolve-server -ORBInitRef = NameService=3DIOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696= e672f4e616d696e67436f6e746578743a312e300002000000caaedfba5400000001010000= 2c0000002f746d702f6f726269742d64686172746572322f6f72622d33353434393930323= 5313038353038363030320000000000180000000000000065bf360eed45d6580100000080= 5b96a123bf5c22000000003800000001010000100000003139322e3136382e3230322e313= 7340088800000180000000000000065bf360eed45d65801000000805b96a123bf5c22
= Binding service reference at name service against id: = Examples/NameResolve/Service


** ERROR **: failed binding of service = IDL:omg.org/CORBA/INV_OBJREF:1.0
aborting...
Abandon

Don't know what to do now...!
Thanks fro any help
Damien

-------- Message d'origine--------
De:     Frank Rehberger [mailto:Frank.Rehberger@web.de]=
Date:   jeu. 10/06/2004 11:28
=C0:      Harter Damien
Cc:     orbit-list@gnome.org
Objet:  Re: RE : Orbit2 Name Service Problems
Harter Damien wrote:

> I updated the name-resolve-server code as you said :
> I had the 3 following lines int he main(), just before
> etk_get_name_service() :
> *printf("IOR String =3D %s\n", argv[2]) ;*
> *printf("ORB ref =3D %p\n, global_orb) ;*
> *printf("NS Ref =3D %p\n", string_to_object(global_orb, = argv[2], ev)) ;*

The example had been developed on RH9, testing on Fedora-1 the = example
runs fine out of the box, too (as described in README), even  with = your
~/.orbitrc settings ;)
I did Testing with
ORBit2-2.8.2-1 and
ORBit2-2.10.1

Did you change implementation of name-resolve-server?
Please, can you send me your code?

Regards, Frank

------_=_NextPart_001_01C44EEB.68D83F25-- From robert@pengutronix.de Fri Jun 11 14:01:01 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from amalthea.dnx.de (amalthea.dnx.de [193.108.181.146]) by menubar.gnome.org (Postfix) with ESMTP id 218AF3B0819 for ; Fri, 11 Jun 2004 14:01:01 -0400 (EDT) Received: from metis.pengutronix.de ([213.252.143.165]:50398) by amalthea.dnx.de with asmtp (Exim 4.30) id 1BYqKe-0002gZ-MG for orbit-list@gnome.org; Fri, 11 Jun 2004 20:00:48 +0200 Received: from ganymed.pengutronix.de ([213.252.143.162] ident=mail) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 1BYqKe-0001lN-00 for ; Fri, 11 Jun 2004 20:00:48 +0200 Received: from robert by ganymed.pengutronix.de with local (Exim 3.36 #1 (Debian)) id 1BYqKe-0002h7-00 for ; Fri, 11 Jun 2004 20:00:48 +0200 Date: Fri, 11 Jun 2004 20:00:48 +0200 From: Robert Schwebel To: orbit-list@gnome.org Message-ID: <20040611180048.GA10337@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: Robert Schwebel X-Scan-Signature: 5003f175ed075e86e191ee2bc398b282 Subject: Local communication X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 18:01:01 -0000 Hi, I'm currently searching for a CORBA ORB for an embedded project, and ORBit2 seems not the worst choice to me, especially as it supports C. ORBit2 is said to be optimized for local use, which is good for my design. It has several parts which are normally local but can, in some cases, be on another machine. However, I was wondering about the performance for purely local calls, so I wrote a little testcase which defines an object with only one method (print out one character to stdout) which is called from a client in a loop. I compared the per-call-times with a normal function call and found it to be about 300 times slower; compared with a "transfer data over named pipe" testcase there is still a factor of 15 between the ORBit variant and the native one. I'm wondering where this huge differences come from. I had expected that, when the ORB notices that an object is local, it tries to do the IOP communication as fast as possible (shared memory?). Having a short look into the source it seems like it uses Unix Domain Sockets via linc for local communication. My question now is: where does this difference come from? Can it be completely explained by the fact that ORBit2 does things I have not thought of in my stupid test cases (like locking)? Shouldn't Unix Domain Sockets be implemented by recent kernels in a way to be pretty fast? Or is it just the overhead by using the IOP vs. just a call? Would a IOP implemtation based on shared memory be faster, or would it be a waste of time? I'm aware of the fact that it is surely not the best idea to use CORBA for non-IPC calls; the argument here is that it will probably be difficult enough to teach the people who shall write the code how to use a C based object model (it is generally difficult to teach embedded people into thinking in well designed software patterns instead of bit banging). It will probably be not easier to teach them to learn two object models, one for non-IPC and one for IPC calls. I hope that some of you ORBit2 gurus can give me some hints... :-) Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 From gjc@inescporto.pt Fri Jun 11 18:14:35 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from animal.inescn.pt (animal.inescn.pt [192.35.246.1]) by menubar.gnome.org (Postfix) with ESMTP id 65CEA3B0899 for ; Fri, 11 Jun 2004 18:14:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by animal.inescn.pt (8.12.10/8.12.10/17) with ESMTP id i5BMEYAA011384; Fri, 11 Jun 2004 23:14:34 +0100 (WEST) Received: from yang.inescn.pt (yang.inescn.pt [194.117.24.169]) by animal.inescn.pt (8.12.10/8.12.10/6) with ESMTP id i5BMEQES011379; Fri, 11 Jun 2004 23:14:26 +0100 (WEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by yang.inescn.pt (Postfix) with ESMTP id 4F83E7088E; Fri, 11 Jun 2004 23:14:25 +0100 (WEST) From: "Gustavo J. A. M. Carneiro" To: Robert Schwebel In-Reply-To: <20040611180048.GA10337@pengutronix.de> References: <20040611180048.GA10337@pengutronix.de> Content-Type: text/plain; charset=iso-8859-15 Organization: INESC Message-Id: <1086992064.3443.3.camel@emperor> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 23:14:24 +0100 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at inescporto.pt Cc: orbit-list@gnome.org Subject: Re: Local communication X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 22:14:36 -0000 Hi, I think that "local use" actually means in-proc communication to a component activated as shared library. It would be interesting to benchmark this case also. Regards. A Sex, 2004-06-11 às 19:00, Robert Schwebel escreveu: > Hi, > > I'm currently searching for a CORBA ORB for an embedded project, and > ORBit2 seems not the worst choice to me, especially as it supports C. > > ORBit2 is said to be optimized for local use, which is good for my > design. It has several parts which are normally local but can, in some > cases, be on another machine. However, I was wondering about the > performance for purely local calls, so I wrote a little testcase which > defines an object with only one method (print out one character to > stdout) which is called from a client in a loop. I compared the > per-call-times with a normal function call and found it to be about 300 > times slower; compared with a "transfer data over named pipe" testcase > there is still a factor of 15 between the ORBit variant and the native > one. > > I'm wondering where this huge differences come from. I had expected > that, when the ORB notices that an object is local, it tries to do the > IOP communication as fast as possible (shared memory?). Having a short > look into the source it seems like it uses Unix Domain Sockets via linc > for local communication. > > My question now is: where does this difference come from? Can it be > completely explained by the fact that ORBit2 does things I have not > thought of in my stupid test cases (like locking)? Shouldn't Unix Domain > Sockets be implemented by recent kernels in a way to be pretty fast? Or > is it just the overhead by using the IOP vs. just a call? Would a IOP > implemtation based on shared memory be faster, or would it be a waste of > time? > > I'm aware of the fact that it is surely not the best idea to use CORBA > for non-IPC calls; the argument here is that it will probably be > difficult enough to teach the people who shall write the code how to use > a C based object model (it is generally difficult to teach embedded > people into thinking in well designed software patterns instead of bit > banging). It will probably be not easier to teach them to learn two > object models, one for non-IPC and one for IPC calls. > > I hope that some of you ORBit2 gurus can give me some hints... :-) > > Robert -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic From michael@ximian.com Fri Jun 11 22:48:04 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 7DBAA3B072E for ; Fri, 11 Jun 2004 22:48:03 -0400 (EDT) Received: (qmail 16953 invoked from network); 12 Jun 2004 02:48:01 -0000 Received: from localhost (HELO ?10.250.0.125?) (michael@127.0.0.1) by localhost with SMTP; 12 Jun 2004 02:48:01 -0000 From: Michael Meeks To: Robert Schwebel In-Reply-To: <20040611180048.GA10337@pengutronix.de> References: <20040611180048.GA10337@pengutronix.de> Content-Type: text/plain Organization: Ximian. Date: Fri, 11 Jun 2004 19:37:30 -0700 Message-Id: <1087007851.12557.23.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.8 Content-Transfer-Encoding: 7bit Cc: orbit Subject: Re: Local communication X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 02:48:04 -0000 On Fri, 2004-06-11 at 20:00 +0200, Robert Schwebel wrote: > ORBit2 is said to be optimized for local use It's also optimised for in-process use, where it is even faster :-) > I compared the > per-call-times with a normal function call and found it to be about 300 > times slower; compared with a "transfer data over named pipe" testcase > there is still a factor of 15 between the ORBit variant and the native > one. Ok; so - we need some profiling data; can you get that ? so far we've not really been optimising ORBit2 in recent years so there are prolly some nice / easy wins in there. > I'm aware of the fact that it is surely not the best idea to use CORBA > for non-IPC calls; the argument here is that it will probably be > difficult enough to teach the people who shall write the code how to use > a C based object model (it is generally difficult to teach embedded > people into thinking in well designed software patterns instead of bit > banging). It will probably be not easier to teach them to learn two > object models, one for non-IPC and one for IPC calls. Sure; have you tried to use libbonobo ? BonoboObject makes CORBA object use really rather easier. HTH, Michael. -- michael@ximian.com <><, Pseudo Engineer, itinerant idiot From fta@cube.opentransit.net Sat Jun 12 18:32:07 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from cube.opentransit.net (cube.opentransit.net [193.251.151.83]) by menubar.gnome.org (Postfix) with ESMTP id 9C1583B094D for ; Sat, 12 Jun 2004 18:32:07 -0400 (EDT) Received: from cube.opentransit.net (nobody@localhost [127.0.0.1]) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) with ESMTP id i5CMW4tW025075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Jun 2004 00:32:04 +0200 Received: (from fta@localhost) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) id i5CMW2ut025074; Sun, 13 Jun 2004 00:32:02 +0200 Date: Sun, 13 Jun 2004 00:32:02 +0200 From: Fabien Tassin To: orbit-list@gnome.org Message-ID: <20040612223201.GA10565@opentransit.net> References: <20040531142520.GA2160@opentransit.net> <20040609131852.GC4335@opentransit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040609131852.GC4335@opentransit.net> User-Agent: Mutt/1.5.6+20040523i Subject: Re: problems with remote NameService calls X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 22:32:08 -0000 According to Fabien Tassin: > > Anyone to help me with that ? I've identified my problem. I traced it to ORBit_initial_references_by_user(). When it receives a corbaloc from '-ORBInitRef NameService=' or -ORBNamingIOR, before calling ORBit_set_initial_reference(), it should check that "NameService" _is_a() IDL:omg.org/CosNaming/NamingContext". The answer would have been (in my case) a location forward to a new Object key. Another _is_a() on that new key would be ok. Then CosNaming_NamingContext_list() would work as expected. There's a FIXME in orb-core/corba-orb.c ORBit_initial_references_by_user() that is related to that. The second call of ORBit_set_initial_reference() in ORBit_initial_references_by_user() needs the same FIXME. The loop I'm experiencing is just that. CosNaming_NamingContext_list() receives the location forward to that new key but does not handle it properly and loops with the initial key (NameService) instead of using the new one. IMHO, that's a bug too. I've just read the implementation of CORBA_Object_is_a() and I'm not sure that function does what I need, ie send GIOP _is_a() requests and handle location forwards properly (if any). Could someone help me from here ? /Fabien > According to Fabien Tassin: > > Date: Mon, 31 May 2004 16:25:21 +0200 > > > > Hi, > > > > I have an Orbit2 client talking to a remote non-Orbit server. > > It works well when used with a (fixed) IOR read with > > client_import_service_from_stream(). > > I now wish to use the NameService on the remote ORB to get the IOR > > dynamically.. but it doesn't work. > > > > Here is a minimalistic piece of code. > > > > == > > /* ... */ > > orb = CORBA_ORB_init(&argc, argv, "orbit-local-orb", ev); > > abort_if_exception(ev, "CORBA_ORB_init() failed"); > > > > nameservice = CORBA_ORB_resolve_initial_references(orb, "NameService", ev); > > abort_if_exception(ev, "resolve_initial_references(NameService) failed"); > > > > context = (CosNaming_NamingContext) nameservice; > > g_assert(!CORBA_Object_is_nil(context, ev)); > > > > CosNaming_NamingContext_list(context, 0, &bl, &bi, ev); > > abort_if_exception(ev, "list() failed"); > > g_assert(!CORBA_Object_is_nil(bi, ev)); > > /* ... */ > > == > > > > I invoke this using -ORBInitRef NameService=corbaloc::remote:port/NameService > > It goes into an infinite loop in CosNaming_NamingContext_list(). > > > > ethereal+strace show that the CORBA_ORB_resolve_initial_references() call is > > not made against the remote ORB but against the local one (from my > > Gnome2 desktop, reading /tmp/orbit-myuser). > > CosNaming_NamingContext_list() talks to the remote ORB but loops.. > > [ Request (two-way): list -> Reply: Location Forward ] > > I assume this is because 'nameservice' is wrong. > > > > I'm quite sure it is a problem with my client code (or Orbit2) > > as 'nameclt' from omniorb4 works perfectly. > > (nameclt -ORBInitRef NameService=corbaloc::remote:port/NameService list) > > > > Maybe I missed something or did something wrong.. > > > > $ orbit2-config --version > > ORBit2 2.10.2 > > > > Thoughts ? > > > > /Fabien > > _______________________________________________ > > orbit-list mailing list > > orbit-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/orbit-list > _______________________________________________ > orbit-list mailing list > orbit-list@gnome.org > http://mail.gnome.org/mailman/listinfo/orbit-list From fta@cube.opentransit.net Mon Jun 14 12:52:39 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from cube.opentransit.net (cube.opentransit.net [193.251.151.83]) by menubar.gnome.org (Postfix) with ESMTP id 0F9BD3B0A9E for ; Mon, 14 Jun 2004 12:52:39 -0400 (EDT) Received: from cube.opentransit.net (nobody@localhost [127.0.0.1]) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) with ESMTP id i5EGqZUr026960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jun 2004 18:52:35 +0200 Received: (from fta@localhost) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) id i5EGqZ67026959; Mon, 14 Jun 2004 18:52:35 +0200 Date: Mon, 14 Jun 2004 18:52:35 +0200 From: Fabien Tassin To: orbit-list@gnome.org Message-ID: <20040614165235.GC31836@opentransit.net> References: <20040531142520.GA2160@opentransit.net> <20040609131852.GC4335@opentransit.net> <20040612223201.GA10565@opentransit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040612223201.GA10565@opentransit.net> User-Agent: Mutt/1.5.6+20040523i Subject: Re: problems with remote NameService calls X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 16:52:39 -0000 More to this case.. including a solution. According to Fabien Tassin: > > > > Anyone to help me with that ? > > I've identified my problem. > > I traced it to ORBit_initial_references_by_user(). > When it receives a corbaloc from '-ORBInitRef NameService=' or -ORBNamingIOR, > before calling ORBit_set_initial_reference(), it should check that > "NameService" _is_a() IDL:omg.org/CosNaming/NamingContext". > The answer would have been (in my case) a location forward > to a new Object key. Another _is_a() on that new key would be ok. > Then CosNaming_NamingContext_list() would work as expected. > > There's a FIXME in orb-core/corba-orb.c ORBit_initial_references_by_user() > that is related to that. The second call of ORBit_set_initial_reference() > in ORBit_initial_references_by_user() needs the same FIXME. > > The loop I'm experiencing is just that. CosNaming_NamingContext_list() > receives the location forward to that new key but does not handle > it properly and loops with the initial key (NameService) instead > of using the new one. IMHO, that's a bug too. The loop is in ORBit_small_invoke_stub(). The 1st orbit_small_demarshal() call sets obj->forward_locations then returns MARSHAL_RETRY which causes the 1st iteration. Fine. Then, obj->forward_locations seems to be completely ignored producing an infinite loop. For this to work, ORBit_object_get_connection() must be called at each retry.. I've tried with the 'retry_request:' label a few lines above to include ORBit_object_get_connection() but it doesn't help.. the reason is there: GIOPConnection * ORBit_object_get_connection (CORBA_Object obj) { /* .. declarations .. */ if (obj->connection) { if (ORBit_try_connection_T (obj)) { cnx = obj->connection; giop_connection_ref (cnx); OBJECT_UNLOCK (obj); return cnx; } else { OBJECT_UNLOCK (obj); return NULL; } } g_assert (obj->connection == NULL); if (!obj->forward_locations) { plist = obj->profile_list; objkey = obj->object_key; } else { plist = obj->forward_locations; objkey = IOP_profiles_sync_objkey (plist); } /* .... */ } obj->forward_locations is never used as on the 2nd call, we already have a connection. I've hacked the code to do the proper actions but it fails later as the 2nd IOP_profiles_sync_objkey() completly looses track of the object (by design). Once again, I've patched it and I'm finally able to obtain the expected answer from CosNaming_NamingContext_list(). Problem: the patch is dirty and may have counter effects on other parts of the code :( Anyway, this is a serious bug and the two _is_a() calls I've mentionned are also more than welcome. Do you wish me to post a patch knowing that I'm unable to test it in all situations ? /Fabien > I've just read the implementation of CORBA_Object_is_a() and I'm > not sure that function does what I need, ie send GIOP _is_a() requests > and handle location forwards properly (if any). > > Could someone help me from here ? > > /Fabien > > > According to Fabien Tassin: > > > Date: Mon, 31 May 2004 16:25:21 +0200 > > > > > > Hi, > > > > > > I have an Orbit2 client talking to a remote non-Orbit server. > > > It works well when used with a (fixed) IOR read with > > > client_import_service_from_stream(). > > > I now wish to use the NameService on the remote ORB to get the IOR > > > dynamically.. but it doesn't work. > > > > > > Here is a minimalistic piece of code. > > > > > > == > > > /* ... */ > > > orb = CORBA_ORB_init(&argc, argv, "orbit-local-orb", ev); > > > abort_if_exception(ev, "CORBA_ORB_init() failed"); > > > > > > nameservice = CORBA_ORB_resolve_initial_references(orb, "NameService", ev); > > > abort_if_exception(ev, "resolve_initial_references(NameService) failed"); > > > > > > context = (CosNaming_NamingContext) nameservice; > > > g_assert(!CORBA_Object_is_nil(context, ev)); > > > > > > CosNaming_NamingContext_list(context, 0, &bl, &bi, ev); > > > abort_if_exception(ev, "list() failed"); > > > g_assert(!CORBA_Object_is_nil(bi, ev)); > > > /* ... */ > > > == > > > > > > I invoke this using -ORBInitRef NameService=corbaloc::remote:port/NameService > > > It goes into an infinite loop in CosNaming_NamingContext_list(). > > > > > > ethereal+strace show that the CORBA_ORB_resolve_initial_references() call is > > > not made against the remote ORB but against the local one (from my > > > Gnome2 desktop, reading /tmp/orbit-myuser). > > > CosNaming_NamingContext_list() talks to the remote ORB but loops.. > > > [ Request (two-way): list -> Reply: Location Forward ] > > > I assume this is because 'nameservice' is wrong. > > > > > > I'm quite sure it is a problem with my client code (or Orbit2) > > > as 'nameclt' from omniorb4 works perfectly. > > > (nameclt -ORBInitRef NameService=corbaloc::remote:port/NameService list) > > > > > > Maybe I missed something or did something wrong.. > > > > > > $ orbit2-config --version > > > ORBit2 2.10.2 > > > > > > Thoughts ? > > > > > > /Fabien > > > _______________________________________________ > > > orbit-list mailing list > > > orbit-list@gnome.org > > > http://mail.gnome.org/mailman/listinfo/orbit-list > > _______________________________________________ > > orbit-list mailing list > > orbit-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/orbit-list From gatecrasher01@hotmail.com Wed Jun 16 00:14:00 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from hotmail.com (bay17-f20.bay17.hotmail.com [64.4.43.70]) by menubar.gnome.org (Postfix) with ESMTP id B8C2E3B06EC for ; Wed, 16 Jun 2004 00:13:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 Jun 2004 20:41:57 -0700 Received: from 192.83.231.203 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 16 Jun 2004 03:41:57 GMT X-Originating-IP: [192.83.231.203] X-Originating-Email: [gatecrasher01@hotmail.com] X-Sender: gatecrasher01@hotmail.com From: "Jeremy Centenera" To: orbit-list@gnome.org Date: Wed, 16 Jun 2004 13:11:57 +0930 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jun 2004 03:41:57.0364 (UTC) FILETIME=[DFB2BB40:01C45353] Subject: mapping sequences to aliases X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 04:14:00 -0000 Hi , I am using your perl binding CORBA::ORBit 0.4.7 with ORBit 0.5.17. When I am performing a call with an inout parameter, I get the following error message: bless{ '-file' => '/usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/CORBA/ORBit.pm', 'reason' => 'LineTestMO: Parameter InputParams has wrong type 19, required 21', '-line' => 191, '-package' => 'CORBA::UserException', 'code' => 12 }, 'oam::nms::sm::corba::OperationException' ) I know this is an error related to CORBA types, which are defined by some specifications. 21 is the type alias, while 19 is the type sequence. Normally, ORB implementations (at least the Java and C++ ORBs I have tried untill now) map sequences to aliases. I don’t know what CORBA::ORBit does in the case of mapping sequences to aliases. Can this be fixed or is there some setting in ORBit about this?? Regards Jeremy Centenera _________________________________________________________________ Smart Saving with ING Direct – earn 5.25% p.a. variable rate: http://ad.au.doubleclick.net/clk;7249209;8842331;n?http://www.ingdirect.com.au/burst6offer.asp?id=8 From marcus.lunzenauer@osnanet.de Wed Jun 16 15:43:08 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from mailinout01.osnanet.de (mailinout01.osnanet.de [212.95.97.82]) by menubar.gnome.org (Postfix) with ESMTP id CBBB93B0738 for ; Wed, 16 Jun 2004 15:43:07 -0400 (EDT) Received: from mail.osnanet.de (mail.osnanet.de [212.95.97.81]) by mailinout01.osnanet.de (mailinout01.osnanet.de) with ESMTP id E9408CEB5 for ; Wed, 16 Jun 2004 21:43:04 +0200 (CEST) Received: from herbert (xdslf244.osnanet.de [212.95.105.244]) by mail.osnanet.de (mail.osnanet.de) with SMTP id A3E2DCB1A2 for ; Wed, 16 Jun 2004 21:43:04 +0200 (CEST) Date: Wed, 16 Jun 2004 21:43:11 +0200 From: Marcus Lunzenauer To: orbit-list@gnome.org Message-ID: <5tQuRIbKegT2cU7GYnQxyGM8h76CCYnoS47w71eDpsi@akmail> References: <20040611180048.GA10337@pengutronix.de> <1087007851.12557.23.camel@linux.site> X-Mailer: AK-Mail 3.5 [ger] (registered, single user license) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: how to know wheter an object is still "alive" X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcus Lunzenauer List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 19:43:08 -0000 In my application I have have to determine, whether that an object is stil= l "alive" (reachable? active?) but I only have that object's IOR. I thought that the following code would do this for me, but it does not: static CORBA_Object getGovernor(const char *governorIOR, CORBA_Environment * ev){ CORBA_Object cur_gov =3D CORBA_OBJECT_NIL; // CHECK: is the current governor still active? if (governorIOR){ // translate IOR cur_gov =3D (CORBA_Object) CORBA_ORB_string_to_object(global_orb, gover= norIOR, ev); // that IOR is not translatable if (ev->_major !=3D CORBA_NO_EXCEPTION){ debug(DEFAULT_DEBUG_FLAGS, "Could not find registered governor.\n"); CORBA_exception_free(ev); // FIXME: is this needed? cur_gov =3D CORBA_OBJECT_NIL; // DON'T DO ANYTHING; governor is still active } else { debug(DEFAULT_DEBUG_FLAGS, "Registered governor still active.\n"); } } return cur_gov; } How else can I get to know whether the IOR's object can be reached? Marcus From marcus.lunzenauer@osnanet.de Fri Jun 18 02:38:09 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from mailinout01.osnanet.de (mailinout01.osnanet.de [212.95.97.82]) by menubar.gnome.org (Postfix) with ESMTP id 4887C3B0887 for ; Fri, 18 Jun 2004 02:38:09 -0400 (EDT) Received: from mail.osnanet.de (mail.osnanet.de [212.95.97.81]) by mailinout01.osnanet.de (mailinout01.osnanet.de) with ESMTP id A49DECAA6 for ; Fri, 18 Jun 2004 08:37:42 +0200 (CEST) Received: from herbert (xdslc254.osnanet.de [212.95.102.254]) by mail.osnanet.de (mail.osnanet.de) with SMTP id 559BCCB21A for ; Fri, 18 Jun 2004 08:37:42 +0200 (CEST) Date: Fri, 18 Jun 2004 08:37:44 +0200 From: Marcus Lunzenauer To: orbit-list@gnome.org Message-ID: References: <20040611180048.GA10337@pengutronix.de> <1087007851.12557.23.camel@linux.site> <5tQuRIbKegT2cU7GYnQxyGM8h76CCYnoS47w71eDpsi@akmail> X-Mailer: AK-Mail 3.5 [ger] (registered, single user license) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Problems with NameService X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcus Lunzenauer List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 06:38:09 -0000 I have two applications, a service A and a "client" B. Service A binds its= elf to the NameService. B resolves it. When I restart B, it cannot resolve= A anymore.. This is how this happens. 1.) I start my service A which bind successfully to the NameService. 2.) Second I start my client B, which resolves successfully the service A an= d calls some functions at A. 3.) Now I exit the client gracefully, while the service A is still running. 4.) Using name-client-2 I can now see, that service A is still bound. 5.) I start the client B again, for debugging purposes I let it sleep for ab= out 10 seconds right before the next step. Using name-client-2 I still see service A. 6.) After sleeping, client B does this: debug(DEBUG_SCHEDULER, "short break"); sleep(10); debug(DEBUG_SCHEDULER, "awake"); // get scheduler gchar *sched_id[] =3D {"ua", "services", "Scheduler", NULL}; debug(DEBUG_SCHEDULER, "Resolving service reference from name-service wi= th id " "\"%s/%s/%s\"", sched_id[0], sched_id[1], sched_id[2]); scheduler =3D (ua_services_Scheduler) nameservice_lib_name_service_resol= ve(name_service, sched_id, ev); While the function nameservice_lib_name_service_resolve is the same as t= he function etk_name_service_resolve from the examples-toolkit.c=20 (see http://www.gnome.org/projects/ORBit2/orbit-docs/orbit/x998.html Exa= mple 35). 7.) In line 233 in examples-toolkit.c retval =3D CosNaming_NamingContext_resolve (name_service, name, ev); =20=20 an exception is raised: CosNaming_NamingContext_NotFound Exception why: CosNaming_NamingContext_missing_node rest_of_name: Scheduler 8.) Using name-client-2 I can't see service A anymore. In my client's code I do not unbind anything, just: int main(int argc, char *argv[]){ CORBA_Environment ev[1]; CORBA_exception_init(ev); // server_init right from the examples // see http://www.gnome.org/projects/ORBit2/orbit-docs/orbit/x316.html#A= EN406 ex.3 server_init(&argc, argv, &global_orb, &root_poa, ev); etk_abort_if_exception(ev, "failed ORB init"); // get name_service name_service =3D (CosNaming_NamingContext) CORBA_ORB_resolve_initial_ref= erences(global_orb, "NameService", ev); etk_abort_if_exception(ev, "failed resolving name-service"); debug(DEBUG_SCHEDULER, "short break"); sleep(10); debug(DEBUG_SCHEDULER, "awake"); [..see above,,] I am quite confused, as I NEVER even wrote the word unbind.. There is no w= ay I can tell, what the problem is. I really hope that someone on this list can help me finding this problem. BTW: my ORBIT2 Version is the latest 2.10.2. Utterly despaired, Marcus Lunzenauer From yjoshi@nulinkinc.com Thu Jun 17 08:14:12 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from mail.VirtualMailServers.com (unknown [216.235.244.64]) by menubar.gnome.org (Postfix) with ESMTP id 60CBE3B0AE5 for ; Thu, 17 Jun 2004 08:14:12 -0400 (EDT) Received: from delta.nulinkinc.com by mail.VirtualMailServers.com (Virtual Mail Servers by TactiCom) with ESMTP id LPP74323 for ; Thu, 17 Jun 2004 08:14:10 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jun 2004 17:44:03 +0530 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Orbit2 Details Thread-Index: AcRUZJP+rZrNLF/TRsyxFlxVp86mzg== From: "yateen joshi" To: X-Mailman-Approved-At: Sat, 19 Jun 2004 05:51:24 -0400 Cc: Ritesh Kumar Kakar , yateen joshi Subject: Orbit2 Details X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 12:14:12 -0000 Hi, I am on a lookout for a CORBA that will satisfy my following = requirements. I tried to get the information for the same through = various documents on Orbit and Orbit2, but could not find much. It will = be appreciated if I get following information (in short ). 1. Is complete source code available? ( I believe, yes). 2. Can I buy support from someone? 3. What bindings are supported (e.g. C++, JAVA, C)? 4. Performance a. Good C++ Speed b. Minimum Memory usage c. Executable size. 5. Does it provide following features -=20 a. Callback b. Notifications c. Communication via corbalocs on fixed ports ( I can pre-configure = the port number for the client, without getting it after the server is = started) d. single as well as multithreaded architecture. e. Linkage to pthread. f. Pluggable reactor and transport support. g. SSL transport support h. POA - which services i. Portable interceptors=20 j. one-way support k. No runtime license checks. l. C++ STL support m. C++ design pattern support n. MIPS compatible (Linux on X86, MIPS). o. Time out (global as well as per request) p. Start and stop the CORAB service when the process is running , = should be able to start without killing the process, and clean = shutdown is also possible.=20 q. UNI-code support r. User being able to compile multiple instances simultaneously and no = license checks there.=20 s. Interoperability with other ORB'S. t. Naming service.=20 u. Server load balancing service. v. Feature equivalent to hostname policy of e*ORB.=20 w. Any debugging and monitoring tools available?=20 Thanks and regards, Yateen V. Joshi From Frank.Rehberger@xtradyne.com Fri Jun 18 11:20:38 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from gw.xtradyne.de (gw.xtradyne.de [62.159.77.194]) by menubar.gnome.org (Postfix) with ESMTP id 9C7423B0852 for ; Fri, 18 Jun 2004 11:20:33 -0400 (EDT) Received: from penguin.xtradyne.de ([192.168.1.2]) by gw.xtradyne.de with esmtp (Exim 4.34) id 1BbLAH-0005Yi-Bh; Fri, 18 Jun 2004 17:20:25 +0200 Received: from amavis by penguin.xtradyne.de with scanned-ok (Exim 4.34) id 1BbLAG-0002qe-JC; Fri, 18 Jun 2004 17:20:24 +0200 Received: from mole.xtradyne.de ([192.168.1.4] helo=xtradyne.com) by penguin.xtradyne.de with esmtp (Exim 4.34) id 1BbLAF-0002qX-Vs; Fri, 18 Jun 2004 17:20:24 +0200 Message-ID: <40D30837.80206@xtradyne.com> Date: Fri, 18 Jun 2004 17:20:23 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Lunzenauer References: <20040611180048.GA10337@pengutronix.de> <1087007851.12557.23.camel@linux.site> <5tQuRIbKegT2cU7GYnQxyGM8h76CCYnoS47w71eDpsi@akmail> In-Reply-To: <5tQuRIbKegT2cU7GYnQxyGM8h76CCYnoS47w71eDpsi@akmail> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Mailman-Approved-At: Sat, 19 Jun 2004 05:51:23 -0400 Cc: orbit-list@gnome.org Subject: Re: how to know wheter an object is still "alive" X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 15:20:38 -0000 Marcus Lunzenauer wrote: >In my application I have have to determine, whether that an object is still "alive" (reachable? active?) but I only have that object's IOR. > >I thought that the following code would do this for me, but it does not: > > >static CORBA_Object >getGovernor(const char *governorIOR, CORBA_Environment * ev){ > > CORBA_Object cur_gov = CORBA_OBJECT_NIL; > > // CHECK: is the current governor still active? > if (governorIOR){ > > // translate IOR > cur_gov = (CORBA_Object) CORBA_ORB_string_to_object(global_orb, governorIOR, ev); > > // that IOR is not translatable > if (ev->_major != CORBA_NO_EXCEPTION){ > > debug(DEFAULT_DEBUG_FLAGS, "Could not find registered governor.\n"); > CORBA_exception_free(ev); > > // FIXME: is this needed? > cur_gov = CORBA_OBJECT_NIL; > > // DON'T DO ANYTHING; governor is still active > } else { > debug(DEFAULT_DEBUG_FLAGS, "Registered governor still active.\n"); > } > } > > return cur_gov; >} > > please use CORBA_Object operation CORBA_boolean non_existent = CORBA_Object_non_existent (obj, ev); This is a very lightweight request that is handled by servers object container, object/service implementation is not involved. Following GUI CORBA tool is using this operation to test liveness of object in servers object container: http://casa.in-berlin.de/gnome-ior.html Regards, Frank -- Frank Rehberger XTRADYNE Technologies AG Schoenhauser Allee 6/7 D-10119 Berlin Germany Phone +49-30-44 03 06-37 Fax +49-30-44 03 06-78 Email Frank.Rehberger@xtradyne.com WWW www.xtradyne.com From frehberg@gnome-de.org Fri Jun 18 11:22:34 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from mx-in-01.simplementehosting.net (mx-in-01.simplementehosting.net [66.216.79.177]) by menubar.gnome.org (Postfix) with ESMTP id B6BC43B0852 for ; Fri, 18 Jun 2004 11:22:34 -0400 (EDT) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx-in-01.simplementehosting.net (Postfix) with SMTP id F1D77235224 for ; Fri, 18 Jun 2004 10:21:58 -0500 (CDT) Received: (qmail 16541 invoked by uid 85); 18 Jun 2004 15:21:19 -0000 Received: from frehberg@gnome-de.org by mail.bytecamp.net by uid 88 with qmail-scanner-1.20 (clamscan: 0.54. Clear:RC:0(217.232.12.6):. Processed in 0.022538 secs); 18 Jun 2004 15:21:19 -0000 Received: from pd9e80c06.dip0.t-ipconnect.de (HELO gnome-de.org) (frehberg@gnome-de.org@217.232.12.6) by mail.bytecamp.net with AES256-SHA encrypted SMTP; 18 Jun 2004 15:21:19 -0000 Message-ID: <40D3086B.6050804@gnome-de.org> Date: Fri, 18 Jun 2004 17:21:15 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Lunzenauer References: <20040611180048.GA10337@pengutronix.de> <1087007851.12557.23.camel@linux.site> <5tQuRIbKegT2cU7GYnQxyGM8h76CCYnoS47w71eDpsi@akmail> In-Reply-To: <5tQuRIbKegT2cU7GYnQxyGM8h76CCYnoS47w71eDpsi@akmail> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Jun 2004 05:51:23 -0400 Cc: orbit-list@gnome.org Subject: Re: how to know wheter an object is still "alive" X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 15:22:34 -0000 Marcus Lunzenauer wrote: >In my application I have have to determine, whether that an object is still "alive" (reachable? active?) but I only have that object's IOR. > >I thought that the following code would do this for me, but it does not: > > >static CORBA_Object >getGovernor(const char *governorIOR, CORBA_Environment * ev){ > > CORBA_Object cur_gov = CORBA_OBJECT_NIL; > > // CHECK: is the current governor still active? > if (governorIOR){ > > // translate IOR > cur_gov = (CORBA_Object) CORBA_ORB_string_to_object(global_orb, governorIOR, ev); > > // that IOR is not translatable > if (ev->_major != CORBA_NO_EXCEPTION){ > > debug(DEFAULT_DEBUG_FLAGS, "Could not find registered governor.\n"); > CORBA_exception_free(ev); > > // FIXME: is this needed? > cur_gov = CORBA_OBJECT_NIL; > > // DON'T DO ANYTHING; governor is still active > } else { > debug(DEFAULT_DEBUG_FLAGS, "Registered governor still active.\n"); > } > } > > return cur_gov; >} > > please use CORBA_Object operation CORBA_boolean non_existent = CORBA_Object_non_existent (obj, ev); This is a very lightweight request that is handled by servers object container, object/service implementation is not involved. Following GUI CORBA tool is using this operation to test liveness of object in servers object container: http://casa.in-berlin.de/gnome-ior.html Regards, Frank -- GNOME http://www.gnome.org Frank Rehberger From jordan.crouse@amd.com Fri Jun 18 14:01:53 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from amdext4.amd.com (amdext4.amd.com [163.181.251.6]) by menubar.gnome.org (Postfix) with ESMTP id 3405D3B0845; Fri, 18 Jun 2004 14:01:53 -0400 (EDT) Received: from SAUSGW01.amd.com (sausgw01.amd.com [163.181.250.21]) by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id i5II2pP3017398; Fri, 18 Jun 2004 13:02:51 -0500 Received: from 163.181.250.1 by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (MMS v5.5.3)); Fri, 18 Jun 2004 13:01:45 -0500 Received: from ldcmail.amd.com (ldcmail.amd.com [147.5.200.40]) by amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id i5II1joj005091; Fri, 18 Jun 2004 13:01:45 -0500 (CDT) Received: from cosmic (cosmic.amd.com [147.5.201.206]) by ldcmail.amd.com (Postfix) with SMTP id AB6A960E5C; Fri, 18 Jun 2004 12: 01:44 -0600 (MDT) Date: Fri, 18 Jun 2004 12:04:44 -0600 From: "Jordan Crouse" To: gconf-list@gnome.org Message-ID: <20040618120444.0bea5ea3@cosmic> Organization: AMD X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) MIME-Version: 1.0 X-WSS-ID: 6CCDF1833685355-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Jun 2004 05:51:23 -0400 Cc: orbit-list@gnome.org Subject: x86_64 cross compiling X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 18:01:53 -0000 Sorry for the lack of in depth debug detail in this message, I'm running gconf and friends on an embedded system, so in depth debugging is coming along slowly if at all. Basically, the situation is this: I'm cross compiling gconf 2.6.2, orbit 2.10.2 and all associated libraries on an Gentoo based Opteron system targeted to a i486 machine. Because the Opteron is headless, I also needed to compile several 64 bit native packages as well (most notably orbit2 for a native 64 bit orbit-idl-2 compiler). So, turning to the target machine, running anything related to the gconfd daemon results in the following (gconftool-2 --direct does not cause this to happen): ** ERROR **: Attempted to marshal a bogus / dead object 0xbffff860 type I've tried this with gconftool-2, gconf-sanity-check-2, and rhythmbox (the only other gconf aware app I have on this system at the moment). All of them have slightly different addresses on the bogus type in question. GDB traces on all applications show a common ancestry as follows: #6 0x40d31386 in g_log () from /usr/lib/libglib-2.0.so.0 #7 0x40996780 in ORBit_marshal_object () from /usr/lib/libORBit-2.so.0 #8 0x4099cfc3 in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0 #9 0x409917e4 in ORBit_small_freekids () from /usr/lib/libORBit-2.so.0 #10 0x40992360 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0 #11 0x4099212d in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0 #12 0x409aa7c2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0 #13 0x40b246d0 in ConfigServer_add_client () from /usr/lib/libgconf-2.so.4 #14 0x40b181e9 in gconf_engine_key_is_writable () from /usr/lib/libgconf-2.so.4 #15 0x40b182f3 in gconf_engine_key_is_writable () from /usr/lib/libgconf-2.so.4 #16 0x40b143ae in gconf_engine_pop_owner_usage () from /usr/lib/libgconf-2.so.4 #17 0x40b14508 in gconf_engine_pop_owner_usage () from /usr/lib/libgconf-2.so.4 #18 0x40b15378 in gconf_engine_get_fuller () from /usr/lib/libgconf-2.so.4 #19 0x40b156b2 in gconf_engine_get_entry () from /usr/lib/libgconf-2.so.4 ConfgServer_add_client() comes from from the compiled GConfX.idl code, and I assume this is where the problem lies (I'm not very familiar with Gnome, so please bear with me). Others using the same setup I am using have reported successful code with an 32 bit x86 cross compiling for x86 and ARM architectures. And obviously if there was a platform independent bug in the .idl it would have been discovered and fixed by now. So I would say that points at either the 64 bit platform or the lack of a complete set of native Gnome tools as the issue that I'm up against. So my question for the experts is this: Is it possible that my native 64 bit orbit-idl-2 compiler is making assumptions about the offsets of the various variables, and thereby producing code that is confusing to a 32 bit machine? I do know that Orbit does care about the alignment of pointers (ORBIT_ALIGNOF_CORBA_POINTER and others), but like I said, I'm not very knowledgeable about how all this works, so I'm not sure if thats significant or a red herring. It would be much easier for me to get more indepth debugging information if I could get some advice on where to look (I can't cram all the code on the system, but I might be able to get one or two packages on there if I needed to). Please CC me, as I am on neither list. Thanks for your assistance. Regards, Jordan PS: I do understand I could just chroot and use the i486 cross compiled orbit-idl-2 on the Opteron, but others might use this same setup for building for non-x86 architectures as well, so it would be nice to get to the root of the issue. From Frank.Rehberger@web.de Sat Jun 19 20:19:28 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp05.web.de (smtp05.web.de [217.72.192.209]) by menubar.gnome.org (Postfix) with ESMTP id A901E3B0947 for ; Sat, 19 Jun 2004 20:19:28 -0400 (EDT) Received: from casa.in-dsl.de ([217.197.85.163] helo=web.de) by smtp05.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #26) id 1Bbq3T-0003Du-00 for orbit-list@gnome.org; Sun, 20 Jun 2004 02:19:28 +0200 Message-ID: <40D4D81D.9090007@web.de> Date: Sun, 20 Jun 2004 02:19:41 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: "orbit-list@gnome.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Frank.Rehberger@web.de Subject: ORBit2- webpage update X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 00:19:28 -0000 Hi, Updated www.gnome.org/projects/ORBit2/documentation.html Changes: "Beginners Doc" - Version 1.6 fixes at sample code * non-gcc fixes in example-toolkit.c * build system using "pkgconfig" tool * remove dependency to linc2, had been kept for old distributions anyway Adding cross-link to Andrew Burtons Tutorial: "Writing GNOME Applets in GNOME-2" http://members.iinet.net.au/~adburton/articles/appletstutorial.html Adding cross-link to Mathieu Lacages Tutorial: "Bonobo Activation API Reference Manual" http://developer.gnome.org/doc/API/2.0/bonobo-activation/index.html Regards, Frank -- Frank Rehberger The Twelve Networking Truths - http://www.faqs.org/rfcs/rfc1925.html From Frank.Rehberger@web.de Sun Jun 20 17:03:36 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp07.web.de (smtp07.web.de [217.72.192.225]) by menubar.gnome.org (Postfix) with ESMTP id 480213B0CD5 for ; Sun, 20 Jun 2004 17:03:36 -0400 (EDT) Received: from casa.in-dsl.de ([217.197.85.163] helo=web.de) by smtp07.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.101 #26) id 1Bc9TT-0002wN-00 for orbit-list@gnome.org; Sun, 20 Jun 2004 23:03:35 +0200 Message-ID: <40D5FBB5.5060203@web.de> Date: Sun, 20 Jun 2004 23:03:49 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: "orbit-list@gnome.org" Content-Type: multipart/mixed; boundary="------------000608060201090103020703" Sender: Frank.Rehberger@web.de Subject: native_code_set mix-up fixed X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 21:03:36 -0000 This is a multi-part message in MIME format. --------------000608060201090103020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael, fixed a bug in native-code-set handling I introduced a few weeks ago in HEAD :( This bug affects references to service-objects instanciated in local POA only. The bug affects interoperability with other ORBs and might cause (non-ORBit2) clients to reject ORBit2-IORs. Recent changes relating to codeset handling in ORBit2-HEAD set char-native-code-set==UTF16 wchar-native-code-set undefined. The fix corrects this, now it sets: char-native-code-set==UTF8 wchar-native-code-set==UTF16 Regards, Frank -- Frank Rehberger The Twelve Networking Truths - http://www.faqs.org/rfcs/rfc1925.html --------------000608060201090103020703 Content-Type: text/x-patch; name="iop-profiles.c-native_code_set.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="iop-profiles.c-native_code_set.patch" Index: iop-profiles.c =================================================================== RCS file: /cvs/gnome/ORBit2/src/orb/orb-core/iop-profiles.c,v retrieving revision 1.46 diff -u -r1.46 iop-profiles.c --- iop-profiles.c 8 May 2004 20:43:20 -0000 1.46 +++ iop-profiles.c 20 Jun 2004 20:39:23 -0000 @@ -589,8 +589,8 @@ csets->data.ForCharData.native_code_set = IOP_PROFILES_CODE_SET_UTF8; csets->data.ForCharData.conversion_code_sets = empty_conv_codesets; - csets->data.ForCharData.native_code_set = IOP_PROFILES_CODE_SET_UTF16; - csets->data.ForCharData.conversion_code_sets = empty_conv_codesets; + csets->data.ForWcharData.native_code_set = IOP_PROFILES_CODE_SET_UTF16; + csets->data.ForWcharData.conversion_code_sets = empty_conv_codesets; mci->components = g_slist_append (mci->components, csets); } --------------000608060201090103020703-- From bowie.owens@csiro.au Sun Jun 20 19:39:42 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from csiromail2.vic.csiro.au (csiromail2.vic.csiro.au [138.194.2.13]) by menubar.gnome.org (Postfix) with ESMTP id 2ACED3B0D84; Sun, 20 Jun 2004 19:39:42 -0400 (EDT) Received: from csiromail2.vic.csiro.au (localhost.localdomain [127.0.0.1]) by localhost.vic.csiro.au (Postfix) with ESMTP id B6D1F54018; Mon, 21 Jun 2004 09:39:39 +1000 (EST) Received: from gombak.vic.cmis.CSIRO.AU (gombak.vic.cmis.csiro.au [138.194.30.18]) by csiromail2.vic.csiro.au (Postfix) with ESMTP id AB23654013; Mon, 21 Jun 2004 09:39:39 +1000 (EST) Received: from csiro.au (phi.vic.cmis.CSIRO.AU [138.194.28.45]) by gombak.vic.cmis.CSIRO.AU (Postfix) with ESMTP id 44BD7652C6; Mon, 21 Jun 2004 09:39:39 +1000 (EST) Message-ID: <40D620A4.2090702@csiro.au> Date: Mon, 21 Jun 2004 09:41:24 +1000 From: Bowie Owens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yateen joshi References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: orbit-list@gnome.org, orbitcpp-list , Ritesh Kumar Kakar Subject: Re: Orbit2 Details X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 23:39:42 -0000 yateen joshi wrote: >Hi, > >I am on a lookout for a CORBA that will satisfy my following requirements. I tried to get the information for the same through various documents on Orbit and Orbit2, but could not find much. It will be appreciated if I get following information (in short ). > > Some of your questions will be answered by reading the home page: http://www.gnome.org/projects/ORBit2/ But here are some answers relating to the C++ bindings. There is, however, a separate list for discussing the C++ bindings. It is: orbitcpp-list@gnome.org > >3. What bindings are supported (e.g. C++, JAVA, C)? > > C++ is supported as a thin wrapper around the C binding. Orbitcpp it less mature than the C binding but quite capable for many tasks. If you find something that you need is not implemented, please email the mailing list or post a bug in bugzilla. Lots of things can be sorted out quite quickly if we know they aren't wrappered properly. >4. Performance > a. Good C++ Speed > > The C++ binding is wrapper around the C binding. As such the performance will be similar but slightly slower with slightly higher memory consumption. >5. Does it provide following features - > l. C++ STL support > > Depends what you mean by support. We don't package a version of the STL with orbitcpp but we don't interfere with it either. So you should be able to use as much of the standard library as your compiler supports. Orbitcpp works well with g++ which comes with an implementation of the standard library. > m. C++ design pattern support > > Again, we don't provide any implementations of any design patterns but we shouldn't be interfering with any code or libraries you want to make use of. The source code is freely available so it is a good idea for you to download it and try using the code yourself. -- Bowie Owens CSIRO Mathematical & Information Sciences phone : +61 3 9545 8055 fax : +61 3 9545 8080 mobile : 0425 729 875 email : Bowie.Owens@csiro.au From dharter@sopragroup.com Tue Jun 22 11:18:28 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by menubar.gnome.org (Postfix) with ESMTP id 094F63B08C2 for ; Tue, 22 Jun 2004 11:18:27 -0400 (EDT) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i5MFIMsO022320 for ; Tue, 22 Jun 2004 17:18:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4586C.27F4A578" Date: Tue, 22 Jun 2004 17:18:22 +0200 Message-ID: <51043592743D154DA9C89694EDA1DD0901639182@WEXCHBE02-VS.ptx.fr.sopra> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: orbit2 idl output directory Thread-Index: AcRYbCfVD8AF6QbQTg6v+JUP8YDCAA== From: "Harter Damien" To: X-OriginalArrivalTime: 22 Jun 2004 15:24:37.0078 (UTC) FILETIME=[07530F60:01C4586D] X-Scanned-By: MIMEDefang 2.38 Subject: orbit2 idl output directory X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 15:18:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4586C.27F4A578 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have my Makefile in directory "." in which I use the orbit-idl-2 = command. The problem is that it generates the files in the current = directory but I want them to be generated where the idl file is... In = some words, I'd like to do so : orbit-idl-2 -dir=3D../src/ ../src/myidl.idl Thanks for advises ! Damien ------_=_NextPart_001_01C4586C.27F4A578 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable orbit2 idl output directory

I have my Makefile in directory "." in which = I use the orbit-idl-2 command. The problem is that it generates the = files in the current directory but I want them to be generated where the = idl file is... In some words, I'd like to do so :
orbit-idl-2 -dir=3D../src/ ../src/myidl.idl

Thanks for advises !
Damien

------_=_NextPart_001_01C4586C.27F4A578-- From bowie.owens@csiro.au Tue Jun 22 18:50:29 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from csiromail2.vic.csiro.au (csiromail2.vic.csiro.au [138.194.2.13]) by menubar.gnome.org (Postfix) with ESMTP id E999C3B075C for ; Tue, 22 Jun 2004 18:50:28 -0400 (EDT) Received: from csiromail2.vic.csiro.au (localhost.localdomain [127.0.0.1]) by localhost.vic.csiro.au (Postfix) with ESMTP id 87B7D5400D; Wed, 23 Jun 2004 08:50:26 +1000 (EST) Received: from gombak.vic.cmis.CSIRO.AU (gombak.vic.cmis.csiro.au [138.194.30.18]) by csiromail2.vic.csiro.au (Postfix) with ESMTP id 7B93254003; Wed, 23 Jun 2004 08:50:26 +1000 (EST) Received: from csiro.au (phi.vic.cmis.CSIRO.AU [138.194.28.45]) by gombak.vic.cmis.CSIRO.AU (Postfix) with ESMTP id 4EA10652C6; Wed, 23 Jun 2004 08:50:26 +1000 (EST) Message-ID: <40D8B83C.7000903@csiro.au> Date: Wed, 23 Jun 2004 08:52:44 +1000 From: Bowie Owens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harter Damien References: <51043592743D154DA9C89694EDA1DD0901639182@WEXCHBE02-VS.ptx.fr.sopra> In-Reply-To: <51043592743D154DA9C89694EDA1DD0901639182@WEXCHBE02-VS.ptx.fr.sopra> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: orbit-list@gnome.org Subject: Re: orbit2 idl output directory X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 22:50:29 -0000 Harter Damien wrote: > I have my Makefile in directory "." in which I use the orbit-idl-2 > command. The problem is that it generates the files in the current > directory but I want them to be generated where the idl file is... In > some words, I'd like to do so : > orbit-idl-2 -dir=../src/ ../src/myidl.idl > You can always get make to cd into the directory before executing orbit-idl-2. You can either hard code a rule or use a generic form like this one: %-common.c %-skels.c %-stubs.c %.h %-imodule.c: %.idl ( cd `echo $< | perl -ne 's,[^/]*$$,,; print'` ; orbit-idl-2 -I . --add-imodule `basename $<` ) This works with GNU make and requires perl. -- Bowie Owens CSIRO Mathematical & Information Sciences phone : +61 3 9545 8055 fax : +61 3 9545 8080 mobile : 0425 729 875 email : Bowie.Owens@csiro.au From bla@mailbox.co.za Wed Jun 23 04:17:48 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from mail02.infosat.net (mailout06.infosat.net [66.18.69.6]) by menubar.gnome.org (Postfix) with ESMTP id 52C733B0AE3 for ; Wed, 23 Jun 2004 04:17:47 -0400 (EDT) Received: from [66.18.70.41] (HELO mail01.infosat.net) by mail02.infosat.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 81819859 for orbit-list@gnome.org; Wed, 23 Jun 2004 10:17:39 +0200 Received: from [196.39.9.144] (account bla@mailbox.co.za) by mail01.infosat.net (CommuniGate Pro WebUser 4.1.8) with HTTP id 347852104 for orbit-list@gnome.org; Wed, 23 Jun 2004 10:17:38 +0200 From: "bla bla" To: orbit-list@gnome.org X-Mailer: CommuniGate Pro WebUser Interface v.4.1.8 Date: Wed, 23 Jun 2004 10:17:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Subject: ORBit2 to SUN ORB X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 08:17:48 -0000 Greetings I'm having a problem getting my C client using ORBit2 to connect to a Java server using SUN's ORB. I believe there was an entry in the FAQ that referred to the integration of ORBs and how there was a problem a developer had to get around in order for the ORB's to communicate. What is that problem? My C client connects to the SUN ORB without hassle using corbaloc/CosNaming, but when the client needs a bound object resolved it hangs in a loop of forwards and requests. I can paste the actual packets of this communication and the source code if anyone requires. Has anyone else had this problem? Thanks Mike _____________________________________________________________________ For super low premiums ,click here http://www.dialdirect.co.za/quote From fta@cube.opentransit.net Thu Jun 24 08:40:54 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from cube.opentransit.net (cube.opentransit.net [193.251.151.83]) by menubar.gnome.org (Postfix) with ESMTP id A14CB3B09A1 for ; Thu, 24 Jun 2004 08:40:53 -0400 (EDT) Received: from cube.opentransit.net (nobody@localhost [127.0.0.1]) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) with ESMTP id i5OCeplj020623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jun 2004 14:40:51 +0200 Received: (from fta@localhost) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) id i5OCepMO020622; Thu, 24 Jun 2004 14:40:51 +0200 Date: Thu, 24 Jun 2004 14:40:51 +0200 From: Fabien Tassin To: orbit-list@gnome.org Message-ID: <20040624124051.GG16986@opentransit.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040523i Subject: Re: ORBit2 to SUN ORB X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 12:40:54 -0000 According to bla bla: > > I'm having a problem getting my C client using ORBit2 to > connect to a Java server using SUN's ORB. I believe there > was an entry in the FAQ that referred to the integration of > ORBs and how there was a problem a developer had to get > around in order for the ORB's to communicate. What is that > problem? > > My C client connects to the SUN ORB without hassle using > corbaloc/CosNaming, but when the client needs a bound > object resolved it hangs in a loop of forwards and > requests. I can paste the actual packets of this > communication and the source code if anyone requires. Has > anyone else had this problem? I have a similar loop 100% reproducible due to a bug in the Orbit2 forwarding code. Nobody seems to care here. I've patched Orbit2 and I'll submit it when/if I'm able to fix a side effect of my changes that occurs in CORBA_Object_release(). /Fabien From gatecrasher01@hotmail.com Mon Jun 28 01:07:36 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from hotmail.com (bay17-f36.bay17.hotmail.com [64.4.43.86]) by menubar.gnome.org (Postfix) with ESMTP id C2C853B0701 for ; Mon, 28 Jun 2004 01:07:35 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Jun 2004 22:07:35 -0700 Received: from 192.83.231.203 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 28 Jun 2004 05:07:34 GMT X-Originating-IP: [192.83.231.203] X-Originating-Email: [gatecrasher01@hotmail.com] X-Sender: gatecrasher01@hotmail.com From: "Jeremy Centenera" To: orbit-list@gnome.org Date: Mon, 28 Jun 2004 14:37:34 +0930 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2004 05:07:35.0138 (UTC) FILETIME=[D301D420:01C45CCD] Subject: Create Alias X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2004 05:07:36 -0000 Hi, How do you create an alias??? An alias has a corba typecode of CORBA_tk_alias=21. Thanks Jeremy _________________________________________________________________ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail From gatecrasher01@hotmail.com Mon Jun 28 01:08:27 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from hotmail.com (bay17-f43.bay17.hotmail.com [64.4.43.93]) by menubar.gnome.org (Postfix) with ESMTP id 024323B0E96 for ; Mon, 28 Jun 2004 01:08:27 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Jun 2004 22:08:26 -0700 Received: from 192.83.231.203 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 28 Jun 2004 05:08:26 GMT X-Originating-IP: [192.83.231.203] X-Originating-Email: [gatecrasher01@hotmail.com] X-Sender: gatecrasher01@hotmail.com From: "Jeremy Centenera" To: orbit-list@gnome.org Date: Mon, 28 Jun 2004 14:38:26 +0930 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2004 05:08:26.0431 (UTC) FILETIME=[F19484F0:01C45CCD] Subject: Create Alias X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2004 05:08:27 -0000 Hi, How do you create an alias??? An alias has a corba typecode of CORBA_tk_alias=21. Thanks Jeremy _________________________________________________________________ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail From Frank.Rehberger@web.de Tue Jun 29 10:07:52 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp.hia.no (smtp.hia.no [158.36.178.5]) by menubar.gnome.org (Postfix) with ESMTP id ED35E3B094A for ; Tue, 29 Jun 2004 10:07:51 -0400 (EDT) Received: from smtp.hia.no (localhost.localdomain [127.0.0.1]) by smtp.hia.no (8.12.10/8.12.9) with ESMTP id i5TE7qqK013875 for ; Tue, 29 Jun 2004 16:07:52 +0200 Received: from web.de (wlan158.krs.hia.no [158.36.232.158]) by smtp.hia.no (8.12.10/8.12.9) with ESMTP id i5TE7paX013867; Tue, 29 Jun 2004 16:07:51 +0200 Message-ID: <40E171A8.4020302@web.de> Date: Tue, 29 Jun 2004 15:42:00 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Jeremy Centenera References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: orbit-list@gnome.org Subject: Re: Create Alias X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 14:07:52 -0000 Jeremy Centenera wrote: > Hi, > > How do you create an alias??? An alias has a corba typecode of > CORBA_tk_alias=21. > in IDL file define new type using "typedef" --------------- typedef string mystring; module { interface MyInterface { echo (in mystring msg); }; }; --------------- -- Frank Rehberger The Twelve Networking Truths - http://www.faqs.org/rfcs/rfc1925.html From Frank.Rehberger@web.de Tue Jun 29 10:07:52 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from smtp.hia.no (smtp.hia.no [158.36.178.5]) by menubar.gnome.org (Postfix) with ESMTP id 4C0DB3B095A for ; Tue, 29 Jun 2004 10:07:52 -0400 (EDT) Received: from smtp.hia.no (localhost.localdomain [127.0.0.1]) by smtp.hia.no (8.12.10/8.12.9) with ESMTP id i5TE7qqK013888 for ; Tue, 29 Jun 2004 16:07:52 +0200 Received: from web.de (wlan158.krs.hia.no [158.36.232.158]) by smtp.hia.no (8.12.10/8.12.9) with ESMTP id i5TE7qaX013876; Tue, 29 Jun 2004 16:07:52 +0200 Message-ID: <40E1724D.4050402@web.de> Date: Tue, 29 Jun 2004 15:44:45 +0200 From: Frank Rehberger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Fabien Tassin References: <20040624124051.GG16986@opentransit.net> In-Reply-To: <20040624124051.GG16986@opentransit.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Cc: orbit-list@gnome.org Subject: Re: ORBit2 to SUN ORB X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 14:07:52 -0000 Fabien Tassin wrote: >According to bla bla: > > >>I'm having a problem getting my C client using ORBit2 to >>connect to a Java server using SUN's ORB. I believe there >>was an entry in the FAQ that referred to the integration of >>ORBs and how there was a problem a developer had to get >>around in order for the ORB's to communicate. What is that >>problem? >> >>My C client connects to the SUN ORB without hassle using >>corbaloc/CosNaming, but when the client needs a bound >>object resolved it hangs in a loop of forwards and >>requests. I can paste the actual packets of this >>communication and the source code if anyone requires. Has >>anyone else had this problem? >> >> > >I have a similar loop 100% reproducible due to a bug >in the Orbit2 forwarding code. Nobody seems to care here. >I've patched Orbit2 and I'll submit it when/if I'm able >to fix a side effect of my changes that occurs in CORBA_Object_release(). > > I am very much interested in your patch ;) Please, can I have a look at your patch? Regards, Frank -- Frank Rehberger The Twelve Networking Truths - http://www.faqs.org/rfcs/rfc1925.html From michael@ximian.com Tue Jun 29 10:16:49 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id 7FB6A3B0735 for ; Tue, 29 Jun 2004 10:16:49 -0400 (EDT) Received: (qmail 24888 invoked from network); 29 Jun 2004 14:16:48 -0000 Received: from localhost (HELO wlan452.krs.hia.no) (michael@127.0.0.1) by localhost with SMTP; 29 Jun 2004 14:16:48 -0000 From: Michael Meeks To: Fabien Tassin In-Reply-To: <20040624124051.GG16986@opentransit.net> References: <20040624124051.GG16986@opentransit.net> Content-Type: text/plain Organization: Ximian. Date: Tue, 29 Jun 2004 15:04:44 +0100 Message-Id: <1088517884.30397.9.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit Cc: orbit Subject: Re: ORBit2 to SUN ORB X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 14:16:49 -0000 Hi Fabien, On Thu, 2004-06-24 at 14:40 +0200, Fabien Tassin wrote: > I have a similar loop 100% reproducible due to a bug > in the Orbit2 forwarding code. Nobody seems to care here. > I've patched Orbit2 and I'll submit it when/if I'm able > to fix a side effect of my changes that occurs in CORBA_Object_release(). I care; send in the patch, and we'll get it committed etc. I guess we've just not been handling forwards correctly somehow, no idea why we're suddenly getting lots of them ;-) Also, what version of ORBit2 are you using ? Regards, Michael. -- michael@ximian.com <><, Pseudo Engineer, itinerant idiot From fta@cube.opentransit.net Tue Jun 29 10:42:24 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from cube.opentransit.net (cube.opentransit.net [193.251.151.83]) by menubar.gnome.org (Postfix) with ESMTP id 516073B095A for ; Tue, 29 Jun 2004 10:42:24 -0400 (EDT) Received: from cube.opentransit.net (nobody@localhost [127.0.0.1]) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) with ESMTP id i5TEgKRm015674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jun 2004 16:42:21 +0200 Received: (from fta@localhost) by cube.opentransit.net (8.12.11/8.12.11/Debian-5) id i5TEgKJi015673; Tue, 29 Jun 2004 16:42:20 +0200 Date: Tue, 29 Jun 2004 16:42:20 +0200 From: Fabien Tassin To: Michael Meeks Message-ID: <20040629144220.GA13545@opentransit.net> References: <20040624124051.GG16986@opentransit.net> <1088517884.30397.9.camel@linux.site> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <1088517884.30397.9.camel@linux.site> User-Agent: Mutt/1.5.6+20040523i Cc: orbit Subject: Re: ORBit2 to SUN ORB X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 14:42:24 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline According to Michael Meeks: > > Hi Fabien, > > On Thu, 2004-06-24 at 14:40 +0200, Fabien Tassin wrote: > > I have a similar loop 100% reproducible due to a bug > > in the Orbit2 forwarding code. Nobody seems to care here. > > I've patched Orbit2 and I'll submit it when/if I'm able > > to fix a side effect of my changes that occurs in CORBA_Object_release(). > > I care; glad to read this :) > send in the patch, and we'll get it committed etc. I guess > we've just not been handling forwards correctly somehow, no idea why > we're suddenly getting lots of them ;-) Also, what version of ORBit2 are > you using ? 2.10.2. As I said, my patch is incomplete and should probably not be applied as it is. It solves my urgent problems but there is probably a cleaner way to achieve this. The problem is that I hit an assertion when I CORBA_Object_release() my objects. ** ERROR **: file iop-profiles.c: line 359 (IOP_profile_equal): assertion failed: (!iiop1->object_key && !iiop2->object_key) aborting... this is caused by the one-line patch in iop-profiles.c. I can't think of a way to fix thix without major changes but I haven't investigated further. See my previous messages on the list for the reasons of each change. (note that I'm using only IIOP so maybe IOP_profiles_sync_objkey() should be modified for other profile types too.. to be consistent). /Fabien --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="orbit2-2.10.2.patch" diff -urb orbit2-2.10.2-orig/src/orb/orb-core/corba-object.c orbit2-2.10.2/src/orb/orb-core/corba-object.c --- orbit2-2.10.2-orig/src/orb/orb-core/corba-object.c 2004-01-14 12:04:10.000000000 +0100 +++ orbit2-2.10.2/src/orb/orb-core/corba-object.c 2004-06-14 18:31:03.000000000 +0200 @@ -290,7 +290,7 @@ OBJECT_LOCK (obj); - if (obj->connection) { + if (!obj->forward_locations && obj->connection) { if (ORBit_try_connection_T (obj)) { cnx = obj->connection; giop_connection_ref (cnx); @@ -302,7 +302,7 @@ } } - g_assert (obj->connection == NULL); + // g_assert (obj->connection == NULL); if (!obj->forward_locations) { plist = obj->profile_list; @@ -311,13 +311,13 @@ plist = obj->forward_locations; objkey = IOP_profiles_sync_objkey (plist); } - for (cur = plist; cur; cur = cur->next) { gpointer *pinfo = cur->data; if (IOP_profile_get_info (obj, pinfo, &iiop_version, &proto, &host, &service, &is_ssl, tbuf)) { + if (obj->connection == NULL) obj->connection = giop_connection_initiate ( obj->orb, proto, host, service, is_ssl ? LINK_CONNECTION_SSL : 0, iiop_version); diff -urb orbit2-2.10.2-orig/src/orb/orb-core/iop-profiles.c orbit2-2.10.2/src/orb/orb-core/iop-profiles.c --- orbit2-2.10.2-orig/src/orb/orb-core/iop-profiles.c 2004-04-21 16:58:48.000000000 +0200 +++ orbit2-2.10.2/src/orb/orb-core/iop-profiles.c 2004-06-25 00:04:10.000000000 +0200 @@ -138,7 +138,7 @@ ORBit_free (iiopi->object_key); } - iiopi->object_key = NULL; + // iiopi->object_key = NULL; } break; case IOP_TAG_ORBIT_SPECIFIC: { diff -urb orbit2-2.10.2-orig/src/orb/orb-core/orbit-small.c orbit2-2.10.2/src/orb/orb-core/orbit-small.c --- orbit2-2.10.2-orig/src/orb/orb-core/orbit-small.c 2004-01-14 16:51:00.000000000 +0100 +++ orbit2-2.10.2/src/orb/orb-core/orbit-small.c 2004-06-14 18:34:09.000000000 +0200 @@ -628,6 +628,7 @@ } else giop_thread_new_check (NULL); + retry_request: cnx = ORBit_object_get_connection (obj); if (!cnx) { @@ -636,7 +637,6 @@ goto system_exception; } - retry_request: request_id = GPOINTER_TO_UINT (&obj); completion_status = CORBA_COMPLETED_NO; --T4sUOijqQbZv57TR-- From michael@ximian.com Tue Jun 29 11:29:34 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by menubar.gnome.org (Postfix) with ESMTP id A6C333B0914 for ; Tue, 29 Jun 2004 11:29:33 -0400 (EDT) Received: (qmail 28481 invoked from network); 29 Jun 2004 15:29:31 -0000 Received: from localhost (HELO wlan452.krs.hia.no) (michael@127.0.0.1) by localhost with SMTP; 29 Jun 2004 15:29:31 -0000 From: Michael Meeks To: Jeremy Centenera In-Reply-To: References: Content-Type: text/plain Organization: Ximian. Date: Tue, 29 Jun 2004 16:17:12 +0100 Message-Id: <1088522232.30396.34.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit Cc: orbit Subject: Re: Create Alias X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 15:29:34 -0000 On Mon, 2004-06-28 at 14:37 +0930, Jeremy Centenera wrote: > How do you create an alias??? An alias has a corba typecode of > CORBA_tk_alias=21. I'm guessing with the 'typedef' IDL keyword, HTH, Michael. -- michael@ximian.com <><, Pseudo Engineer, itinerant idiot From sandeep@cs.ucr.edu Wed Jun 30 08:09:27 2004 Return-Path: X-Original-To: orbit-list@gnome.org Delivered-To: orbit-list@gnome.org Received: from eon.cs.ucr.edu (eon.cs.ucr.edu [138.23.169.3]) by menubar.gnome.org (Postfix) with ESMTP id 27E673B0EA3 for ; Wed, 30 Jun 2004 08:09:27 -0400 (EDT) Received: from eon.cs.ucr.edu (localhost.localdomain [127.0.0.1]) by eon.cs.ucr.edu (8.12.8/8.12.8) with ESMTP id i5UC9QuU001796 for ; Wed, 30 Jun 2004 05:09:26 -0700 Received: from localhost (sandeep@localhost) by eon.cs.ucr.edu (8.12.8/8.12.8/Submit) with ESMTP id i5UC9QNE001792 for ; Wed, 30 Jun 2004 05:09:26 -0700 X-Authentication-Warning: eon.cs.ucr.edu: sandeep owned process doing -bs Date: Wed, 30 Jun 2004 05:09:26 -0700 (PDT) From: Sandeep Gupta To: orbit-list@gnome.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 03 Jul 2004 09:35:16 -0400 Subject: orbit2 2.10 configure problem X-BeenThere: orbit-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ORBit CORBA implementation use & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2004 12:09:27 -0000 this problem has been posted before with no solution yet... During the ./configure process of ORBit2-2.10 following error appears: checking for poptStrippedArgv in -lpopt... no configure: error: You must have popt version 1.5 or greater installed. My system has popt version 1.8.2. There must be small fix possible. thanks sandeep