Hello!
I have a strange bug compiling IDL files on Win32. I need to compile IDL
file that is not in the dir where omniidl2 is running. If I give omniidl2
absolute path to the file it works ok, but if I give it relative path it
makes files ".h" and "SK.cpp", just as I said. In my project I have no
possibility to retrieve full path ;(. What can I do with it?
Best regards,
Alik.
From glowstars@gmx.de Wed Dec 29 13:02:06 1999
From: glowstars@gmx.de (Thorsten Roskowetz)
Date: Wed, 29 Dec 1999 14:02:06 +0100 (MET)
Subject: [omniORB] omniORBpy and attributes in IDL (server side)
Message-ID: <8758.946472526@www11.gmx.net>
Hi,
can someone please enlighten me on how to implement
interface attributes server-side with omniORBpy?
The Python Language Mapping only mentions attributes
client side (basically an attribute is mapped to two
methods on the corresponding Python stub class, an
accessor an a modifier prefixed with '_get_' and
'_set_' respectively).
Cheers,
Thorsten
--
Sent through Global Message Exchange - http://www.gmx.net
From jfd@silicomp.fr Thu Dec 30 09:31:23 1999
From: jfd@silicomp.fr (Jean-Francois Denise)
Date: Thu, 30 Dec 1999 10:31:23 +0100
Subject: [omniORB] Generating IOR
Message-ID: <386B266B.27B01603@silicomp.com>
Hello,
Is it possible using omniorb2 to set at creation time an object IOR. I
need to create a specific multiple profile IOR.
Thanks.
--
^
/ \
/ \ Jean-Francois Denise
+---/ \---+ Software Engineer
| / \ | e-mail : jfd@silicomp.com
| /silicomp \ |
|/ingenierie \| Phone: (33) 4 76 41 66 66 Fax: (33) 4 76 41 66 67
|-------------|
| | 195, rue Lavoisier - BP 1
| G R O U P E | 38330 Montbonnot St Martin
+-------------+ FRANCE
S I L I C O M P
From rgruet@ina.fr Thu Dec 30 10:58:35 1999
From: rgruet@ina.fr (Richard Gruet)
Date: Thu, 30 Dec 1999 11:58:35 +0100
Subject: [omniORB] omniORBpy and attributes in IDL (server side)
References: <8758.946472526@www11.gmx.net>
Message-ID: <386B3ADB.3235EF94@ina.fr>
--------------18426228C7ED9E1DD3444ECC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thorsten Roskowetz wrote:
> can someone please enlighten me on how to implement
> interface attributes server-side with omniORBpy?
> The Python Language Mapping only mentions attributes
> client side (basically an attribute is mapped to two
> methods on the corresponding Python stub class, an
> accessor an a modifier prefixed with '_get_' and
> '_set_' respectively).
It's exactly the same on the server side. In your implementation class,
for a given attribute XXX,
you just have to define a pair of methods:
class MyInterfaceImpl(POA_MyModule.MyInterface):
...
def _get_XXX(self):
return theValueOfXXX
def _set_XXX(self, value):
# sets XXX to value
Cheers,
Richard
--------------18426228C7ED9E1DD3444ECC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thorsten Roskowetz wrote:
can someone please enlighten me on how to implement
interface attributes server-side with omniORBpy?
The Python Language Mapping only mentions attributes
client side (basically an attribute is mapped to two
methods on the corresponding Python stub class, an
accessor an a modifier prefixed with '_get_' and
'_set_' respectively).
It's exactly the same on the server side. In your implementation class,
for a given attribute XXX,
you just have to define a pair of methods:
class MyInterfaceImpl(POA_MyModule.MyInterface):
...
def _get_XXX(self):
return theValueOfXXX
def _set_XXX(self, value):
# sets XXX to value
Cheers,
Richard
--------------18426228C7ED9E1DD3444ECC--
From nickr@harlequin.co.uk Thu Dec 30 11:31:22 1999
From: nickr@harlequin.co.uk (Nick Reeves)
Date: Thu, 30 Dec 1999 11:31:22 GMT
Subject: [omniORB] Portable Interceptor
Message-ID: <199912301131.LAA23272@gpo.cam.harlequin.co.uk>
The competing proposals for Portable Interceptors have been formally
merged into a single revised spec orbos/99-12-02, and the nonsense of
the earlier specs has been removed.
Given the wide backing it seems likely to go through with only minor
amendments.
So this seems like a good time to ask what is the official omniORB
position on it.
Thanks again for the great work on adding POA !
--
Nick Reeves nickr@harlequin.co.uk
From glowstars@gmx.de Thu Dec 30 12:50:07 1999
From: glowstars@gmx.de (Thorsten Roskowetz)
Date: Thu, 30 Dec 1999 13:50:07 +0100 (MET)
Subject: [omniORB] omniORBpy and attributes in IDL (server side)
References: <386B3ADB.3235EF94@ina.fr>
Message-ID: <1075.946558207@www12.gmx.net>
Thanks! I was somewhat confused by the C++ mapping which
effectively hides that it invokes the _get_xxxx and _set_xxxx
methods too.
--
Sent through Global Message Exchange - http://www.gmx.net
From tei@elca.ch Thu Dec 30 15:25:31 1999
From: tei@elca.ch (Eicher Thomas)
Date: Thu, 30 Dec 1999 16:25:31 +0100
Subject: [omniORB] use 2.8 client with 2.7.1 server?
Message-ID: <000001bf52da$1f808dd0$1c9248c1@elca.ch>
Is it possible to use a client side built with omniORB 2.8 together with =
a
server side that was built using omniORB 2.7.1? I am not using Any's.
Thanks, Tom
______________________________________________
Tom Eicher ELCA Informatik AG
tei@elca.ch Steinstrasse 21
+41 (0)1 456 32 47 8003 Z=FCrich
http://www.elca.ch Switzerland
From taras@deka.kp.km.ua Thu Dec 30 08:16:42 1999
From: taras@deka.kp.km.ua (Viacheslav N Tararin)
Date: Thu, 30 Dec 1999 10:16:42 +0200
Subject: [omniORB] omniidl2 bug
Message-ID: <386B14EA.25C43720@deka.kp.km.ua>
This is a multi-part message in MIME format.
--------------E14C31724C1DC26ED2606274
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Hi.
1. First idl file:
module a {
module b {
interface Ziro {
short get_short();
};
};
};
2. Second idl file
module a {
typedef long TheLong;
module b {
interface One {
TheLong get_long();
};
};
};
3. Produced omniidl2 test.hh don't contain lines
typedef long TheLong;
I'm attach test files.
Environment: WinNT 4.0 SP3 VC6.0 omniORB2 2.8.0.
Happy New Year.
Tararin Slavik.
--------------E14C31724C1DC26ED2606274
Content-Type: application/x-unknown-content-type-idlfile;
name="test0.idl"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="test0.idl"
bW9kdWxlIGEgew0KICAgIG1vZHVsZSBiIHsNCiAgICAgICAgaW50ZXJmYWNlIFppcm8gew0K
ICAgICAgICAgICAgc2hvcnQgZ2V0X3Nob3J0KCk7DQogICAgICAgIH07DQogICAgfTsNCn07
--------------E14C31724C1DC26ED2606274
Content-Type: application/x-unknown-content-type-idlfile;
name="test.idl"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="test.idl"
I2luY2x1ZGUgPHRlc3QwLmlkbD4NCm1vZHVsZSBhIHsNCiAgICB0eXBlZGVmIGxvbmcgVGhl
TG9uZzsgDQogICAgbW9kdWxlIGIgew0KICAgICAgICBpbnRlcmZhY2UgT25lIHsNCiAgICAg
ICAgICAgIFRoZUxvbmcgZ2V0X2xvbmcoKTsNCiAgICAgICAgfTsNCiAgICB9Ow0KfTs=
--------------E14C31724C1DC26ED2606274--
From taras@deka.kp.km.ua Wed Dec 29 14:58:26 1999
From: taras@deka.kp.km.ua (Viacheslav N Tararin)
Date: Wed, 29 Dec 1999 16:58:26 +0200
Subject: [omniORB] omniidl2 bug
Message-ID: <386A2191.6980C494@deka.kp.km.ua>
Hi.
It's part of CosCollection.idl
interface KeyCollection : Collection {
// c o m p u t i n g t h e k e y s
void key (in any element, out any key)
raises (ElementInvalid);
void keys (in AnySequence elements, out AnySequence keys)
raises (ElementInvalid);
};
Prodused file CosCollection.hh containts:
(5114) virtual void key(const CORBA::Any & element, CORBA::Any *&
key) = 0;
(5115) virtual void _0RL__key(const CORBA::Any & element, CORBA::Any
*& key) {
(5116) key(element, key);
(5117) }
(5118) virtual void keys(const AnySequence & elements, AnySequence *&
keys) = 0;
(5119) virtual void _0RL__keys(const AnySequence & elements,
AnySequence *& keys) {
(5120) keys(elements, keys);
(5121) }
On WinNT it's prodused error
cl.exe /c /nologo /D__x86__ /D__NT__ /D__WIN32__ /GX /TP /MD
-I..\..\..\..\omni\include -I..\..\include -I..\..\include\ui
LLsControlsDynSK.cpp /Fo..\..\obj\LLsControlsDynSK.obj
LLsControlsDynSK.cpp
..\..\include\omg/CosCollection.hh(5114) : error C2064: term does not
evaluate to a function
..\..\include\omg/CosCollection.hh(5118) : error C2064: term does not
evaluate to a function
Environment WinNT 4.0 SP3 VC6.0 omniORB2 (2.8.0).
Happy New Year.
Tararin Slavik.
From jfd@silicomp.com Mon Dec 27 09:30:21 1999
From: jfd@silicomp.com (jfd)
Date: Mon, 27 Dec 1999 10:30:21 +0100
Subject: [omniORB] Implementation over multiple IP hosts
Message-ID: <386731AD.769FDC13@silicomp.com>
Il s'agit d'un message multivolet au format MIME.
--------------C884274C6704C9CD025577FC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I need to create an object implementation on a server running on an host
having multiple IP addresses. I want the implementation being accessible
through both IP interfaces. I can set a prefered host IP address or name
using OMNIORB_USEHOSTNAME but not a list of IP addresses.
I know that my question doesn't fit IOR single profile management. Host
name being part of IOR, if an implementation object is created using 2
different IP addresses, 2 profiles must be generated by the BOA when
creating the object implementation.
Is there a way using omniorb to do so.
Thanks.
--------------C884274C6704C9CD025577FC
Content-Type: text/x-vcard; charset=us-ascii;
name="jfd.vcf"
Content-Description: Carte pour jfd
Content-Disposition: attachment;
filename="jfd.vcf"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.ri.silicomp.fr id KAA08294
begin:vcard=20
n:Jean-Fran=E7ois;Denise
tel;work:+33-04/76/634863
x-mozilla-html:FALSE
url:www.ri.silicomp.com
org:Silicomp Research Institute;AppliBus
version:2.1
email;internet:jfd@silicomp.com
title:Research and Development
adr;quoted-printable:;;2 Avenue de Vignate=3D0D=3D0A;Gi=E8res;;F38610;Fra=
nce
fn:Denise Jean-Fran=E7ois
end:vcard
--------------C884274C6704C9CD025577FC--
From jeffdu@163.net Sun Dec 5 04:26:21 1999
From: jeffdu@163.net (Jeffrey Du)
Date: Sun, 5 Dec 1999 12:26:21 +0800
Subject: [omniORB] Problem of CORBA::String in MFC Application
Message-ID: <01bf3ed8$e1ce1260$c764100a@pc.public.guangzhou.gd.cn>
This is a multi-part message in MIME format.
------=_NextPart_000_001D_01BF3F1B.EFF15260
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
I am writing a CORBA program in VC++ 5.0 using omniORB 2.8 in =
Windows95. I find that
any functions in my program using CORBA::String will encounter an error =
when they return.
For example, here is my code of the function:
=20
int CWSInfoApp::InitCorbaServer()
{
......=20
CORBA::String_var p =3D orb->object_to_string(myobj);
......=20
=20
return(0); // an error occurs after return
}
=20
And the error message is:
=20
Microsoft Visual C++ Debug Library
Debug Assertion Failed
Program: .....
File: dbgdel.cpp
Line: 47
Exception: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
=20
I think the error occurs when releasing CORBA::String memory.=20
Please tell me how to solve this problem.
=20
Jeffrey Du
jeffdu@163.net
------=_NextPart_000_001D_01BF3F1B.EFF15260
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
I am writing a CORBA =
program in=20
VC++ 5.0 using omniORB 2.8 in Windows95. I find that
any functions in my program using =
CORBA::String=20
will encounter an error when they return.
For example, here is my code of the=20
function:
int =
CWSInfoApp::InitCorbaServer()
{
......
CORBA::String_var p =3D =
orb->object_to_string(myobj);
=
......
return(0); // an error =
occurs after=20
return
}
And the error message=20
is:
Microsoft Visual C++ =
Debug=20
Library
Debug=20
Assertion Failed
=20
Program: .....
File:=20
dbgdel.cpp
Line:=20
47
=20
Exception: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
I think the error =
occurs when=20
releasing CORBA::String memory.
Please tell me how to =
solve this=20
problem.
Jeffrey Du
------=_NextPart_000_001D_01BF3F1B.EFF15260--
From fcook@accesscom.com Wed Dec 1 05:52:21 1999
From: fcook@accesscom.com (Fred Cook)
Date: Tue, 30 Nov 1999 21:52:21 -0800
Subject: [omniORB] omniORB NT acnnot find omniORB linux
Message-ID: <3844B795.646B@accesscom.com>
My NT client cannot find my server that lives on Red Hat linux 6.1.
Both machines have fully functional omniORB installations. The echo eg3
examples work on both machines, but a client on one machine cannot find
the server on the other, it is as if the network was not present. There
is a valid network connection between the two machines (both ftp and
telnet work). Can anyone give me some advice?
Fred Cook.
From dgrisby@uk.research.att.com Wed Dec 1 09:36:41 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 01 Dec 1999 09:36:41 +0000
Subject: [omniORB] omniORB NT acnnot find omniORB linux
In-Reply-To: Your message of "Tue, 30 Nov 1999 21:52:21 PST."
<3844B795.646B@accesscom.com>
Message-ID: <199912010936.JAA05664@pineapple.cam-orl.co.uk>
On Tuesday 30 November, Fred Cook wrote:
> My NT client cannot find my server that lives on Red Hat linux 6.1.
> Both machines have fully functional omniORB installations. The echo eg3
> examples work on both machines, but a client on one machine cannot find
> the server on the other, it is as if the network was not present. There
> is a valid network connection between the two machines (both ftp and
> telnet work). Can anyone give me some advice?
Are you running the naming service on both machines? If so, that's
your problem. You should run the naming service on a single machine,
and point both machines to it.
If that isn't your problem, you need to give more details. Does the
eg2 example work between the two machines if you copy the IOR across?
HTH,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Wed Dec 1 10:15:03 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 01 Dec 1999 10:15:03 +0000
Subject: [omniORB] omniidl crash on NT
In-Reply-To: Your message of "Tue, 30 Nov 1999 22:31:32 +0100."
<01BF3B86.22A09930.eici@ovsag.de>
Message-ID: <199912011015.KAA05749@pineapple.cam-orl.co.uk>
On Tuesday 30 November, Christian Eibl wrote:
[...]
> omniidl: Running front end
> omni-cpp: stdout: Bad file descriptor
It looks like the C pre-processor failed for some reason. Can you try
running omni-cpp on the IDL file to see what happens?
What compiler version did you use? I've only tried it with VC++ 5, so
maybe there are problems with other compilers.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Wed Dec 1 11:22:05 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 01 Dec 1999 11:22:05 +0000
Subject: [omniORB] Finding methods in objects / part 2
In-Reply-To: Your message of "Mon, 29 Nov 1999 16:41:33 +0100."
Message-ID: <199912011122.LAA06030@pineapple.cam-orl.co.uk>
On Monday 29 November, Casillas_Juan_M/madrid_tecnologia@sinvest.es wrote:
> well, our sample scenario is one program (say A) asking for =20
> all the interfaces that have a method called hello(). All the >
> interfaces running must answer its IOR and type (to allow A
> comunicate with them) to A.
[... finding objects which respond to events ...]
> How A can instantiate new objects from the implementations,
> A knows the IOR, but ... program A can't cast dinamically new
> objects from a string ... or It can ?
I don't think you mean "instantiate new objects...". I think you mean
you want A to use an _object reference_ to an object which has a type
that A does not know. In this case, there is no problem with creating
the reference, and invoking operations on it with DII. You obviously
can't use static invocation since you don't have compile-time
knowledge of it.
That said, I think you need to carefully re-think what it is you are
trying to do. As someone pointed out earlier, knowing that a server
supports an interface with an operation named hello() doesn't do you
any good at all, since the name of an operation doesn't tell you
anything about what it does. Not only that, but there is no guarantee
that the arguments to different hello() operations are the
same. Consider two interfaces:
interface I {
void hello();
};
interface J {
struct myStruct {
// Some complex struct
};
double hello(in myStruct);
};
If a client of your proposed system asks for objects supporting
hello(), and gets back references to instances of I and J, how can it
possibly do anything useful? Especially since it doesn't have
compile-time knowledge of J::myStruct.
Maybe what you really want to do is something like:
interface HelloSupporter {
void hello(); // Fixed semantics for hello()
};
interface I : HelloSupporter {
// Some other stuff
};
interface J : HelloSupporter {
// Some different stuff
};
Now you can usefully find objects which derive from HelloSupporter,
and call their hello() operations, using the static invocation
interface (since you have compile-time knowledge of the HelloSupporter
interface), and have some idea as to what hello() will do.
HTH,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From eici@ovsag.de Wed Dec 1 15:56:05 1999
From: eici@ovsag.de (Christian Eibl)
Date: Wed, 1 Dec 1999 16:56:05 +0100
Subject: [omniORB] omniidl crash on NT
Message-ID: <01BF3C1D.09D81EE0.eici@ovsag.de>
i'm using MSVC++ 6.0 (apart from that, i'm healthy ;-)
everything else in OmniORB seems to work fine, so i suppose it's not
a compiler problem.
below the outputs from the idl(pre)compiler and an
excerpt of the code where it crashes (seems that things mess up where
you are converting to the FILE struct...)
###########
E:\ORB\omniORB_280\src\lib\omniORBpy\examples>omni-cpp -v echo_example.idl
GNU CPP version omni-cpp-1.0
#include "..." search starts here:
End of search list.
# 1 "echo_example.idl"
module Example {
interface Echo {
string echoString(in string mesg);
};
};
###########
E:\ORB\omniORB_280\src\lib\omniORBpy\examples>omniidl2 -v echo_example.idl
omniidl2: preprocessing echo_example.idl
echo_example.idl
omniidl2: parsing echo_example.idl
omniidl2: BE processing on echo_example.idl
###########
E:\ORB\omniORB_280\src\lib\omniORBpy\examples>cl
Optimierender Microsoft (R) 32-Bit C/C++-Compiler, Version 12.00.8168, fuer x86
Copyright (C) Microsoft Corp 1984-1998. Alle Rechte vorbehalten.
##################
# CODE
##################
extern "C" {
static PyObject* IdlPyCompile(PyObject* self, PyObject* args)
{
PyObject* pyfile;
if (!PyArg_ParseTuple(args, "O!", &PyFile_Type, &pyfile))
return 0;
FILE* file = PyFile_AsFile(pyfile);
PyObject* pyname = PyFile_Name(pyfile);
const char* name = PyString_AsString(pyname);
- file 0x78037c88
+ _ptr 0x00000000 ""
_cnt 0
+ _base 0x00000000 ""
_flag 1
_file 3
_charbuf 0
_bufsiz 0
+ _tmpfname 0x00000000 ""
+ name 0x008591e4 "omni-cpp -lang-c++ -undef -D__OMNIIDL__=0x2301 echo_example.idl"
Loc>> _CORBA_Boolean success = AST::process(file, name);
PyObject* result;
if (success) {
PythonVisitor v;
AST::tree()->accept(v);
result = v.result();
}
else {
Py_INCREF(Py_None);
result = Py_None;
}
AST::tree()->clear();
return result;
}
> -----Ursprungliche Nachricht-----
> Von: Duncan Grisby [SMTP:dgrisby@uk.research.att.com]
> Gesendet am: Mittwoch, 1. Dezember 1999 11:15
> An: eici@ovsag.de
> Cc: 'omniorb-list@uk.research.att.com'
> Betreff: Re: [omniORB] omniidl crash on NT
>
> On Tuesday 30 November, Christian Eibl wrote:
>
> [...]
>
> > omniidl: Running front end
> > omni-cpp: stdout: Bad file descriptor
>
> It looks like the C pre-processor failed for some reason. Can you try
> running omni-cpp on the IDL file to see what happens?
>
> What compiler version did you use? I've only tried it with VC++ 5, so
> maybe there are problems with other compilers.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --
>
>
From dgrisby@uk.research.att.com Wed Dec 1 16:25:41 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 01 Dec 1999 16:25:41 +0000
Subject: [omniORB] omniidl crash on NT
In-Reply-To: Your message of "Wed, 01 Dec 1999 16:56:05 +0100."
<01BF3C1D.09D81EE0.eici@ovsag.de>
Message-ID: <199912011625.QAA07993@pineapple.cam-orl.co.uk>
On Wednesday 1 December, Christian Eibl wrote:
> i'm using MSVC++ 6.0 (apart from that, i'm healthy ;-)
> everything else in OmniORB seems to work fine, so i suppose it's not
> a compiler problem.
Has anyone successfully compiled omniORBpy with VC++ 6? If so, did
you have to do anything special to make it work?
> below the outputs from the idl(pre)compiler and an
> excerpt of the code where it crashes (seems that things mess up where
> you are converting to the FILE struct...)
It looks from the debugging like everything is doing the right thing,
but there's clearly something wrong. My only guess is that the pipe
between the C pre-processor and the IDL front end isn't working. As an
experiment, try
omniidl -v -N -bpython echo_example.idl
That will compile the IDL file directly without invoking the
pre-processor. If that works, I'll have to think about replacing the
pipe with a temporary file. If it doesn't work, then I'll have to
think again.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From Dejan.Polomcic@telecom.co.nz Wed Dec 1 21:09:58 1999
From: Dejan.Polomcic@telecom.co.nz (Dejan Polomcic)
Date: Thu, 02 Dec 1999 10:09:58 +1300
Subject: [omniORB] Event Daemon(Event Service) Error
Message-ID:
hi,
I have come across the following Error while using paul nader's event =
service, could anyone tell me what causes the error:
The following stmts show gdb of the core :
[nasex]/home/nasex/menu > gdb ../bin/eventd core
Wildebeest is free software and you are welcome to distribute copies of
it under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for Wildebeest; type "show warranty"
for details.
Hewlett-Packard Wildebeest 1.0 (based on GDB 4.16)
(built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00)
Copyright 1996, 1997 Free Software Foundation, Inc...(no debugging symbols =
found)...
Core was generated by `eventd'.
Program terminated with signal 6, Aborted.
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.
(no debugging symbols found)...(no debugging symbols found)...(no =
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...#0 0xc01e8498 in kill () from /usr/lib/libc=
.2
#0 0xc01e8498 in kill () from /usr/lib/libc.2
(gdb) bt
#0 0xc01e8498 in kill () from /usr/lib/libc.2
#1 0xc01826c4 in raise () from /usr/lib/libc.2
#2 0xc01591f0 in abort () from /usr/lib/libc.2
#3 0xc0159880 in _assert () from /usr/lib/libc.2
#4 0xd507c928 in Strand::decrRefCount () from //home/nasex/lib/libomniORB2=
.sl.8
#5 0xd508cc7c in tcpSocketRendezvouser::run_undetached () from //home/nase=
x/lib/libomniORB2.sl.8
#6 0xc02fea20 in omni_thread_wrapper () from //home/nasex/lib/libomnithrea=
d.sl.2
#7 0xc0ff9c4c in __pthread_create_system () from /usr/lib/libpthread.1
cheers
dejan
From eici@ovsag.de Wed Dec 1 21:15:29 1999
From: eici@ovsag.de (Christian Eibl)
Date: Wed, 1 Dec 1999 22:15:29 +0100
Subject: AW: [omniORB] omniidl crash on NT
Message-ID: <01BF3C49.D4D807F0.eici@ovsag.de>
> It looks from the debugging like everything is doing the right thing,
> but there's clearly something wrong. My only guess is that the pipe
> between the C pre-processor and the IDL front end isn't working. As an
> experiment, try
>
> omniidl -v -N -bpython echo_example.idl
>
E:\ORB\omniORB_280\src\lib\omniORBpy\examples>omniidl -v -N -bpython echo_example.idl
omniidl: Importing back-end `python'
omniidl: Running front end
crashes at the same location...
stackdump:
NTDLL! 77f7cde6()
NTDLL! 77f77506()
fread(void * 0x009a6df0, unsigned int 1, unsigned int 8192, _iobuf * 0x78037ca8) line 75 + 9 bytes
yy_get_next_buffer() line 623 + 216 bytes
yylex() line 458 + 5 bytes
yyparse() line 387 + 5 bytes
AST::process(_iobuf * 0x78037ca8, const char * 0x0086f394) line 134 + 5 bytes
IdlPyCompile(_object * 0x00000000, _object * 0x0086d970) line 1079 + 13 bytes
PYTHON15! 1e10f90f()
PYTHON15! 1e10f821()
PYTHON15! 1e10e734()
PYTHON15! 1e10fc53()
PYTHON15! 1e10f82b()
PYTHON15! 1e103dbd()
PYTHON15! 1e103f4b()
main(int 0, char * * 0x1e16903c) line 1155 + 20 bytes
PYTHON15! 1e17be18()
seems your guess is right, because when i try it with omniidl -E then:
E:\ORB\omniORB_280\src\lib\omniORBpy\examples>omniidl -v -E -bpython echo_exampl
e.idl
omniidl: Importing back-end `python'
omniidl: Preprocessing `echo_example.idl' with `omni-cpp -lang-c++ -undef -D__OM
NIIDL__=0x2301 -D__OMNIIDL_PYTHON__ echo_example.idl'
# 1 "echo_example.idl"
module Example {
interface Echo {
string echoString(in string mesg);
};
};
bye,
Chris E.
--
Christian Eibl
Object Vision Software AG, Munchen
Christian.Eibl@ovsag.de | www.ovsag.de
mobile: +49.171.7623844 or +43.676.3060031
From crawley@dstc.edu.au Thu Dec 2 05:23:05 1999
From: crawley@dstc.edu.au (Stephen Crawley)
Date: Thu, 02 Dec 1999 15:23:05 +1000
Subject: [omniORB] Finding methods in objects / part 2
In-Reply-To: Message from Duncan Grisby
of "Wed, 01 Dec 1999 11:22:05 GMT." <199912011122.LAA06030@pineapple.cam-orl.co.uk>
Message-ID: <199912020523.PAA04296@piglet.dstc.edu.au>
> On Monday 29 November, Casillas_Juan_M/madrid_tecnologia@sinvest.es wrote:
> > How A can instantiate new objects from the implementations,
> > A knows the IOR, but ... program A can't cast dinamically new
> > objects from a string ... or It can ?
>
> I don't think you mean "instantiate new objects...". I think you mean
> you want A to use an _object reference_ to an object which has a type
> that A does not know. In this case, there is no problem with creating
> the reference, and invoking operations on it with DII. You obviously
> can't use static invocation since you don't have compile-time
> knowledge of it.
>
> That said, I think you need to carefully re-think what it is you are
> trying to do. As someone pointed out earlier, knowing that a server
> supports an interface with an operation named hello() doesn't do you
> any good at all, since the name of an operation doesn't tell you
> anything about what it does. Not only that, but there is no guarantee
> that the arguments to different hello() operations are the
> same.
True.
If you are considering implementing an application that uses dynamic
discovery of interface types, it would be worthwhile taking a look
at the OMG MOF specification. You could use MOF in (at least) 2
ways to solve this sort of problem:
1) Define your own "type system" that expresses the semantics of
your interface types in an appropriate manner. Render this
type system as a MOF meta-model, generate IDL and server and
implement a compiler to populate your server with interface
types. Then do type discovery using the repository.
2) Make the MOF's meta-meta-model your type system and define
your application's information model as a MOF meta-model.
Then use an "off the shelf" MOF meta-model repository and
an "off-the-shelf" meta-model compiler to populate it.
While 2) is not what the MOF was originally designed for, if the
MOF Model is a rich enough information meta-model for you, this
will save you a lot of time.
-- Steve
From Casillas_Juan_M/madrid_tecnologia@sinvest.es Wed Dec 1 12:34:13 1999
From: Casillas_Juan_M/madrid_tecnologia@sinvest.es (Casillas_Juan_M/madrid_tecnologia@sinvest.es)
Date: Wed, 1 Dec 1999 13:34:13 +0100
Subject: [omniORB] Finding methods / part 3
Message-ID:
Hi everybody, =20
Duncan says:
>
>I don't think you mean "instantiate new objects...". I think you mean
>you want A to use an _object reference_ to an object which has a type
>that A does not know. In this case, there is no problem with creating
>he reference, and invoking operations on it with DII. You obviously
>can't use static invocation since you don't have compile-time
>knowledge of it.
>
Ok, that's fine.
>
>That said, I think you need to carefully re-think what it is you are
>trying to do. As someone pointed out earlier, knowing that a server
>supports an interface with an operation named hello() doesn't do you
>any good at all, since the name of an operation doesn't tell you
>anything about what it does. Not only that, but there is no guarantee
>that the arguments to different hello() operations are the
>same. Consider two interfaces:
>
That's fine too. But here I have another problem: I have to find the
interface (I don't known nothing about it) and then, I have to find
what methods they have, and their values ... sounds dificult ... =20
how can I do that usign omniORB only ?
>
>If a client of your proposed system asks for objects supporting
>hello(), and gets back references to instances of I and J, how can it
>possibly do anything useful? Especially since it doesn't have
>compile-time knowledge of J::myStruct.
>
Ok, You have all the reason. Test only the methods is danger. I
have to find the interfaces, and then test the methods. But I want
to do that in a distributed way ... Imagine the following scenario:
Program A wants to know what Laser Printers are out of paper;
There are programs monitoring the printers say, these monitors
check periodically the printer to see its status and send events
about it; and in the other side, these monitor have a CORBA interface=
so you can manage the printer from another program:
A program monitor has:
1) code to check the printer periodically
2) code to send events to the Eventchannel or something like
this (the Communication Adapter) so we can notify the
status to other programs
3) code to receive events that contain commands
4) a corba interface to allow another program manage the
printer, just like this program was the monitor
so Program A don't =20
manage the printers directly and A don't know nothing about the
monitoring programs; Program A and the monitors talks using a
event channel or something like this. So to do something useful,
A must check:
1) first all the printers
2) then for the printers available, all the laser printers
3) from this, printers that are out of paper.
There are 2 ways to do this
=20
1) Use the Naming service, register all the monitors on it,
and then use object references for all of them from the
program A, and use their interfaces to check the conditions
but this has two problems: 1) It requires lots of connections
to do this and 2) is very centralized, so if A crash, I have
problems.
2) The other way is to use a comunication media says an Event
channel, or something like this, so A can query to the rest =20
of programs (in this scenario, the monitors) for those that
are monitoring laser printers, that are out of paper. The =20
monitors that check the conditions (monitors monitoring
laser printers that are out of paper) send the answer to =20
program A; so A can use the Monitor CORBA interface to =20
manage this printers. This is way is distributed (each
monitor checks itself the conditions) and requires less
connections. I think my steps must follow this path
=20
Sorry by this long message :)
Btw, This project is called GAP
(http:://www.gsyc.inf.uc3m.es/~assman/gap)
I think it is a new approach to distributed administration.
Kind Regards
Juan Manuel Casillas
Santander Investment
(systems/technology)
From johannes@ees2.oulu.fi Wed Dec 1 10:26:38 1999
From: johannes@ees2.oulu.fi (Janne Haverinen)
Date: Wed, 01 Dec 1999 12:26:38 +0200
Subject: [omniORB] POA and port number for IIOP
requests.
Message-ID: <3844F7DE.B4FFF254@ee.oulu.fi>
Is there anything like -BOAiiop_port for POA in OmniORB3? If not, how to
work with POA and firewall?
// Janne Haverinen
From dgrisby@uk.research.att.com Thu Dec 2 11:04:56 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Thu, 02 Dec 1999 11:04:56 +0000
Subject: [omniORB] POA and port number for IIOP requests.
In-Reply-To: Your message of "Wed, 01 Dec 1999 12:26:38 +0200."
<3844F7DE.B4FFF254@ee.oulu.fi>
Message-ID: <199912021104.LAA10042@pineapple.cam-orl.co.uk>
On Wednesday 1 December, Janne Haverinen wrote:
> Is there anything like -BOAiiop_port for POA in OmniORB3? If not, how to
> work with POA and firewall?
Yes. Use -ORBpoa_iiop_port . You can find all the -ORB
possibilities on both omniORB 2.8 and omniORB 3 by doing -ORBhelp.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From baofyu@ns.dept3.buaa.edu.cn Thu Dec 2 12:21:19 1999
From: baofyu@ns.dept3.buaa.edu.cn (Yu Baofeng)
Date: Thu, 2 Dec 1999 20:21:19 +0800
Subject: [omniORB] Finding methods / part 3
Message-ID: <001601bf3cbf$bd1eddc0$5a0201df@yubaofeng>
Hi! Everyone
Why not use Jini?
Kind Regards say:
Ok, You have all the reason. Test only the methods is danger. I
have to find the interfaces, and then test the methods. But I want
to do that in a distributed way ... Imagine the following scenario:
Program A wants to know what Laser Printers are out of paper;
There are programs monitoring the printers say, these monitors
check periodically the printer to see its status and send events
about it; and in the other side, these monitor have a CORBA interface
so you can manage the printer from another program:
A program monitor has:
1) code to check the printer periodically
2) code to send events to the Eventchannel or something like
this (the Communication Adapter) so we can notify the
status to other programs
3) code to receive events that contain commands
4) a corba interface to allow another program manage the
printer, just like this program was the monitor
so Program A don't
manage the printers directly and A don't know nothing about the
monitoring programs; Program A and the monitors talks using a
event channel or something like this. So to do something useful,
A must check:
1) first all the printers
2) then for the printers available, all the laser printers
3) from this, printers that are out of paper.
There are 2 ways to do this
1) Use the Naming service, register all the monitors on it,
and then use object references for all of them from the
program A, and use their interfaces to check the conditions
but this has two problems: 1) It requires lots of connections
to do this and 2) is very centralized, so if A crash, I have
problems.
2) The other way is to use a comunication media says an Event
channel, or something like this, so A can query to the rest
of programs (in this scenario, the monitors) for those that
are monitoring laser printers, that are out of paper. The
monitors that check the conditions (monitors monitoring
laser printers that are out of paper) send the answer to
program A; so A can use the Monitor CORBA interface to
manage this printers. This is way is distributed (each
monitor checks itself the conditions) and requires less
connections. I think my steps must follow this path
Baofeng Yu
Advanced Simulation Technology Lab
email: baofyu@ns.dept3.buaa.edu.cn
From zoltan.sebestyen@netvisor.hu Thu Dec 2 14:58:34 1999
From: zoltan.sebestyen@netvisor.hu (zoltan.sebestyen@netvisor.hu)
Date: Thu, 2 Dec 1999 14:58:34 +0000
Subject: [omniORB] Date: Thu, 2 Dec 1999 16:04:51 +0100
Message-ID: <617185BB0AA2D111872400105AD899AD09123B@netvisorpdc.intranet.netvisor.hu>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01BF3CD6.992C98C0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Hi,
Did anyone succeed to compile omniORB 2.8.0 on DEC Alpha =
OSF-4.0/gcc-2.95?
I have modified the appropriate makefile (alpha-osf.4.0.mk) with using =
a SUN
makefile that contained gcc specificic parameters and compiled it, but =
can't
run the examples shipped with omniORB they dump core:
That error message follows:
Caught omniORB2 fatalException. This indicates a bug is caught within
omniORB2.
Please send a bug report.
The exception was thrown in file: giopClient.cc
line: 191
The error message is: GIOP_C::ReceiveReply() reported wrong request =
message
size.
Segmentation fault (core dumped) =20
Thanks
Zolt=E1n Sebesty=E9n, NETvisor Ltd., Hungary
<>=20
------_=_NextPart_000_01BF3CD6.992C98C0
Content-Type: application/octet-stream;
name="alpha_osf1_4.0.mk"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="alpha_osf1_4.0.mk"
#=0A=
# alpha_osf1_4.0.mk - make variables and rules specific to Digital =
Unix=0A=
# (i.e. OSF1) 4.0.=0A=
#=0A=
=0A=
OSF1 =3D 1=0A=
AlphaProcessor =3D 1=0A=
=0A=
=0A=
#=0A=
# Include general unix things=0A=
#=0A=
=0A=
include $(THIS_IMPORT_TREE)/mk/unix.mk=0A=
=0A=
=0A=
#=0A=
# C preprocessor macro definitions for this architecture=0A=
#=0A=
=0A=
IMPORT_CPPFLAGS +=3D -D__alpha__ -D__osf1__ -D__OSVERSION__=3D4=0A=
=0A=
=0A=
#=0A=
# Standard programs=0A=
#=0A=
=0A=
AR =3D ar clq=0A=
=0A=
# gcc related..=0A=
CPP =3D gcc=0A=
=0A=
CXX =3D g++=0A=
CXXMAKEDEPEND =3D $(TOP)/$(BINDIR)/omkdepend -D__cplusplus -D__GNUG__ =
-D__GNUC__=0A=
CXXDEBUGFLAGS =3D =0A=
CXXOPTIONS =3D -fexceptions -Wall -Wno-unused=0A=
CXXMTFLAG =3D=0A=
=0A=
CXXLINK =3D $(CXX)=0A=
CXXLINKOPTIONS =3D $(CXXDEBUGFLAGS) $(CXXOPTIONS)=0A=
=0A=
COPTIONS =3D -fpcc-struct-return=0A=
=0A=
=0A=
#CXX =3D /usr/bin/cxx=0A=
# For DEC C++ 6.0=0A=
#CXXOPTIONS =3D -ptr $(TOP)/cxx_respository=0A=
#=0A=
DecCxxMajorVersion =3D 6=0A=
DecCxxMinorVersion =3D 0=0A=
#=0A=
# For DEC C++ 6.0=0A=
# Uncommment the following line to speed up the compilation, but may =
require=0A=
# manually deleted some .pch and cxx_respository/TIMESTAMP files to =
pick=0A=
# up changes in templates or the order of -I flags.=0A=
#=0A=
# CXXOPTIONS +=3D -ttimestamp -pch=0A=
=0A=
#CXXMAKEDEPEND =3D $(TOP)/$(BINDIR)/omkdepend -D__DECCXX =
-D__cplusplus=0A=
#CXXDEBUGFLAGS =3D -O=0A=
=0A=
#CXXLINK =3D $(CXX)=0A=
#CXXLINKOPTIONS =3D $(CXXDEBUGFLAGS) $(CXXOPTIONS) -call_shared=0A=
=0A=
CC =3D gcc=0A=
CMAKEDEPEND =3D $(TOP)/$(BINDIR)/omkdepend -D__GNUC__=0A=
#CDEBUGFLAGS =3D -O=0A=
=0A=
CLINK =3D $(CC)=0A=
=0A=
=0A=
#=0A=
# When specifying the "rpath" (directories which the run-time linker =
should=0A=
# search for shared libraries) we unfortunately need to do it in a =
single=0A=
# argument. For this reason we override the default unix CXXExecutable =
and=0A=
# CExecutable rules. Any -L flags given in $$libs results in another =
element=0A=
# being added to the rpath and we then give the whole rpath at the end =
of the=0A=
# link command line.=0A=
#=0A=
=0A=
RPATH =3D $(subst $(space),:,$(strip $(IMPORT_LIBRARY_DIRS)))=0A=
=0A=
define CXXExecutable=0A=
(rpath=3D"$(RPATH)"; \=0A=
for arg in $$libs; do \=0A=
if expr "$$arg" : "-L" >/dev/null; then \=0A=
rpath=3D"$$rpath$${rpath+:}`expr $$arg : '-L\(.*\)'"; \=0A=
fi; \=0A=
done; \=0A=
set -x; \=0A=
$(RM) $@; \=0A=
$(CXXLINK) -o $@ $(CXXLINKOPTIONS) $(IMPORT_LIBRARY_FLAGS) \=0A=
$(filter-out $(LibSuffixPattern),$^) $$libs -rpath $$rpath; \=0A=
)=0A=
endef=0A=
=0A=
define CExecutable=0A=
(rpath=3D"$(RPATH)"; \=0A=
for arg in $$libs; do \=0A=
if expr "$$arg" : "-L" >/dev/null; then \=0A=
rpath=3D"$$rpath$${rpath+:}`expr $$arg : '-L\(.*\)'"; \=0A=
fi; \=0A=
done; \=0A=
set -x; \=0A=
$(RM) $@; \=0A=
$(CLINK) -o $@ $(CLINKOPTIONS) $(IMPORT_LIBRARY_FLAGS) \=0A=
$(filter-out $(LibSuffixPattern),$^) $$libs -rpath $$rpath; \=0A=
)=0A=
endef=0A=
=0A=
=0A=
#=0A=
# CORBA stuff=0A=
#=0A=
=0A=
omniORB2GatekeeperImplementation =3D OMNIORB2_TCPWRAPGK=0A=
CorbaImplementation =3D OMNIORB2=0A=
=0A=
#=0A=
# OMNI thread stuff=0A=
#=0A=
=0A=
ThreadSystem =3D Posix=0A=
=0A=
OMNITHREAD_POSIX_CPPFLAGS =3D -DPthreadDraftVersion=3D10 =
-DNoNanoSleep=0A=
OMNITHREAD_CPPFLAGS =3D -D_REENTRANT -pthread=0A=
=0A=
# The pthread package before 4.0 was POSIX 1003.4a draft 4. If for =
some=0A=
# reason it is necessary to run the same binaries on 4.0 and older =
systems=0A=
# (e.g. 3.2), use the following make variables instead.=0A=
#=0A=
# OMNITHREAD_POSIX_CPPFLAGS =3D -DPthreadDraftVersion=3D4 -DNoNanoSleep =
=0A=
# OMNITHREAD_CPPFLAGS =3D -D_PTHREAD_USE_D4 -D_REENTRANT=0A=
=0A=
OMNITHREAD_LIB =3D $(patsubst %,$(LibSearchPattern),omnithread) \=0A=
-lpthread -lexc=0A=
=0A=
lib_depend :=3D $(patsubst %,$(LibPattern),omnithread)=0A=
OMNITHREAD_LIB_DEPEND :=3D $(GENERATE_LIB_DEPEND)=0A=
=0A=
# Default location of the omniORB2 configuration file [falls back to =
this if=0A=
# the environment variable OMNIORB_CONFIG is not set] :=0A=
=0A=
OMNIORB_CONFIG_DEFAULT_LOCATION =3D /etc/omniORB.cfg=0A=
=0A=
# Default directory for the omniNames log files.=0A=
OMNINAMES_LOG_DEFAULT_LOCATION =3D /var/omninames=0A=
------_=_NextPart_000_01BF3CD6.992C98C0--
From seefelds@MAGELLAN.UMontreal.CA Thu Dec 2 15:18:45 1999
From: seefelds@MAGELLAN.UMontreal.CA (Stefan Seefeld)
Date: Thu, 02 Dec 1999 15:18:45 +0000
Subject: [omniORB] Finding methods / part 3
References:
Message-ID: <38468DD5.C0144D47@magellan.umontreal.ca>
Casillas_Juan_M/madrid_tecnologia@sinvest.es wrote:
> to do that in a distributed way ... Imagine the following scenario:
>
> Program A wants to know what Laser Printers are out of paper;
> There are programs monitoring the printers say, these monitors
> check periodically the printer to see its status and send events
> about it; and in the other side, these monitor have a CORBA interface
> so you can manage the printer from another program:
>
> A program monitor has:
> 1) code to check the printer periodically
> 2) code to send events to the Eventchannel or something like
> this (the Communication Adapter) so we can notify the
> status to other programs
> 3) code to receive events that contain commands
> 4) a corba interface to allow another program manage the
> printer, just like this program was the monitor
>
> so Program A don't
> manage the printers directly and A don't know nothing about the
> monitoring programs; Program A and the monitors talks using a
> event channel or something like this. So to do something useful,
> A must check:
>
> 1) first all the printers
> 2) then for the printers available, all the laser printers
> 3) from this, printers that are out of paper.
>
> There are 2 ways to do this
>
> 1) Use the Naming service, register all the monitors on it,
> and then use object references for all of them from the
> program A, and use their interfaces to check the conditions
> but this has two problems: 1) It requires lots of connections
> to do this and 2) is very centralized, so if A crash, I have
> problems.
>
> 2) The other way is to use a comunication media says an Event
> channel, or something like this, so A can query to the rest
> of programs (in this scenario, the monitors) for those that
> are monitoring laser printers, that are out of paper. The
> monitors that check the conditions (monitors monitoring
> laser printers that are out of paper) send the answer to
> program A; so A can use the Monitor CORBA interface to
> manage this printers. This is way is distributed (each
> monitor checks itself the conditions) and requires less
> connections. I think my steps must follow this path
I think trading service is really what you want. You can export
a service ("monitor a laser printer" together with an attached interface).
Then your program can query for services given a list of attributes. Then
it selects and imports the service it prefers, using the returned interface.
Of course, those interfaces have to be known by both, the provider (exporter)
and the user (importer). But that's ok, you have to know *something* anyway
in your client to be able to invoke a service's interface...
Stefan
PS: you need to decide what is an attribute of the interface (for example
laser, ink jet etc.) and what is an attribute of the object (out of paper).
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
From djr@uk.research.att.com Thu Dec 2 17:59:43 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Thu, 2 Dec 1999 17:59:43 +0000 (GMT)
Subject: [omniORB] Overlapping servant lifetimes with ServantActivator
(omniORB3)
In-Reply-To:
Message-ID:
Hi Wil,
Darn -- you've caught me ;-) I realised that this was not 100% compliant
when I implemented it, but went ahead because there are significant
performance and/or complexity implications in getting it right. I think I
can get it right efficiently, but it will be quite difficult. This is the
one place I knew I was not quite right, and I really thought no-one would
notice, doh!
What is happening is that the object has been removed from the Active
Object Map, and then is passed to another thread to be etherealised (when
all outstanding invocations have completed). In the mean time another
thread comes along and incarnates an object with the same id. What should
happen is that this incarnation should block until the origional object
has finished etherealising (see 11.3.8.17).
I can probably do this by putting some sort of placeholder into the active
object map which is only removed when etherealisation is complete. Quite
a bit of work though, so I suggest that you work under the assumption that
it won't get fixed for a while.
Cheers,
David
On Tue, 30 Nov 1999 Wil_Evers@doosys.com wrote:
> Trying last Friday's snapshot of the omniORB3 pre-release, I ran into some
> unexpected behaviour.
>
> Using a ServantActivator, I implemented a variant of the evictor pattern as
> described in Henning & Vinoski's book. The basic idea is to limit the
> number of active servants in a POA to a certain maximum; if that maximum is
> reached, then for every newly incarnated servant, the oldest previously
> incarnated servant is deactivated. To see what would happen under stress,
> I limited the maximum number of active servants to 1. This way, the only
> living servant (if any) is deactivated as soon as a request for another
> object id arrives at the POA.
>
> omniORB3 does not immediately etherialize a servant that has just been
> deactivated by a call to deactivate_object() on the associated POA. That in
> itself, I believe, is OK, and may even be necessary. However, in the
> scenario above, incarnate() was called with an object ID I had just
> deactivated, but for which the ORB had not yet invoked etherialize(). The
> effect is that for a short period of time, the same object id is being
> incarnated by two separate servants, causing a race condition in the
> interaction with the underlying persistent store. I *think* this is
> illegal for a POA with a ServantActivator - section 11.3.5 of the CORBA 2.3
> spec says:
>
> Incarnations of a particular object may not overlap; that is,
> incarnate shall not be invoked with a particular ObjectId while,
> within the same POA, that ObjectId is in use as the ObjectId
> of an activated object or as the argument of a call to incarnate
> or etherealize that has not completed.
>
> The policies I set for this POA are PERSISTENT, USER_ID,
> USE_SERVANT_MANAGER and RETAIN.
>
> Did I miss something?
From djr@uk.research.att.com Thu Dec 2 18:15:04 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Thu, 2 Dec 1999 18:15:04 +0000 (GMT)
Subject: [omniORB] Re: OmniNames
In-Reply-To: <862DA3FEB3BBD211933800A0C9CDFE7A8C6046@ntsrvr01.acdca.itt.com>
Message-ID:
Hi,
I've had a look at this, and yes there is a problem. In theory it should
have all worked as it used to. It does work in the case where you put
NAMESERVER IOR:... into the config file, but not when you use
ORBInitialHost and ORBInitialPort. Looks like I've done something to
damage the bootstrap agent.
I'll look into it.
Cheers,
David
On Tue, 30 Nov 1999, Kapla, Jami wrote:
> Hello David,
> We are trying to use the Omniidl3 on linux 6.0
> and test the echo example. The eg1 works however the eg3_impl
> fails when the call to orb->resolve_initial_references("NameServece")
> is called. We are trying to find what exception is being thrown. However
> I believe it has something to do with either the ORB is configured wrong
> or the omniORB.cfg file is not configured correctly. There is a mention
> in the 3.0 release notes of changes to the log file for omniNames but no
> specifics. currently we start the omniNames:
>
> omniNames -start 1234
> which then seems to start it ok.
>
> omniORB.cfg has:
> ORBInitialHost korea (my machine)
> ORBInitialPort 1234
>
> and OMNIORB_CONFIG is set in the environment to the correct path.
>
> However we are using the documentation for OmniOrb2, so maybe this has
> changed some(?).
> We simply did a make all and ran eg3.impl but the resolve_initial_refernces
> call fails. (it also fails for all ID's except "RootPOA").
From rbritten@icon.co.za Fri Dec 3 06:15:24 1999
From: rbritten@icon.co.za (Randall Britten)
Date: Fri, 03 Dec 1999 01:15:24 -0500
Subject: [omniORB] omniNames and libstdc++.so.2.9 on RedHat 6.0
Message-ID: <38475FFB.CA23444@icon.co.za>
I downloaded the following binary distribution from
www.uk.research.att.com:
omniORB_280_x86_linux_2.0_glibc.tar.gz, hoping to run it on my RedHat
6.0
Linux box.
In order to run omniNames, I followed the first two steps in README.unix
under
part 4 of "Configuration". However, it seems that libstdc++.so.2.9 is
required, and I do not know how to obtain it. (Found and Rpm ...2.9,
but it contained the 2.8 .so). I tried a hack: symbollically
linking the name libstdc++.so.2.9 to libstdc++.so.2.8, but that doesn't
seem
to really work.
Perhaps someone could help me out here. Thanks in advance.
I have pasted some "command line stuff" below:
$ uname -a
Linux hostname 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586 unknown
$ env | grep omni
LD_LIBRARY_PATH=/home/randall/omniORB_280/lib/i586_linux_2.0_glibc/
OMNINAMES_LOGDIR=/home/randall/omniORB_280/logs
$ bin/i586_linux_2.0_glibc/omniNames -start 12345 &
$ bin/i586_linux_2.0_glibc/omniNames: error in loading shared libraries:
libstdc++.so.2.9: cannot open shared object file: No such
file or directory
$ su
# cd /usr/lib
# ln -s ./libstdc++.so.2.8 libstdc++.so.2.9
# exit
$
bin/i586_linux_2.0_glibc/omniORB_280/bin/i586_linux_2.0_glibc/omniNames
-start 12345
`
Fri Dec 3 01:01:31 1999:
Starting omniNames for the first time.
./omniORB_280/bin/i586_linux_2.0_glibc/omniNames: error in loading
shared libraries:
./omniORB_280/bin/i586_linux_2.0_glibc/omniNames: undefined symbol:
__eh_alloc
--
--------------
Randall Britten
rbritten@icon.co.za
From seefelds@MAGELLAN.UMontreal.CA Fri Dec 3 02:18:40 1999
From: seefelds@MAGELLAN.UMontreal.CA (Stefan Seefeld)
Date: Thu, 02 Dec 1999 21:18:40 -0500
Subject: [omniORB] omniNames and libstdc++.so.2.9 on RedHat 6.0
References: <38475FFB.CA23444@icon.co.za>
Message-ID: <38472880.11DF6798@magellan.umontreal.ca>
Randall Britten wrote:
> In order to run omniNames, I followed the first two steps in README.unix
> under
> part 4 of "Configuration". However, it seems that libstdc++.so.2.9 is
> required, and I do not know how to obtain it. (Found and Rpm ...2.9,
> but it contained the 2.8 .so). I tried a hack: symbollically
> linking the name libstdc++.so.2.9 to libstdc++.so.2.8, but that doesn't
> seem
> to really work.
either you recompile omniorb or you get a newer compiler (which ships with
the newer library)
Stefan
From rbritten@icon.co.za Fri Dec 3 14:18:29 1999
From: rbritten@icon.co.za (Randall Britten)
Date: Fri, 03 Dec 1999 09:18:29 -0500
Subject: [omniORB] omniNames and libstdc++.so.2.9 on RedHat 6.0
References: <38475FFB.CA23444@icon.co.za> <384736DC.5CE9@accesscom.com>
Message-ID: <3847D135.48C239C0@icon.co.za>
I did a recompile from scratch, and now omniNames works. Did you have other
problems on RedHat 6.0 ?
Fred Cook wrote:
> Randall Britten wrote:
> >
> > I downloaded the following binary distribution from
> > www.uk.research.att.com:
> > omniORB_280_x86_linux_2.0_glibc.tar.gz, hoping to run it on my RedHat
> > 6.0
> > Linux box.
> >
> > In order to run omniNames, I followed the first two steps in README.unix
> > under
> > part 4 of "Configuration". However, it seems that libstdc++.so.2.9 is
> > required, and I do not know how to obtain it. (Found and Rpm ...2.9,
> > but it contained the 2.8 .so). I tried a hack: symbollically
> > linking the name libstdc++.so.2.9 to libstdc++.so.2.8, but that doesn't
> > seem
> > to really work.
> >
> > Perhaps someone could help me out here. Thanks in advance.
> >
> > I have pasted some "command line stuff" below:
> >
> > $ uname -a
> > Linux hostname 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586 unknown
> >
> > $ env | grep omni
> > LD_LIBRARY_PATH=/home/randall/omniORB_280/lib/i586_linux_2.0_glibc/
> > OMNINAMES_LOGDIR=/home/randall/omniORB_280/logs
> >
> > $ bin/i586_linux_2.0_glibc/omniNames -start 12345 &
> > $ bin/i586_linux_2.0_glibc/omniNames: error in loading shared libraries:
> > libstdc++.so.2.9: cannot open shared object file: No such
> > file or directory
> >
> > $ su
> > # cd /usr/lib
> > # ln -s ./libstdc++.so.2.8 libstdc++.so.2.9
> > # exit
> >
> > $
> > bin/i586_linux_2.0_glibc/omniORB_280/bin/i586_linux_2.0_glibc/omniNames
> > -start 12345
> > `
> > Fri Dec 3 01:01:31 1999:
> >
> > Starting omniNames for the first time.
> > ./omniORB_280/bin/i586_linux_2.0_glibc/omniNames: error in loading
> > shared libraries:
> > ./omniORB_280/bin/i586_linux_2.0_glibc/omniNames: undefined symbol:
> > __eh_alloc
> >
> > --
> > --------------
> > Randall Britten
> > rbritten@icon.co.za
>
> Randall,
>
> I fought this battle for three weeks and got no where. The solution to
> this problem is to upgrade to RH 6.1. You will have to recomple
> omniORB_280, but that should not be a problem, just follow the given
> instructions. A standard workstation installation of RH 6.1 and a
> recompiled omniORB_280 does work. Trying to get omniORB_280 on RH 6.0
> working is not worth your time (it only costs $30), and it may not be
> possible.
>
> Have fun!
> Fred
--
--------------
Randall Britten
rbritten@icon.co.za
P.O.Box 2584, Parklands, Johannesburg, South Africa, 2121
From renzo.tomaselli@tecnotp.it Fri Dec 3 08:55:31 1999
From: renzo.tomaselli@tecnotp.it (Renzo Tomaselli)
Date: Fri, 3 Dec 1999 09:55:31 +0100
Subject: [omniORB] Implementation repository
Message-ID: <008d01bf3d6c$2f725e90$a8c649c1@big>
This is a multi-part message in MIME format.
------=_NextPart_000_008A_01BF3D74.88DE8B90
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all,
assume one would implement an Implem. Repository over Omniorb =
2.8 such the one described in Henning & Vinoski book. The loading on =
demand feature of Omniorb looks great for this, so that one could use =
indirect binding for all persistent objects.
But the hard point is about forcing an implementation BOA to include a =
pair into generated IOR profiles while listening on a =
possibly *different* port. The option -BOAiiop_name_port is described in =
such a way making me to believe the used port concerns both the port to =
listen on *and* the port to include into a profile.
This would mean that IR and all implementations must use the same port - =
a hard constraint to follow; really impossible when multiple processes =
are listening at the same host. On the other hand the host name setting =
should be ok with this option.
A closely connected issue concerns non-persistent object: in this case =
an implementation would like to use direct binding only, e.g. to include =
local host and port into a IOR profile, without involving the IR. AFAIK, =
Omniorb BOA setup cannot be differentiated to yield different profiles =
for different objects.
Alternatively multiple -BOAiiop_port lead to include multiple profiles =
in a IOR, which in principle should be an even optimized way to handle =
this issue, according to Vinosky; the IOR would include both direct and =
indirect binding profiles.
But for some reasons this approach is not safe or not liked (I remember =
some comments on this list stating as an ORB might forget about any =
extra profile after the very first one, I don't know about Omniorb =
behavior here).
Any comment ? Thanks,
Renzo Tomaselli =20
-------------------------------------------------------------------------=
--
TecnoTP s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY
Tel. +39 0461 773164 Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.it =20
-------------------------------------------------------------------------=
--
------=_NextPart_000_008A_01BF3D74.88DE8B90
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all,
assume one =
would=20
implement an Implem. Repository over Omniorb 2.8 such the one described =
in=20
Henning & Vinoski book. The loading on demand feature of Omniorb =
looks great=20
for this, so that one could use indirect binding for all persistent=20
objects.
But the hard point is about forcing an =
implementation BOA to=20
include a <host,port> pair into generated IOR profiles while =
listening on=20
a possibly *different* port. The option -BOAiiop_name_port is =
described in=20
such a way making me to believe the used port concerns both the port to =
listen=20
on *and* the port to include into a profile.
This would mean that IR and all implementations must =
use the=20
same port - a hard constraint to follow; really impossible when multiple =
processes are listening at the same host. On the other hand the host =
name=20
setting should be ok with this option.
A closely connected issue concerns non-persistent =
object: in=20
this case an implementation would like to use direct binding only, e.g. =
to=20
include local host and port into a IOR profile, without involving the =
IR. AFAIK,=20
Omniorb BOA setup cannot be differentiated to yield different profiles =
for=20
different objects.
Alternatively multiple -BOAiiop_port lead to include =
multiple=20
profiles in a IOR, which in principle should be an even optimized way to =
handle=20
this issue, according to Vinosky; the IOR would include both direct and =
indirect=20
binding profiles.
But for some reasons this approach is not safe or =
not liked (I=20
remember some comments on this list stating as an ORB might forget about =
any=20
extra profile after the very first one, I don't know about Omniorb =
behavior=20
here).
Any comment ? Thanks,
&nbs=
p; =
; =
=20
Renzo Tomaselli =20
---------------------------------------------------------------------=
------
TecnoTP=20
s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi=20
Valsugana, Trento TN ITALY
Tel. +39 0461=20
773164 Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.it=
=20
---------------------------------------------------------------------=
------
------=_NextPart_000_008A_01BF3D74.88DE8B90--
From johannes@ees2.oulu.fi Fri Dec 3 09:04:40 1999
From: johannes@ees2.oulu.fi (Janne Haverinen)
Date: Fri, 03 Dec 1999 11:04:40 +0200
Subject: [omniORB] Problems while compiling OmniORB for SunOS
Message-ID: <384787A8.F9B1DAF2@ee.oulu.fi>
Hi,
I tried to compile OmniORB3 for Sun Solaris and I got following error:
CC -c -O2 -g -I. -I../include -I. -I../../../../include -D__sparc__
-D__sunos__ -D__OSVERSION__=5 -o o2be_root.o o2be_root.cc
"o2be_root.cc", line 562: Error: Cannot use const char* to initialize
char*.
1 Error(s) detected.
Our system is:
(tk39)(johannes)(104)(src) uname -a
SunOS tk39 5.7 Generic_106541-07 sun4u sparc SUNW,Ultra-5_10
And compilers:
CC - Sun WorkShop C++ Compiler 5.0
gcc, g++ - GNU project C and C++ Compiler (gcc-2.95)
Will I get OmniORB work in our system?
Regards,
Janne Haverinen
From Haarek.Ryeng@datarespons.no Fri Dec 3 09:09:17 1999
From: Haarek.Ryeng@datarespons.no (Haarek Ryeng)
Date: Fri, 03 Dec 1999 10:09:17 +0100
Subject: [omniORB] How to init a tie pointer safely
Message-ID: <384788BD.1D28FFB7@datarespons.no>
This is a multi-part message in MIME format.
--------------A6E96E1332FEF58FD1A5C57D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
What is the preferred way to initialise a pointer to a
tie-class?
And how do I maintain this pointer safely?
Ex:
Tie-class: _tie_A
Impl-class: A_i
class A_i
{
// some defs......
_tie_A< A_i*,false >* _p;
};
A_i::A_i()
{
_p = NULL // Alright?
}
A_i::InterfaceFactory()
{
if ( CORBA::is_nil(_p->-this()) ) // Is this the safe way
to check
//for a valid interface
through the tie pointer?
{
try
{
_p = new _tie_A(this);
boa->obj_is_ready(_p);
}
catch( bad_alloc)
{
_p = ? // What do I initialise it to so that the
above “is_nil”
//check is safe?
}
}// end if
}// end factory function
Any comments?
Regards,
Haarek Ryeng
--------------A6E96E1332FEF58FD1A5C57D
Content-Type: text/x-vcard; charset=us-ascii;
name="haarek.ryeng.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Hårek Ryeng
Content-Disposition: attachment;
filename="haarek.ryeng.vcf"
begin:vcard
adr;dom:;;;N-1322 HØVIK;;;
n:Ryeng;Hårek
x-mozilla-html:FALSE
org:Data Respons AS
version:2.1
email;internet:haarek.ryeng@datarespons.no
title:M.sci (computers & signal processing)
tel;fax:67112050
tel;home:90196734
tel;work:67112071
x-mozilla-cpt:;0
fn:Hårek Ryeng
end:vcard
--------------A6E96E1332FEF58FD1A5C57D--
From Haarek.Ryeng@datarespons.no Fri Dec 3 09:32:52 1999
From: Haarek.Ryeng@datarespons.no (Haarek Ryeng)
Date: Fri, 03 Dec 1999 10:32:52 +0100
Subject: [omniORB] How to init a tie pointer safely
References: <384788BD.1D28FFB7@datarespons.no>
Message-ID: <38478E44.783ACF92@datarespons.no>
This is a multi-part message in MIME format.
--------------4925C9C1E5DF74B3BB951E9A
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
The CORBA::is_nil(_p->_this()) will obviously throw an
exception when _p == NULL, and the way I do the check today is
by "if (_p == NULL)".
Is there a better way to do this?
- Haarek Ryeng
PS! I'll try to send only one mail next time.. (to little
coffee- yet :-) )
Haarek Ryeng wrote:
> What is the preferred way to initialise a pointer to a
> tie-class?
> And how do I maintain this pointer safely?
>
> Ex:
> Tie-class: _tie_A
> Impl-class: A_i
>
> class A_i
> {
> // some defs......
> _tie_A< A_i*,false >* _p;
> };
>
> A_i::A_i()
> {
> _p = NULL // Alright?
> }
>
> A_i::InterfaceFactory()
> {
> if ( CORBA::is_nil(_p->-this()) ) // Is this the safe way
> to check
> //for a valid interface
> through the tie pointer?
> {
> try
> {
> _p = new _tie_A(this);
> boa->obj_is_ready(_p);
> }
> catch( bad_alloc)
> {
> _p = ? // What do I initialise it to so that the
> above “is_nil”
> //check is safe?
> }
> }// end if
> }// end factory function
>
> Any comments?
>
> Regards,
>
> Haarek Ryeng
--------------4925C9C1E5DF74B3BB951E9A
Content-Type: text/x-vcard; charset=us-ascii;
name="haarek.ryeng.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Hårek Ryeng
Content-Disposition: attachment;
filename="haarek.ryeng.vcf"
begin:vcard
adr;dom:;;;N-1322 HØVIK;;;
n:Ryeng;Hårek
x-mozilla-html:FALSE
org:Data Respons AS
version:2.1
email;internet:haarek.ryeng@datarespons.no
title:M.sci (computers & signal processing)
tel;fax:67112050
tel;home:90196734
tel;work:67112071
x-mozilla-cpt:;0
fn:Hårek Ryeng
end:vcard
--------------4925C9C1E5DF74B3BB951E9A--
From rbritten@icon.co.za Fri Dec 3 15:10:20 1999
From: rbritten@icon.co.za (Randall Britten)
Date: Fri, 03 Dec 1999 10:10:20 -0500
Subject: [omniORB] Which cpp on RedHat 6.0?
Message-ID: <3847DD5B.CBDC8B44@icon.co.za>
On RedHat 6.0, I have managed to compile omniORB, and the Name Service
and the echo examples work. I am still not sure though, if I chose the
correct cpp in ./mk/platforms/i586_linux_2.0_glibc.mk
I couldn't find a cpp executable anywhere, so a wild guess was that g++
itself would do the c pre processing, hence I used:
CPP = /usr/bin/g++
More info
Linux dist: RedHat 6.0
omniORB Platform: i586_linux_2.0_glibc
Compiler version:
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Thanks
--
--------------
Randall Britten
rbritten@icon.co.za
From djr@uk.research.att.com Fri Dec 3 09:42:18 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Fri, 3 Dec 1999 09:42:18 +0000 (GMT)
Subject: [omniORB] Which cpp on RedHat 6.0?
In-Reply-To: <3847DD5B.CBDC8B44@icon.co.za>
Message-ID:
Hi,
Redhat 6.1 has cpp in /lib/cpp -- this is a sym-link to EGCS installation.
I expect 6.0 is the same.
David
On Fri, 3 Dec 1999, Randall Britten wrote:
> On RedHat 6.0, I have managed to compile omniORB, and the Name Service
> and the echo examples work. I am still not sure though, if I chose the
> correct cpp in ./mk/platforms/i586_linux_2.0_glibc.mk
From edumas@tumbleweed.com Fri Dec 3 09:46:04 1999
From: edumas@tumbleweed.com (Eric Dumas)
Date: Fri, 3 Dec 1999 01:46:04 -0800
Subject: [omniORB] Which cpp on RedHat 6.0?
In-Reply-To: <3847DD5B.CBDC8B44@icon.co.za>; from Randall Britten on Fri, Dec 03, 1999 at 10:10:20AM -0500
References: <3847DD5B.CBDC8B44@icon.co.za>
Message-ID: <19991203014603.A27952@cliff.tumbleweed.com>
According to Randall Britten:
> On RedHat 6.0, I have managed to compile omniORB, and the Name Service
> and the echo examples work. I am still not sure though, if I chose the
> correct cpp in ./mk/platforms/i586_linux_2.0_glibc.mk
you can use g++ -E or /lib/cpp (this is a symbolic link to your real
cpp - for example /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/cpp).
> I couldn't find a cpp executable anywhere, so a wild guess was that g++
> itself would do the c pre processing, hence I used:
> CPP = /usr/bin/g++
Use -E
--
Éric Dumas (dumas@tumbleweed.com)
Tumbleweed Communications, 700 Saginaw Drive, Redwood City, CA 94063, USA
http://www.tumbleweed.com Tel: +1 650-216-2030
From jfpoilpret@hn.vnn.vn Fri Dec 3 10:24:24 1999
From: jfpoilpret@hn.vnn.vn (Poilpret Jean Francois)
Date: Fri, 3 Dec 1999 17:24:24 +0700
Subject: [omniORB] Miscellaneous problems with omniEvents 2.0
Message-ID: <000301bf3d78$ab2ac520$0100a8c0@windev>
Hi omniORBers,
At this time, I am in the process of chosing an Event Service (for a =
little project with omniORB for my students). I'm just "playing" with =
omniEvents 2.0, but I ran into some problems (some of which I could not =
solve).
But first of all, I have to tell that I want to use omniEvents with Java =
clients (written with ORBACUS 3.2), so I have to recompile IDL files =
included with the omniEvents package, with the jidl ORBACUS compiler.
The problems I ran into are:
1. The file CosEventChannelAdmin.idl is not compliant with the =
"official" OMG IDL file, since it includes "CosLifeCycle.idl". Moreover, =
it seems that nothing from CosLifeCycle.idl is used inside =
CosEventChannelAdmin.idl. So I cleared the including line from the file. =
After this, no problem.
2. I wanted to write a PushSupplier (in Java) sending events to an =
omniEvents event channel.
So I got the object reference of the channel, then the SupplierAdmin =
object reference, then a ProxyPushConsumer reference object from the =
SuplierAdmin.
Then I call the connect_push_supplier() operation on that reference.The =
problem is that I pass a nil object reference for the push_supplier =
argument. And then, I receive the BAD_PARAM exception.
I read the code in CosEvent_i.cc (in omniEvents package) and discovered =
that passing a nil object reference was forbidden.
But according to the OMG specs, (CORBAservices, march 1995, Event =
Service 1.0, pages 4-17 and 4-18), it is allowed for a push-supplier to =
pass a nil object reference for this argument.
(In fact, I think the problem is the same with a pull-consumer who wants =
to register itself with a proxypullsupplier, but I didnot check it with =
omniEvents).
For me, this is a problem since if you want to act as a push-supplier, =
you still have to write an implementation for the PushSupplier interface =
and make your java application (or applet) a server. But I don't want to =
write a CORBA server in java, just a simple client. But I can't do :-(
It would be great if omniEvents could be made compliant with the specs =
here, because I think many people would like to use Event Channels this =
way, writing simple CORBA clients when it is possible.
I alse have a suggestion for the next releases of omniEvents: I think it =
would be great to provide both static and dynamic libraries, since the =
size of executables is quite big ;-)
Besides this, congratulations for omniEvents, the examples seem to work =
great !
Thank you in advance
Regards
Jean-Fran=E7ois
From Christian_Lipp@allianz.at Fri Dec 3 11:45:55 1999
From: Christian_Lipp@allianz.at (Christian_Lipp@allianz.at)
Date: Fri, 3 Dec 1999 12:45:55 +0100
Subject: [omniORB] Winsock
Message-ID: <4125683C.0045F2E4.00@smtp_01.allianz.at>
We are using omniOrb 2.8 under Win95 (laptop) and WinNT (PC).
On the laptops, we use it for client/server apps, but also for IPC.
When the network connection isn't available (so we just want to use IPC)
every start of a CORBA-Server fails.
So we tried to upgrade winsock.dll to V2, now the server is able to start.
Unfortunately, we have to install 1400 clients and we could't manage
to make the winsock-upgrade unintented (for automatical installation
whitout user interaction).
So my question: does omniORB only run with winsock 2 on windows
platforms or is there a way to start a server without network connection
and an older winsock?
Thanks in advance, greetings
CL
From seefelds@MAGELLAN.UMontreal.CA Fri Dec 3 13:51:33 1999
From: seefelds@MAGELLAN.UMontreal.CA (Stefan Seefeld)
Date: Fri, 03 Dec 1999 13:51:33 +0000
Subject: [omniORB] Which cpp on RedHat 6.0?
References: <3847DD5B.CBDC8B44@icon.co.za>
Message-ID: <3847CAE5.683EF510@magellan.umontreal.ca>
Randall Britten wrote:
>
> On RedHat 6.0, I have managed to compile omniORB, and the Name Service
> and the echo examples work. I am still not sure though, if I chose the
> correct cpp in ./mk/platforms/i586_linux_2.0_glibc.mk
I think it is an error for those *.mk files to refer to the tools by
absolute paths. They should simply refer to "c++", "cpp" etc. so that
it's the user's choice to set his PATH variable so that those tools can
be found.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
From djr@uk.research.att.com Fri Dec 3 17:03:35 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Fri, 3 Dec 1999 17:03:35 +0000 (GMT)
Subject: [omniORB] Bug in omniORB 2.8 and 3.0
In-Reply-To: <19991202184123.A1835@cuivre.fr.eu.org>
Message-ID:
Hi,
There is a bug in the marshalling code for multi-dimensional arrays of
simple types for omniORB 2.8 and 3.0. Credit to Thomas Quinot for
spotting this one. If you use multi-dimensional arrays of simple types
you should definately get the update from CVS, or a patch from
http://www.uk.research.att.com/omniORB/omniORBbug.html
Cheers,
David
From tsulaia@usa.net Fri Dec 3 18:41:55 1999
From: tsulaia@usa.net (Vakhtang Tsulaia)
Date: 3 Dec 99 11:41:55 MST
Subject: [omniORB] Problems with omniEvents
Message-ID: <19991203184156.5047.qmail@nwcst286.netaddress.usa.net>
Hello,
I have just started to try omniEvents on the Win98 platform (MSVC++ 6.0).=
Following the instructions in 'Readme', I tryed to build source files
with the use of GNU make. (Command: make export).
As a result, I got lots of errors while compiling 'omniEvents.cc',
but anyway three .lib files ('omniEventsStubs.lib', 'omniEventsFe.lib',
'omniEventsUtil.lib') were installed into the
appropriate folder.
Afterwards I tryed to link those .lib files to my VC++ project (I linked
all of them) and added just single line of code:
=2E..
EventChannelFactory_i *factory =3D new EventChannelFactory_i();
=2E..
Result:
error LNK2001: unresolved external symbol "public: __thiscall
EventChannelFactory_i::EventChannelFactory_i(void)"
(??0EventChannelFactory_i@@QAE@XZ)
What I did wrong?
I would be very grateful, if someone could help me to solve my problems.
Thanks in advance.
V.Tsulaia
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=3D=
1
From renny@visualsoft.com Fri Dec 3 18:48:24 1999
From: renny@visualsoft.com (Renny Koshy)
Date: Fri, 3 Dec 1999 13:48:24 -0500
Subject: [omniORB] Problems with omniEvents
Message-ID:
More than likely MSVC++ uses a different mangling scheme than GCC...
:-)
Don't you love it?!
-Renny
> -----Original Message-----
> From: Vakhtang Tsulaia [mailto:tsulaia@usa.net]
> Sent: Friday, December 03, 1999 1:42 PM
> To: omniorb-list@uk.research.att.com
> Subject: [omniORB] Problems with omniEvents
>
>
> Hello,
>
> I have just started to try omniEvents on the Win98 platform
> (MSVC++ 6.0).
> Following the instructions in 'Readme', I tryed to build source files
> with the use of GNU make. (Command: make export).
> As a result, I got lots of errors while compiling 'omniEvents.cc',
> but anyway three .lib files ('omniEventsStubs.lib',
> 'omniEventsFe.lib',
> 'omniEventsUtil.lib') were installed into the
> appropriate folder.
>
> Afterwards I tryed to link those .lib files to my VC++
> project (I linked
> all of them) and added just single line of code:
>
> ...
> EventChannelFactory_i *factory = new EventChannelFactory_i();
> ...
>
> Result:
>
> error LNK2001: unresolved external symbol "public: __thiscall
> EventChannelFactory_i::EventChannelFactory_i(void)"
> (??0EventChannelFactory_i@@QAE@XZ)
>
> What I did wrong?
> I would be very grateful, if someone could help me to solve
> my problems.
>
> Thanks in advance.
> V.Tsulaia
>
> ____________________________________________________________________
> Get free email and a permanent address at
> http://www.netaddress.com/?N=1
>
From rceci@master.adams.com Fri Dec 3 20:02:34 1999
From: rceci@master.adams.com (Rob Cecil)
Date: Fri, 03 Dec 1999 15:02:34 -0500
Subject: [omniORB] destructor not called on _dispose()
Message-ID: <384821DA.F4CBD0BA@adams.com>
--------------72F9CB7CF86F1A8B15DFEF42
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can anyone think of a reason the dtor of a Corba server implementation would
not be called, when _dispose()'d?
Thanks
--
| Rob Cecil | Senior Development Engineer |
| rceci@adams.com | Product Development |
| (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
--------------------------------------------------------------------
Modern Quantum Physics has found that the universe is composed of
25% protons, 15% electrons, 15% neutrons, and 45% morons.
--------------72F9CB7CF86F1A8B15DFEF42
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Can anyone think of a reason the dtor of a Corba server implementation
would not be called, when _dispose()'d?
Thanks
--
| Rob Cecil | Senior Development Engineer |
| rceci@adams.com | Product Development |
| (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
--------------------------------------------------------------------
Modern Quantum Physics has found that the universe is composed of
25% protons, 15% electrons, 15% neutrons, and 45% morons.
--------------72F9CB7CF86F1A8B15DFEF42--
From rshoup@tumbleweed.com Fri Dec 3 20:52:38 1999
From: rshoup@tumbleweed.com (Randy Shoup)
Date: Fri, 03 Dec 1999 12:52:38 -0800
Subject: [omniORB] destructor not called on _dispose()
References: <384821DA.F4CBD0BA@adams.com>
Message-ID: <38482D96.8820F5ED@tumbleweed.com>
Most likely the reference count of the object is off -- the servant has
probably been _duplicate()'d or _this()'d or _narrow()'d one too many
times.
_dispose() does not destruct the servant unless and until all the
servant's references are released. This is to prevent a servant from
being destructed while a call is in-flight on it.
-- Randy
Tumbleweed Communications
Rob Cecil wrote:
>
> Can anyone think of a reason the dtor of a Corba server implementation
> would not be called, when _dispose()'d?
>
> Thanks
>
> --
> | Rob Cecil | Senior Development Engineer |
> | rceci@adams.com | Product Development |
> | (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
> --------------------------------------------------------------------
> Modern Quantum Physics has found that the universe is composed of
> 25% protons, 15% electrons, 15% neutrons, and 45% morons.
>
>
From rdasilva@connecttel.com Sun Dec 5 02:29:46 1999
From: rdasilva@connecttel.com (Rosimildo DaSilva)
Date: Sat, 4 Dec 1999 20:29:46 -0600
Subject: [omniORB] omniORB for RTEMS -- update
Message-ID: <02c501bf3ec8$9910ce60$0200a8c0@rps1.rr.com>
Droping this note to let all of you know that I have updated the
porting of omniORB to RTEMS.
More info here:
http://www.connecttel.com/corba/rtems_omni.html
Support for 2.8.0 and 3.0 has been added.
Requirements:
+ gcc 2.95.1
+ omniORB-19991204 snapshot ( 2.8.0 version )
+ rtems-19991117 snapshot
+ omniORB3-19991204 snapshot ( 3.0 version ).
+ rtems-19991117 snapshot
A release of RTEMS is due any time now. A new update will be done
whenever RTEMS gets released.
Regards, Rosimildo.
+---------------------------------------------------------------------
| ConnectTel, Inc. - Austin, Texas.
| Phone : 512-338-1111 - Fax : 512-918-0449
| Email : devl@connecttel.com or mkting@connecttel.com
| Site : http://www.connecttel.com
+---------------------------------------------------------------------
From dgrisby@uk.research.att.com Mon Dec 6 10:41:36 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 06 Dec 1999 10:41:36 +0000
Subject: [omniORB] Finding methods / part 3
In-Reply-To: Your message of "Wed, 01 Dec 1999 13:34:13 +0100."
Message-ID: <199912061041.KAA00956@pineapple.cam-orl.co.uk>
On Wednesday 1 December, Casillas_Juan_M/madrid_tecnologia@sinvest.es wrote:
[...]
> That's fine too. But here I have another problem: I have to find the
> interface (I don't known nothing about it) and then, I have to find
> what methods they have, and their values ... sounds dificult ... =20
> how can I do that usign omniORB only ?
You can't do it with things distributed in omniORB, without
implementing the interface querying functionality yourself.
[...description of finding laser printers out of paper...]
There is nothing in your description which requires that clients
dynamically find the interfaces of objects. You just need to design
your interfaces properly, with sensible use of inheritance. Trying to
dynamically query and invoke on unknown interfaces will turn
everything into a big unmanageble mess.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Mon Dec 6 10:55:37 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 06 Dec 1999 10:55:37 +0000
Subject: [omniORB] omniNames and libstdc++.so.2.9 on RedHat 6.0
In-Reply-To: Your message of "Fri, 03 Dec 1999 01:15:24 EST."
<38475FFB.CA23444@icon.co.za>
Message-ID: <199912061055.KAA01044@pineapple.cam-orl.co.uk>
On Friday 3 December, Randall Britten wrote:
> I downloaded the following binary distribution from
> www.uk.research.att.com: omniORB_280_x86_linux_2.0_glibc.tar.gz,
> hoping to run it on my RedHat 6.0 Linux box.
Redhat 6 uses glibc 2.1. omniORB is compiled against glibc 2.0, so the
binary libraries won't work. You should download the source and
compile it.
You should compile omniORB with the latest version of gcc, which is
2.95.2. When you build gcc, make sure you use the --enable-threads
option to configure. Despite the documentation's claim that it only
affects Objective-C, it does make a difference.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Mon Dec 6 11:00:15 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 06 Dec 1999 11:00:15 +0000
Subject: [omniORB] A question about ORB thread model
In-Reply-To: Your message of "Wed, 17 Jun 1998 19:59:36 +0800."
<3587AFA8.B4D24722@263.net>
Message-ID: <199912061100.LAA01097@pineapple.cam-orl.co.uk>
On Wednesday 17 June, biguo wrote:
> Hello,folks! I have a question about ORB thread model.In CORBA
> model,there is a thread scheduling in handling client request and a
> client request correspond to a server thread . I think,it should be a
> user level thread.According to my understanding, for each client
> connection,only a thread are automatically allocated on the server to a
> client connection.A ORB implementation only can generate one OS(such as
> Unix or Windows ) task.Is it right?Thanks.
I don't quite understand the question, but omniORB's threading model
is described in
http://www.uk.research.att.com/omniORB/archives/1997-06/0048.html
and
http://www.uk.research.att.com/omniORB/doc/omniORB2/node8.html
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From tei@elca.ch Mon Dec 6 11:16:23 1999
From: tei@elca.ch (Eicher Thomas)
Date: Mon, 6 Dec 1999 12:16:23 +0100
Subject: [omniORB] Solution for problems compiling projects using MSDevStudio 6
Message-ID: <000a01bf3fdb$58494dd0$1c9248c1@elca.ch>
Hallo
Several people have indicated problems with compiling an omniOrb project
using MS Visual Studio 6. Usually, the linker would find unresolved exter=
nal
dependencies like
CORBA::Any::~Any()
or others, even though the instructions in README.win32 had been followed
closely.
The problem comes from the README.win32 file, which tells to include
- omniORB280_rt(d).lib and
- omnithread2_rt(d).lib,
but not
- omniDynamic280_rtd.lib.
This library has to be included as well (see the dir.mak files for
examples).
Just include the libraries in Project/Settings/Link/Input, and it should
work.
-- Tom
______________________________________________
Tom Eicher ELCA Informatik AG
tei@elca.ch Steinstrasse 21
+41 (0)1 456 32 47 8003 Z=FCrich
http://www.elca.ch Switzerland
From Wil_Evers@doosys.com Mon Dec 6 11:37:41 1999
From: Wil_Evers@doosys.com (Wil_Evers@doosys.com)
Date: Mon, 6 Dec 1999 12:37:41 +0100
Subject: [omniORB] omniNames and libstdc++.so.2.9 on RedHat 6.0
Message-ID:
Hi,
Duncan Grisby wrote:
> You should compile omniORB with the latest version of gcc,
> which is 2.95.2.
Does that mean there is no official support for the compiler that comes
standard with RedHat 6.0, which is a costimized version of egcs-1.1.2?
If so, I'd expect problems when linking with commercial third-party
libraries for which the sources are not available. Most likely, these
libraries will target the compiler that's
included in the official RedHat distribution.
- Wil
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
From dgrisby@uk.research.att.com Mon Dec 6 11:45:14 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 06 Dec 1999 11:45:14 +0000
Subject: [omniORB] omniNames and libstdc++.so.2.9 on RedHat 6.0
In-Reply-To: Your message of "Mon, 06 Dec 1999 12:37:41 +0100."
Message-ID: <199912061145.LAA03424@pineapple.cam-orl.co.uk>
On Monday 6 December, Wil_Evers@doosys.com wrote:
> > You should compile omniORB with the latest version of gcc,
> > which is 2.95.2.
>
> Does that mean there is no official support for the compiler that comes
> standard with RedHat 6.0, which is a costimized version of egcs-1.1.2?
omniORB works fine with egcs, provided the compiler is configured with
--enable-threads. I don't know whether the one which comes with RH6.0
is or not. If you use a compiler which is configured incorrectly, you
see occasional random crashes due to incorrect exception handling.
> If so, I'd expect problems when linking with commercial third-party
> libraries for which the sources are not available. Most likely,
> these libraries will target the compiler that's included in the
> official RedHat distribution.
If RedHat's compiler is configured incorrectly, I imagine that any
library problems would be overcome by building your own version of
egcs-1.1.2 which was correctly configured.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From biguo@263.net Tue Dec 7 05:57:39 1999
From: biguo@263.net (biguo@263.net)
Date: Tue, 7 Dec 1999 13:57:39 +0800 (CST)
Subject: [omniORB] A question about omniorb thread model
Message-ID: <384CA1D3.18536@mta2>
Hello,folks! I have a question about ORB thread model.In CORBA
model,there is a thread scheduling in handling client request and a
client request correspond to a server thread . I think,it should be a
user level thread.According to my understanding, for each client
connection,only a thread are automatically allocated on the server to a client connection.A ORB implementation only can generate one OS(such as Unix or Windows ) task.Is it right?Thanks.
_____________________________________________
Ê׶¼ÔÚÏß--ÏȽøÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net
Ãâ·ÑÓÊÏä ÓʼþÔÓÖ¾ Ç©ÃûÓʼþ Óʼþ¼ÓÃÜ Óʼþ×·Éíºô
ËÑË÷ÒýÇæ ¸öÈËÕ¾µã ÔÚÏßÓÎÏ· ÍøÉÏÁÄÌì ÍøÉϹҺÅ
½ðÈÚÍõ¹ú ÔÚÏßɱ¶¾ ÌøÔéÊг¡ Èí¼þÏÂÔØ ÐÝÏÐÓéÀÖ
ŵ·½°²È«£¬ÖúÄúe·ƽ°²
From tei@elca.ch Tue Dec 7 08:23:34 1999
From: tei@elca.ch (Eicher Thomas)
Date: Tue, 7 Dec 1999 09:23:34 +0100
Subject: [omniORB] RE: [omniorb] solution for problems compiling projects using msdevstudio 6
In-Reply-To: <966B307EF37DD311A3B1002048400F1B87C8FF@uspto-is-104.uspto.gov>
Message-ID: <000201bf408c$5b9edc00$1c9248c1@elca.ch>
Hi --
I just tried to build the examples once, which did not work, although I a=
m
not quite sure whether this was due to the lack of omniDynamic280 or rath=
er
some other missing setting in MS Dev. But my own application did compile
smoothly as soon as I linked in the additional library, after having had
those unresolved external symbol errors.
I have never tried to do much stuff with omniNames, since I am working on
the client side, and all I have to do is connect to the naming service. I
started with that only after compiling my application. It works.
I hope that helps.
-- Tom
______________________________________________
Tom Eicher ELCA Informatik AG
tei@elca.ch Steinstrasse 21
+41 (0)1 456 32 47 8003 Z=FCrich
http://www.elca.ch Switzerland
> -----Original Message-----
> From: Chung, David [mailto:David.Chung@USPTO.GOV]
> Sent: Montag, 6. Dezember 1999 20:55
> To: 'tei@elca.ch'
> Cc: 'omniorb-list@uk.research.att.com'
> Subject: re: [omniorb] solution for problems compiling projects using
> msdevstudio 6
>
>
> Just out of curiosity, were you able to build the
> examples 1 and 2
> without omniDynamic280_rtd.lib?
> What about omniNames?
>
> Thanks in advance.
>
From David.Chung@USPTO.GOV Mon Dec 6 19:54:58 1999
From: David.Chung@USPTO.GOV (Chung, David)
Date: Mon, 6 Dec 1999 14:54:58 -0500
Subject: [omniORB] re: [omniorb] solution for problems compiling projects using msde
vstudio 6
Message-ID: <966B307EF37DD311A3B1002048400F1B87C8FF@uspto-is-104.uspto.gov>
Just out of curiosity, were you able to build the examples 1 and 2
without omniDynamic280_rtd.lib?
What about omniNames?
Thanks in advance.
From randall@is.co.za Tue Dec 7 12:23:22 1999
From: randall@is.co.za (Randall Britten)
Date: Tue, 7 Dec 1999 14:23:22 +0200
Subject: [omniORB] Which cpp on RedHat 6.0?
Message-ID:
How does one test that the chosen cpp is being used correctly? Is the =
cpp
specified in the .mk file only for the once off compiling of omniORB, =
or is
it also used by omniidl2 when compiling .idl files? If so, how does =
one
test it?
-----Original Message-----
From: Eric Dumas
To: Randall Britten
Cc: omniORB
Date: 03 December 1999 11:48
Subject: Re: [omniORB] Which cpp on RedHat 6.0?
>According to Randall Britten:
>> On RedHat 6.0, I have managed to compile omniORB, and the Name =
Service
>> and the echo examples work. I am still not sure though, if I chose =
the
>> correct cpp in ./mk/platforms/i586_linux_2.0_glibc.mk
>
>you can use g++ -E or /lib/cpp (this is a symbolic link to your real
>cpp - for example =
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/cpp).
>
>> I couldn't find a cpp executable anywhere, so a wild guess was that =
g++
>> itself would do the c pre processing, hence I used:
>> CPP =3D /usr/bin/g++
>
> Use -E
>
>--=20
> =C9ric Dumas (dumas@tumbleweed.com)
> Tumbleweed Communications, 700 Saginaw Drive, Redwood City, CA =
94063,
USA
> http://www.tumbleweed.com Tel: +1 650-216-2030
>
>
From tei@elca.ch Tue Dec 7 13:05:30 1999
From: tei@elca.ch (Eicher Thomas)
Date: Tue, 7 Dec 1999 14:05:30 +0100
Subject: [omniORB] RE: [omniorb] solution for problems compiling projects using msdevstudio 6
In-Reply-To: <966B307EF37DD311A3B1002048400F1B87C909@uspto-is-104.uspto.gov>
Message-ID: <000401bf40b3$bee1dca0$1c9248c1@elca.ch>
I am using MSVC++(SP3) and NT4 (SP4);
I have not read about the independence of the omniDynamic and omniORB
libraries; since I am using my server's idl file, I don't know exactly wh=
at
interfaces (e.g. class Any) are implicitely used in there.
The problem was, that I was able to compile everything (since e.g.
Any::~Any() shows up in corba.h), but not to link -> obviously, corba.h
refers to some functions defined in omniDynamic.
What I did notice, is that the provided makefiles for the examples (dir.m=
ak
and similar) for nmake do include omniDynamic as well. That's why those
nmake-makefiles work, but not the projects genereated in MSVC. -> Why not
link them in, it works.
Since I read, that many others had had similar problem with MSVC, I thoug=
ht
that this was the solution, but maybe there is some deeper problem to it?
Let me know, if you find out more.
-- tom
______________________________________________
Tom Eicher ELCA Informatik AG
tei@elca.ch Steinstrasse 21
+41 (0)1 456 32 47 8003 Z=FCrich
http://www.elca.ch Switzerland
> -----Original Message-----
> From: Chung, David [mailto:David.Chung@USPTO.GOV]
> Sent: Dienstag, 7. Dezember 1999 13:42
> To: 'tei@elca.ch'
> Cc: 'omniorb-list@uk.research.att.com'
> Subject: RE: [omniorb] solution for problems compiling projects using
> msdevstudio 6
>
>
> MSVC++(SP2), NT4 (SP4)
>
> According to earlier emails in omniorb-list (by omniorb
> developers)
> omniDynamic280_rtd.dll and omniorb280_rtd.dll are supposed to be
> independent, at least if you are not using interfaces from
> omniDynamic280_rtd.dll
>
> Nonetheless, I had similar problems you described;
> except that my
> problems were on omniORB3.0. With different
> permutations/combination of
> kludges, I was able to coerce examples 1 and 2 to work as
> described in the
> documentation (with and without omniDynamic300_rtd.dll). I
> was unable to
> get dynamic examples to work -- they would crash immediately.
>
>
> > -----Original Message-----
> > From: tei@elca.ch [SMTP:tei@elca.ch]
> > Sent: Tuesday, December 07, 1999 3:22 AM
> > To: David.Chung@USPTO.GOV
> > Subject: RE: [omniorb] solution for problems compiling
> projects using
> > msdevstudio 6
> >
> > Hi --
> >
> > I just tried to build the examples once, which did not
> work, although I am
> > not quite sure whether this was due to the lack of omniDynamic280 or
> > rather
> > some other missing setting in MS Dev. But my own
> application did compile
> > smoothly as soon as I linked in the additional library,
> after having had
> > those unresolved external symbol errors.
> >
> > I have never tried to do much stuff with omniNames, since I
> am working on
> > the client side, and all I have to do is connect to the
> naming service. I
> > started with that only after compiling my application. It works.
> >
> > I hope that helps.
> >
> > -- Tom
> > ______________________________________________
> > Tom Eicher ELCA Informatik AG
> > tei@elca.ch Steinstrasse 21
> > +41 (0)1 456 32 47 8003 Z=FCrich
> > http://www.elca.ch Switzerland
> >
> > > -----Original Message-----
> > > From: Chung, David [mailto:David.Chung@USPTO.GOV]
> > > Sent: Montag, 6. Dezember 1999 20:55
> > > To: 'tei@elca.ch'
> > > Cc: 'omniorb-list@uk.research.att.com'
> > > Subject: re: [omniorb] solution for problems compiling
> projects using
> > > msdevstudio 6
> > >
> > >
> > > Just out of curiosity, were you able to build the
> > > examples 1 and 2
> > > without omniDynamic280_rtd.lib?
> > > What about omniNames?
> > >
> > > Thanks in advance.
> > >
>
From David.Chung@USPTO.GOV Tue Dec 7 12:42:25 1999
From: David.Chung@USPTO.GOV (Chung, David)
Date: Tue, 7 Dec 1999 07:42:25 -0500
Subject: [omniORB] RE: [omniorb] solution for problems compiling projects using msde
vstudio 6
Message-ID: <966B307EF37DD311A3B1002048400F1B87C909@uspto-is-104.uspto.gov>
MSVC++(SP2), NT4 (SP4)
According to earlier emails in omniorb-list (by omniorb developers)
omniDynamic280_rtd.dll and omniorb280_rtd.dll are supposed to be
independent, at least if you are not using interfaces from
omniDynamic280_rtd.dll
Nonetheless, I had similar problems you described; except that my
problems were on omniORB3.0. With different permutations/combination =
of
kludges, I was able to coerce examples 1 and 2 to work as described in =
the
documentation (with and without omniDynamic300_rtd.dll). I was unable =
to
get dynamic examples to work -- they would crash immediately.=20
> -----Original Message-----
> From: tei@elca.ch [SMTP:tei@elca.ch]
> Sent: Tuesday, December 07, 1999 3:22 AM
> To: David.Chung@USPTO.GOV
> Subject: RE: [omniorb] solution for problems compiling projects using
> msdevstudio 6
>=20
> Hi --
>=20
> I just tried to build the examples once, which did not work, although =
I am
> not quite sure whether this was due to the lack of omniDynamic280 or
> rather
> some other missing setting in MS Dev. But my own application did =
compile
> smoothly as soon as I linked in the additional library, after having =
had
> those unresolved external symbol errors.
>=20
> I have never tried to do much stuff with omniNames, since I am =
working on
> the client side, and all I have to do is connect to the naming =
service. I
> started with that only after compiling my application. It works.
>=20
> I hope that helps.
>=20
> -- Tom
> ______________________________________________
> Tom Eicher ELCA Informatik AG
> tei@elca.ch Steinstrasse 21
> +41 (0)1 456 32 47 8003 Z=FCrich
> http://www.elca.ch Switzerland
>=20
> > -----Original Message-----
> > From: Chung, David [mailto:David.Chung@USPTO.GOV]
> > Sent: Montag, 6. Dezember 1999 20:55
> > To: 'tei@elca.ch'
> > Cc: 'omniorb-list@uk.research.att.com'
> > Subject: re: [omniorb] solution for problems compiling projects =
using
> > msdevstudio 6
> >
> >
> > Just out of curiosity, were you able to build the
> > examples 1 and 2
> > without omniDynamic280_rtd.lib?
> > What about omniNames?
> >
> > Thanks in advance.
> >
From djr@uk.research.att.com Tue Dec 7 14:52:54 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Tue, 7 Dec 1999 14:52:54 +0000 (GMT)
Subject: [omniORB] solution for problems compiling projects using
msdevstudio 6
In-Reply-To: <000401bf40b3$bee1dca0$1c9248c1@elca.ch>
Message-ID:
Hi,
The situation is that applications that don't use TypeCode, Any, DynAny
etc should be able to link only with omniORB280_rt(d).dll. It turns out
that MSVC does a poor job of analysing dependancies, and so references
code in omniDynamic280_rt(d).dll, even though it is not reachable. This
is a problem with MSVC -- all other platforms/compilers we have tested do
not have this problem.
So this means that pretty much all applications have to be linked against
both the omniORB and omniDynamic libraries. When using dynamically linked
libraries this oughtn't be too much of an overhead, just a pain.
If anyone can tell me specifically how to prevent MSVC from generating
these unnecassary references, and if it is very little work to implement,
and it has no performance penalty for other platforms, *then* I might be
able to solve this problem.
Until then...if you really need to avoid linking with omniDynamic (say if
you are using static libraries) then you could hack the headers to remove
all the dynamic types. More hassle than its worth if you ask me.
Cheers,
David
From astitcher@orchestream.com Tue Dec 7 16:30:25 1999
From: astitcher@orchestream.com (Andrew Stitcher)
Date: Tue, 07 Dec 1999 16:30:25 +0000
Subject: [omniORB] solution for problems compiling projects using
msdevstudio 6
In-Reply-To: Message from David Riddoch
of "Tue, 07 Dec 1999 14:52:54 GMT."
Message-ID: <199912071630.QAA14220@annexia.orchestream.com>
[This info is a bit hazy in my head, but I think the guts are right]
By default when using the Microsoft compilation tool chain here is
what happens:
If you specify an import library in the link line (even if you don't
use any of the symbols from the corresponding dll) the executable
that is generated is marked as using the dll. For normal (debugging)
builds I don't think you can avoid this, if you don't want a dll
don't include the import library.
If you specify the "Minimize Size" optimisation, this enables
function level linking. This causes the linker to notice which
functions are being used or not and not to link in the ones that
aren't. As a side effect the linker will notice if any of the
specified dlls aren't actually being used, print a warning message
and take it out of the executable.
Incidently, the "Minimise size" optimisation is recomended for
release builds over the speed optimising setting.
Andrew
From djr@uk.research.att.com Tue Dec 7 18:54:21 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Tue, 7 Dec 1999 18:54:21 +0000 (GMT)
Subject: [omniORB] omniidl2 bug
Message-ID:
Hi,
Another bug in omniidl2. The following IDL gives it a headache:
interface foo {
typedef sequence seq;
};
See http://www.uk.research.att.com/omniORB/omniORBbug.html
Cheers,
David
From mark.borges@attws.com Tue Dec 7 22:58:14 1999
From: mark.borges@attws.com (Borges, Mark)
Date: Tue, 7 Dec 1999 14:58:14 -0800
Subject: [omniORB] omniidl bug?
Message-ID:
[ My apologies if this is posted to the list twice; my first attempt didn't
appear to go through, perhaps because I posted from a different account than
what I am subscribed on? ]
The following IDL snippet,
--------------------
$ cat cdt.idl
//___________________COMMON DATA TYPES _____________________
#ifndef COMMON_DATA_TYPES
#define COMMON_DATA_TYPES
typedef string<2> StringTwo;
#endif
--------------------
gives the error,
--------------------
$ /opt/omniORB/scripts/omniidl -I. -bpython cdt.idl
cdt.idl:6: Integer literal is too large for unsigned long
omniidl: 1 error.
--------------------
Why? Neither omniidl2 nor python-stubber from the XEROX-PARC ILU-2.0beta1
distribution complain.
The code in question appears to be in idlexpr.cc, around line 145,
--------------------
$ sed -n "145,151{p;}" idlexpr.cc
_CORBA_ULong IntegerExpr::evalAsULong() {
#ifdef HAS_LongLong
if (value_ > 0xffffffff) {
IdlError(file(), line(), "Integer literal is too large for unsigned
long");
return 1;
}
#endif
--------------------
If it matters, I'm using,
--------------------
$ gcc -dumpversion
2.95.2
$ gcc -dumpmachine
sparc-sun-solaris2.6
$ uname -a
SunOS jimi 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-5_10
$ cvs status idlexpr.cc
===================================================================
File: idlexpr.cc Status: Up-to-date
Working revision: 1.3
Repository revision: 1.3 /cvsroot/omniidl/cxx/idlexpr.cc,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
--------------------
--
-mb-
From dgrisby@uk.research.att.com Wed Dec 8 09:59:49 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 08 Dec 1999 09:59:49 +0000
Subject: [omniORB] omniidl bug?
In-Reply-To: Your message of "Tue, 07 Dec 1999 14:58:14 PST."
Message-ID: <199912080959.JAA03833@pineapple.cam-orl.co.uk>
On Tuesday 7 December, "Borges, Mark" wrote:
> $ /opt/omniORB/scripts/omniidl -I. -bpython cdt.idl
> cdt.idl:6: Integer literal is too large for unsigned long
> omniidl: 1 error.
> --------------------
>
> Why? Neither omniidl2 nor python-stubber from the XEROX-PARC ILU-2.0beta1
> distribution complain.
[...]
> if (value_ > 0xffffffff) {
[...]
> $ gcc -dumpversion
> 2.95.2
> $ gcc -dumpmachine
> sparc-sun-solaris2.6
I assume the problem is that on Sparc, the 0xffffffff is being
sign-extended to be -1. It's not obvious from the C++ spec what the
behaviour should be. Can you try the following enormous patch to see
if the problem goes away?
--- idlexpr.cc 1999/11/02 17:07:26 1.3
+++ idlexpr.cc 1999/12/08 09:55:13
@@ -144,7 +144,7 @@
}
_CORBA_ULong IntegerExpr::evalAsULong() {
#ifdef HAS_LongLong
- if (value_ > 0xffffffff) {
+ if (value_ > 0xffffffffU) {
IdlError(file(), line(), "Integer literal is too large for unsigned long");
return 1;
}
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From Andrew.Weaver@tecnomen.fi Wed Dec 8 12:30:02 1999
From: Andrew.Weaver@tecnomen.fi (Andrew Weaver)
Date: Wed, 8 Dec 1999 14:30:02 +0200
Subject: [omniORB] "Permanent Connections with Omni..."
Message-ID: <99Dec8.152716gmt+0200.115587@sister.tecnomen.fi>
Moi, I am fairly new to the CORBA world although I have extensive experience
in the design and implementation of distributed systems in a heterogeneous
hardware environment and have previously developed various network-based
"services" that have similarities with, for instance, the Naming Service.
Whilst I can see the role of the ORB as an rpc mechanism, I am looking to
see if I can leverage some of the CORBA aspects to achieve more of a
"transfer" function.
So far, I can imagine that I could use the naming service to locate my
"provider". Thereafter, I want to establish connection and request something
similar to a download. The circuit must remain open until I decide that I am
finished with it because the "download" may well consist of more than one
block of transfer.
Anybody done this or similar using OMNI?
Kind Regards
Andy Weaver
From dgrisby@uk.research.att.com Wed Dec 8 14:43:41 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 08 Dec 1999 14:43:41 +0000
Subject: [omniORB] "Permanent Connections with Omni..."
In-Reply-To: Your message of "Wed, 08 Dec 1999 14:30:02 +0200."
<99Dec8.152716gmt+0200.115587@sister.tecnomen.fi>
Message-ID: <199912081443.OAA04434@pineapple.cam-orl.co.uk>
On Wednesday 8 December, Andrew Weaver wrote:
> So far, I can imagine that I could use the naming service to locate my
> "provider". Thereafter, I want to establish connection and request something
> similar to a download. The circuit must remain open until I decide that I am
> finished with it because the "download" may well consist of more than one
> block of transfer.
I'm not certain what you want to do, but there are two possible ways
you can use omniORB to do block transfers. The first is to stay
completely within the bounds of CORBA, and define an interface like
interface Provider {
exception NoMoreData {};
typedef sequence data;
data getNextBlock() raises (NoMoreData);
};
Alternatively, you could do it the other way around, where the
provider pushes data to an object on the consumer. In this situation,
omniORB opens a TCP connection when you do the first invocation, then
caches it. Future invocations use the same connection, unless you
leave it idle for too long.
The second solution is to use CORBA to mediate access through another
transport, like plain TCP:
interface Provider {
void openConnection(string host, unsigned short port);
};
Does that answer your question?
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From mark.borges@attws.com Wed Dec 8 19:21:45 1999
From: mark.borges@attws.com (Borges, Mark)
Date: Wed, 8 Dec 1999 11:21:45 -0800
Subject: [omniORB] omniidl bug?
Message-ID:
Duncan,
I applied the enormous patch, but sadly it had no effect.
Is there any other diagnostic information I can provide to help find a
solution? Is there a mini test program I can compile and run here that would
help (sorry, I'm new to C++ so I can't help much -- the omniORB python
binding is what lured me here in the first place :-).
Mark
> -----Original Message-----
> From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
> Sent: Wednesday, December 08, 1999 2:00 AM
> To: Borges, Mark
> Cc: 'omniorb-list@uk.research.att.com'
> Subject: Re: [omniORB] omniidl bug?
>
>
> On Tuesday 7 December, "Borges, Mark" wrote:
>
> > $ /opt/omniORB/scripts/omniidl -I. -bpython cdt.idl
> > cdt.idl:6: Integer literal is too large for unsigned long
> > omniidl: 1 error.
> > --------------------
> >
> > Why? Neither omniidl2 nor python-stubber from the
> XEROX-PARC ILU-2.0beta1
> > distribution complain.
>
> [...]
>
> > if (value_ > 0xffffffff) {
>
> [...]
>
> > $ gcc -dumpversion
> > 2.95.2
> > $ gcc -dumpmachine
> > sparc-sun-solaris2.6
>
> I assume the problem is that on Sparc, the 0xffffffff is being
> sign-extended to be -1. It's not obvious from the C++ spec what the
> behaviour should be. Can you try the following enormous patch to see
> if the problem goes away?
>
>
> --- idlexpr.cc 1999/11/02 17:07:26 1.3
> +++ idlexpr.cc 1999/12/08 09:55:13
> @@ -144,7 +144,7 @@
> }
> _CORBA_ULong IntegerExpr::evalAsULong() {
> #ifdef HAS_LongLong
> - if (value_ > 0xffffffff) {
> + if (value_ > 0xffffffffU) {
> IdlError(file(), line(), "Integer literal is too large
> for unsigned long");
> return 1;
> }
>
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --
>
From Dejan.Polomcic@telecom.co.nz Wed Dec 8 22:17:27 1999
From: Dejan.Polomcic@telecom.co.nz (Dejan Polomcic)
Date: Thu, 09 Dec 1999 11:17:27 +1300
Subject: [omniORB] omniEvents problem - getting a core dump
Message-ID:
hi,
I have come across the following Error while using paul nader's event =
service, could anyone tell me what causes the error:
The following stmts show gdb of the core :
[nasex]/home/nasex/menu > gdb ../bin/eventd core
Wildebeest is free software and you are welcome to distribute copies of
it under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for Wildebeest; type "show warranty"
for details.
Hewlett-Packard Wildebeest 1.0 (based on GDB 4.16)
(built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00)
Copyright 1996, 1997 Free Software Foundation, Inc...(no debugging symbols =
found)...
Core was generated by `eventd'.
Program terminated with signal 6, Aborted.
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.
(no debugging symbols found)...(no debugging symbols found)...(no =
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...#0 0xc01e8498 in kill () from /usr/lib/libc=
.2
#0 0xc01e8498 in kill () from /usr/lib/libc.2
(gdb) bt
#0 0xc01e8498 in kill () from /usr/lib/libc.2
#1 0xc01826c4 in raise () from /usr/lib/libc.2
#2 0xc01591f0 in abort () from /usr/lib/libc.2
#3 0xc0159880 in _assert () from /usr/lib/libc.2
#4 0xd507c928 in Strand::decrRefCount () from //home/nasex/lib/libomniORB2=
.sl.8
#5 0xd508cc7c in tcpSocketRendezvouser::run_undetached () from //home/nase=
x/lib/libomniORB2.sl.8
#6 0xc02fea20 in omni_thread_wrapper () from //home/nasex/lib/libomnithrea=
d.sl.2
#7 0xc0ff9c4c in __pthread_create_system () from /usr/lib/libpthread.1
cheers
dejan
From biguo@263.net Thu Dec 9 02:45:04 1999
From: biguo@263.net (biguo@263.net)
Date: Thu, 9 Dec 1999 10:45:04 +0800 (CST)
Subject: [omniORB] Another question about CORBA thread model in embedded system
Message-ID: <384F17B0.29494@mta4>
Hello,folks!I still have a question.In CORBA model,there is a thread scheduler in BOA of server side.These threads is scheduled by ORB and they're invisible to underlying OS.So,I say these threads are user level threads.Is it right?In embedded CORBA,ORB thread is the task of RTOS.These thread/task is visible to ORB and RTOS.Are they scheduled by ORB or RTOS?How to implement it?Anyone can help me?Thanks.
_____________________________________________
Ê׶¼ÔÚÏß--ÏȽøÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net
Ãâ·ÑÓÊÏä ÓʼþÔÓÖ¾ Ç©ÃûÓʼþ Óʼþ¼ÓÃÜ Óʼþ×·Éíºô
ËÑË÷ÒýÇæ ¸öÈËÕ¾µã ÔÚÏßÓÎÏ· ÍøÉÏÁÄÌì ÍøÉϹҺÅ
½ðÈÚÍõ¹ú ÔÚÏßɱ¶¾ ÌøÔéÊг¡ Èí¼þÏÂÔØ ÐÝÏÐÓéÀÖ
ŵ·½°²È«£¬ÖúÄúe·ƽ°²
From biguo@263.net Thu Dec 9 02:46:54 1999
From: biguo@263.net (biguo@263.net)
Date: Thu, 9 Dec 1999 10:46:54 +0800 (CST)
Subject: [omniORB] The relation between minimumCORBA and IIOP engine
Message-ID: <384F181E.12090@mta2>
Hello,folks!In some embedded system,ORB is implemented in form os IIOP engine,such orbix embedded orb,highlander embedded visibroker,etc.Is the IIOP engine implemented by OMG minimumCORBA specifications?Anyone can help me?Thanks.
_____________________________________________
Ê׶¼ÔÚÏß--ÏȽøÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net
Ãâ·ÑÓÊÏä ÓʼþÔÓÖ¾ Ç©ÃûÓʼþ Óʼþ¼ÓÃÜ Óʼþ×·Éíºô
ËÑË÷ÒýÇæ ¸öÈËÕ¾µã ÔÚÏßÓÎÏ· ÍøÉÏÁÄÌì ÍøÉϹҺÅ
½ðÈÚÍõ¹ú ÔÚÏßɱ¶¾ ÌøÔéÊг¡ Èí¼þÏÂÔØ ÐÝÏÐÓéÀÖ
ŵ·½°²È«£¬ÖúÄúe·ƽ°²
From glowstars@gmx.de Thu Dec 9 08:12:10 1999
From: glowstars@gmx.de (Thorsten Roskowetz)
Date: Thu, 9 Dec 1999 09:12:10 +0100 (MET)
Subject: [omniORB] omniidl bug?
References:
Message-ID: <16821.944727130@www7.gmx.net>
Duncan,
although the 'enormous' patch didn't fix Mark's problem I still
have one question: Wouldn't it be better (read: more portable)
to use UINT_MAX from than 0xffffffffU ?
Thorsten
Mark Borges wrote:
> Duncan,
>
> I applied the enormous patch, but sadly it had no effect.
>
> Is there any other diagnostic information I can provide to help find a
> solution? Is there a mini test program I can compile and run here that
> would
> help (sorry, I'm new to C++ so I can't help much -- the omniORB python
> binding is what lured me here in the first place :-).
>
> Mark
>
> > -----Original Message-----
> > From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
> > Sent: Wednesday, December 08, 1999 2:00 AM
> > To: Borges, Mark
> > Cc: 'omniorb-list@uk.research.att.com'
> > Subject: Re: [omniORB] omniidl bug?
> >
> >
> > On Tuesday 7 December, "Borges, Mark" wrote:
> >
> > > $ /opt/omniORB/scripts/omniidl -I. -bpython cdt.idl
> > > cdt.idl:6: Integer literal is too large for unsigned long
> > > omniidl: 1 error.
> > > --------------------
> > >
> > > Why? Neither omniidl2 nor python-stubber from the
> > XEROX-PARC ILU-2.0beta1
> > > distribution complain.
> >
> > [...]
> >
> > > if (value_ > 0xffffffff) {
> >
> > [...]
> >
> > > $ gcc -dumpversion
> > > 2.95.2
> > > $ gcc -dumpmachine
> > > sparc-sun-solaris2.6
> >
> > I assume the problem is that on Sparc, the 0xffffffff is being
> > sign-extended to be -1. It's not obvious from the C++ spec what the
> > behaviour should be. Can you try the following enormous patch to see
> > if the problem goes away?
> >
> >
> > --- idlexpr.cc 1999/11/02 17:07:26 1.3
> > +++ idlexpr.cc 1999/12/08 09:55:13
> > @@ -144,7 +144,7 @@
> > }
> > _CORBA_ULong IntegerExpr::evalAsULong() {
> > #ifdef HAS_LongLong
> > - if (value_ > 0xffffffff) {
> > + if (value_ > 0xffffffffU) {
> > IdlError(file(), line(), "Integer literal is too large
> > for unsigned long");
> > return 1;
> > }
> >
> >
> > Cheers,
> >
> > Duncan.
> >
> > --
> > -- Duncan Grisby \ Research Engineer --
> > -- AT&T Laboratories Cambridge --
> > -- http://www.uk.research.att.com/~dpg1 --
> >
>
--
Sent through Global Message Exchange - http://www.gmx.net
From glowstars@gmx.de Thu Dec 9 08:48:28 1999
From: glowstars@gmx.de (Thorsten Roskowetz)
Date: Thu, 9 Dec 1999 09:48:28 +0100 (MET)
Subject: [omniORB] omniidl bug?
References: <16821.944727130@www7.gmx.net>
Message-ID: <32350.944729308@www7.gmx.net>
Hate to correct myself but I meant ULONG_MAX of course.
BTW: It should be 0xffffffffUL then...
Thorsten
> Duncan,
>
> although the 'enormous' patch didn't fix Mark's problem I still
> have one question: Wouldn't it be better (read: more portable)
> to use UINT_MAX from than 0xffffffffU ?
--
Sent through Global Message Exchange - http://www.gmx.net
From dgrisby@uk.research.att.com Thu Dec 9 09:29:35 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Thu, 09 Dec 1999 09:29:35 +0000
Subject: [omniORB] omniidl bug?
In-Reply-To: Your message of "Thu, 09 Dec 1999 09:12:10 +0100."
<16821.944727130@www7.gmx.net>
Message-ID: <199912090929.JAA23299@pineapple.cam-orl.co.uk>
On Thursday 9 December, Thorsten Roskowetz wrote:
> although the 'enormous' patch didn't fix Mark's problem I still
> have one question: Wouldn't it be better (read: more portable)
> to use UINT_MAX from than 0xffffffffU ?
It is wrong to use UINT_MAX or ULONG_MAX, since the code in question
is making sure that the number fits in 32 bits. On 64 bit platforms,
ULONG_MAX, and possibly UINT_MAX will be too big.
Anyway, it turns out that the problem is nothing to do with that test,
but to do with reading the number in the first place. There is a fix
in CVS.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From Andrew.Weaver@tecnomen.fi Thu Dec 9 11:39:57 1999
From: Andrew.Weaver@tecnomen.fi (Andrew Weaver)
Date: Thu, 9 Dec 1999 13:39:57 +0200
Subject: [omniORB] ORBInitialPort
Message-ID: <99Dec9.143705gmt+0200.115586@sister.tecnomen.fi>
Moi, running omniORB 2.8 on Linux kernel 2.2.5-15.
I have rebuilt the entire thing receiving some warnings that some refs might
be used uninitialised but no outright failures.
Now, I have the .cfg file created and it contains the entries ORBInitialHost
and ORBInitialPort
I start the omniNames for the first time with ./omniNames -start 70000 and
get the message "Configuration error: Invalid object reference supplied for
ORBInitialPort. Aborted"
I noticed in the mail archive that somebody else had a similar problem but
cannot find any patch or so.
Can anybody tell me what is wrong here please?
Kind Regards
Andy Weaver
From dgrisby@uk.research.att.com Thu Dec 9 11:59:35 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Thu, 09 Dec 1999 11:59:35 +0000
Subject: [omniORB] ORBInitialPort
In-Reply-To: Your message of "Thu, 09 Dec 1999 13:39:57 +0200."
<99Dec9.143705gmt+0200.115586@sister.tecnomen.fi>
Message-ID: <199912091159.LAA00797@pineapple.cam-orl.co.uk>
On Thursday 9 December, Andrew Weaver wrote:
> I start the omniNames for the first time with ./omniNames -start 70000 and
> get the message "Configuration error: Invalid object reference supplied for
> ORBInitialPort. Aborted"
70000 is not a valid port number. Port numbers are unsigned 16 bit
integers, so you have to choose a port less than 65535.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From gdd0@gte.com Thu Dec 9 15:05:51 1999
From: gdd0@gte.com (Gary D. Duzan)
Date: Thu, 09 Dec 1999 10:05:51 -0500
Subject: [omniORB] Call Timeout
Message-ID: <199912091505.KAA00444@duzanmac.gte.com>
Can we please disable timeouts on method calls by default? They
are easy to overlook and I believe it violates the principle of
least surprise to have a method call randomly generate a COMM_FAILURE
when the system becomes a little slower than usual. While this
might be reasonable behavior in, e.g., a client-server situation
where the client or the connection is expected to be unreliable,
I would expect a COMM_FAILURE in a fairly reliable peer-to-peer
situation to indicate that something serious had occurred.
Thanks.
Gary Duzan
GTE Laboratories
From dgrisby@uk.research.att.com Thu Dec 9 15:37:17 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Thu, 09 Dec 1999 15:37:17 +0000
Subject: [omniORB] Another question about CORBA thread model in embedded system
In-Reply-To: Your message of "Thu, 09 Dec 1999 10:45:04 +0800."
<384F17B0.29494@mta4>
Message-ID: <199912091537.PAA04807@pineapple.cam-orl.co.uk>
On Thursday 9 December, biguo@263.net wrote:
> Hello,folks!I still have a question.In CORBA model,there is a thread
> scheduler in BOA of server side.These threads is scheduled by ORB
> and they're invisible to underlying OS.So,I say these threads are
> user level threads.Is it right?In embedded CORBA,ORB thread is the
> task of RTOS.These thread/task is visible to ORB and RTOS.Are they
> scheduled by ORB or RTOS?How to implement it?Anyone can help
> me?Thanks.
In omniORB, all threads are operating system threads. There is no
scheduler in omniORB.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From rgruet@ina.fr Thu Dec 9 15:49:46 1999
From: rgruet@ina.fr (Richard Gruet)
Date: Thu, 09 Dec 1999 16:49:46 +0100
Subject: [omniORB] IDL sequences map to Python lists, not tuples.
Message-ID: <384FCF9A.D43164D5@ina.fr>
Just a detail concerning the Python back-end.
Unlike stated in the submission for the Python mapping, the actual
mapping in OmniORBpy for an IDL sequence
seems to require a Python LIST. Any attempt to pass a TUPLE to a
function (as an in or out parameter)
results in a BAD_PARAM exception.
Maybe it's normal, but I lost some time to find the rule....
cheers,
Richard
From dgrisby@uk.research.att.com Thu Dec 9 15:52:27 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Thu, 09 Dec 1999 15:52:27 +0000
Subject: [omniORB] IDL sequences map to Python lists, not tuples.
In-Reply-To: Your message of "Thu, 09 Dec 1999 16:49:46 +0100."
<384FCF9A.D43164D5@ina.fr>
Message-ID: <199912091552.PAA04865@pineapple.cam-orl.co.uk>
On Thursday 9 December, Richard Gruet wrote:
> Unlike stated in the submission for the Python mapping, the actual
> mapping in OmniORBpy for an IDL sequence
> seems to require a Python LIST. Any attempt to pass a TUPLE to a
> function (as an in or out parameter)
> results in a BAD_PARAM exception.
I added support for tuples a few days ago. If you get the latest
version from CVS or the FTP snapshots, you'll find that it supports
tuples.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From cameron.bruce@mayo.edu Thu Dec 9 17:17:31 1999
From: cameron.bruce@mayo.edu (Bruce Cameron)
Date: Thu, 09 Dec 1999 11:17:31 -0600
Subject: [omniORB] Bug in omniORB 3.0
Message-ID: <384FE42B.E1103CC7@mayo.edu>
I'm running omniORB 3.0 under Irix 6.5.3 using the 7.3 MIPS C++
compiler.
When starting my server, I catch the following exception:
omniORB: Assertion failed. This indicates a bug in omniORB.
file: ../corbaObject.cc
line: 223
info: !_NP_is_pseudo()
Is this a real bug, or am I doing something really wrong in my
code? If it is a real bug, is there a patch yet? Could this be
due to my trying to create a child POA with a nil POAManager?
My server code is:
int main (int argc, char**argv)
{
try {
cerr << "1" << endl;
CORBA::ORB_var orb = CORBA::ORB_init(argc,argv,"omniORB3");
cerr << "2" << endl;
CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
PortableServer::POA_var poa = PortableServer::POA::_narrow(obj);
cerr << "3" << endl;
PortableServer::POAManager_var mgr = poa->the_POAManager();
mgr->activate();
cerr << "4" << endl;
Factory_impl factory_servant(poa); // THROWS EXCEPTION ABOUT HERE?
cerr << "5" << endl;
PortableServer::ObjectId_var oid =
PortableServer::string_to_ObjectId("vrs_WorldFactory");
cerr << "5a" << endl;
poa->activate_object_with_id(oid,&factory_servant);
cerr << "6" << endl;
orb->run();
}
catch (const CORBA::Exception&) {
cerr << "Uncaught corba exception" << endl;
return 1;
}
return 0;
}
and the factory constructor is
Factory_impl::Factory_impl (PortableServer::POA_ptr poa)
{
cerr << "Factory_impl" << endl;
_rootPoa = poa;
cerr << "\t1" << endl;
PortableServer::IdAssignmentPolicy_var assign =
_rootPoa->create_id_assignment_policy(PortableServer::USER_ID);
cerr << "\t2" << endl;
CORBA::PolicyList policyList;
policyList.length(1);
policyList[0] = PortableServer::IdAssignmentPolicy::_duplicate(assign);
PortableServer::POAManager_var mgr =
PortableServer::POAManager::_nil();
cerr << "\t3" << endl;
_worldPoa = _rootPoa->create_POA ("Worlds", mgr, policyList);
cerr << "Factory_impl" << endl;
}
Output from this whole mess is:
1
2
3
4
Factory_impl
1
2
3
Factory_impl
omniORB: Assertion failed. This indicates a bug in omniORB.
file: ../corbaObject.cc
line: 223
info: !_NP_is_pseudo()
Abort (core dumped)
--
--Bruce
From crawley@dstc.edu.au Fri Dec 10 00:29:43 1999
From: crawley@dstc.edu.au (Stephen Crawley)
Date: Fri, 10 Dec 1999 10:29:43 +1000
Subject: [omniORB] Miscellaneous problems with omniEvents 2.0
In-Reply-To: Message from "Poilpret Jean Francois"
of "Fri, 03 Dec 1999 17:24:24 +0700." <000301bf3d78$ab2ac520$0100a8c0@windev>
Message-ID: <199912100029.KAA21943@piglet.dstc.edu.au>
Jean Francois,
You wrote:
> 1. The file CosEventChannelAdmin.idl is not compliant with the "officia=
l" =
> OMG IDL file, since it includes "CosLifeCycle.idl". Moreover, it seems =
> that nothing from CosLifeCycle.idl is used inside CosEventChannelAdmin.=
idl. =
> So I cleared the including line from the file. After this, no problem.
I'm being a bit pedantic but ... the OMG IDL files are provided by the
OMG as a convenience for implementors and users. Compliance is measured
against the specifications from which the IDL on those files was extracte=
d.
The file structure ... and that includes presence or absence of #includes=
of other files ... is not an OMG compliance point.
That having been said, it >>is<< a bad idea for the omniORB version of th=
e
CosEventChannelAdmin.idl file to #include another IDL file that is not us=
ed.
-- Steve
From agranov@redconnect.net Fri Dec 10 06:54:38 1999
From: agranov@redconnect.net (Alex Agranov)
Date: Fri, 10 Dec 1999 01:54:38 -0500
Subject: [omniORB] Any Sun C++ 5.0 updates???
References: <384FE42B.E1103CC7@mayo.edu>
Message-ID: <3850A3AE.E394AE4E@redconnect.net>
Hi folks...
Any news on this front? We're moving to production soon with the 5.0
compiler (client choice, not ours) and the thing makes me feel real uneasy.
I've applied the new libC patch (there's been a new one since the omni 2.8.0
release notes) which is stated as fixing some exception handling snafus but
it doesn't seem to have any effect. And yes, the compile times are
flabbergasting...
Alex
From rgruet@ina.fr Fri Dec 10 10:03:22 1999
From: rgruet@ina.fr (Richard Gruet)
Date: Fri, 10 Dec 1999 11:03:22 +0100
Subject: [omniORB] Mispelling in "CORBA scripting with Python" doc
Message-ID: <3850CFEA.F4D197BB@ina.fr>
There is a mispelling in the "CORBA scripting with Python" document,
paragraph 4.6 (p.20):
The method orb.list_initial_references() doesnt exist.
The right name is: orb.list_initial_services() ... and it works.
Richard
From b.keeping@ic.ac.uk Fri Dec 10 11:58:31 1999
From: b.keeping@ic.ac.uk (b.keeping@ic.ac.uk)
Date: Fri, 10 Dec 1999 11:58:31 GMT
Subject: [omniORB] Call Timeout
In-Reply-To: <199912091505.KAA00444@duzanmac.gte.com> (gdd0@gte.com)
Message-ID: <6420.199912101158@ultra11.ps.ic.ac.uk>
Hi,
Just writing to second Gary's proposal! A useful feature in some
contexts I'm sure, but one which should be consciously activated
rather than on by default.
Ben Keeping
Imperial College
From omniorb@beteigeuze.cs.tu-berlin.de Fri Dec 10 12:09:56 1999
From: omniorb@beteigeuze.cs.tu-berlin.de (Robert Sander)
Date: Fri, 10 Dec 1999 13:09:56 +0100
Subject: [omniORB] omniORBpy: Nameserver IOR via HTTP
Message-ID: <19991210130956.B21801@beteigeuze.cs.tu-berlin.de>
Hi!
In standard omniORB config I have a Nameserver IOR string in omniORB.cfg,
but I have a special case, where I only get the IOR via HTTP, because the
nameserver changes from time to time. Is it possible to set the nameserver
IOR in the program, before calling CORBA.ORB_init. Maybe it is stated
somewhere in the docs, so a reference is also useful.
Thank You.
--
Robert Sander
home.pages.de/~gurubert, pgp available there
tel 0700-GURUBERT
From djr@uk.research.att.com Fri Dec 10 12:36:10 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Fri, 10 Dec 1999 12:36:10 +0000 (GMT)
Subject: [omniORB] omniORBpy: Nameserver IOR via HTTP
In-Reply-To: <19991210130956.B21801@beteigeuze.cs.tu-berlin.de>
Message-ID:
There is an omniORB specific solution:
void _omni_set_NameService(CORBA::Object_ptr ns);
I don't think it is documented though, and certainly not portable.
Cheers,
David
On Fri, 10 Dec 1999, Robert Sander wrote:
> In standard omniORB config I have a Nameserver IOR string in omniORB.cfg,
> but I have a special case, where I only get the IOR via HTTP, because the
> nameserver changes from time to time. Is it possible to set the nameserver
> IOR in the program, before calling CORBA.ORB_init. Maybe it is stated
> somewhere in the docs, so a reference is also useful.
From djr@uk.research.att.com Fri Dec 10 12:44:13 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Fri, 10 Dec 1999 12:44:13 +0000 (GMT)
Subject: [omniORB] OmniNames on omniORB 3 pre
In-Reply-To:
Message-ID:
Hi,
I've tracked down and fixed the problem with the bootstrap agent in
omniORB 3. There was a deadlock if you used the ORBInitialHost
ORBInitialPort mechanism for getting initial references.
The fix wil be in CVS tonight ...
David
On Thu, 2 Dec 1999, David Riddoch wrote:
> I've had a look at this, and yes there is a problem. In theory it should
> have all worked as it used to. It does work in the case where you put
> NAMESERVER IOR:... into the config file, but not when you use
> ORBInitialHost and ORBInitialPort. Looks like I've done something to
> damage the bootstrap agent.
>
> I'll look into it.
>
> Cheers,
> David
>
>
> On Tue, 30 Nov 1999, Kapla, Jami wrote:
>
> > Hello David,
> > We are trying to use the Omniidl3 on linux 6.0
> > and test the echo example. The eg1 works however the eg3_impl
> > fails when the call to orb->resolve_initial_references("NameServece")
> > is called. We are trying to find what exception is being thrown. However
> > I believe it has something to do with either the ORB is configured wrong
> > or the omniORB.cfg file is not configured correctly. There is a mention
> > in the 3.0 release notes of changes to the log file for omniNames but no
> > specifics. currently we start the omniNames:
> >
> > omniNames -start 1234
> > which then seems to start it ok.
> >
> > omniORB.cfg has:
> > ORBInitialHost korea (my machine)
> > ORBInitialPort 1234
> >
> > and OMNIORB_CONFIG is set in the environment to the correct path.
> >
> > However we are using the documentation for OmniOrb2, so maybe this has
> > changed some(?).
> > We simply did a make all and ran eg3.impl but the resolve_initial_refernces
> > call fails. (it also fails for all ID's except "RootPOA").
From omniorb@beteigeuze.cs.tu-berlin.de Fri Dec 10 12:51:55 1999
From: omniorb@beteigeuze.cs.tu-berlin.de (Robert Sander)
Date: Fri, 10 Dec 1999 13:51:55 +0100
Subject: [omniORB] omniORBpy: Nameserver IOR via HTTP
In-Reply-To: ; from djr@uk.research.att.com on Fri, Dec 10, 1999 at 12:36:10PM +0000
References: <19991210130956.B21801@beteigeuze.cs.tu-berlin.de>
Message-ID: <19991210135155.A23134@beteigeuze.cs.tu-berlin.de>
On Fri, Dec 10, 1999 at 12:36:10PM +0000, David Riddoch wrote:
>
> There is an omniORB specific solution:
>
> void _omni_set_NameService(CORBA::Object_ptr ns);
>
> I don't think it is documented though, and certainly not portable.
I'm sure every solution would not be portable, but this is a beginning. I
can get the IOR with Python using urllib.urlopen etc. and then do a
orb.string_to_object to get the NameService object. Using the method above
I could add this object to the avaiable services.
Or I could just use the object as a NameService object directly, without
adding it to the avaiable services. That should work, too.
Thanks
--
Robert Sander
home.pages.de/~gurubert, pgp available there
tel 0700-GURUBERT
From chapmanb@arches.uga.edu Fri Dec 10 21:39:43 1999
From: chapmanb@arches.uga.edu (Brad Chapman)
Date: Fri, 10 Dec 1999 16:39:43 -0500
Subject: [omniORB] FreeBSD and omniORBpy
Message-ID:
--============_-1267260500==_============
Content-Type: text/plain; charset="us-ascii"
Hello all! I have been attempting to get omniORB working on FreeBSD 3.3 so
that I can work with the python bindings (thanks much for them!).
Unfortunately, I have only had partial success doing this, likely due to my
inexperience in this area. I have managed to, I think, get omniORB itself
compiled, but cannot get the test examples to compile (so I can't check how
well my compilation went!). In addition, I am having problems trying to get
the python bindings to compile. So, some solutions, but lots of problems.
I have included as a text file attachment a description of what I
have done/tried to do, and my results. If anyone would be willing to take a
look at it and give my some pointers, etc. I would be extremely
appreciative!
Brad
chapmanb@arches.uga.edu
--============_-1267260500==_============
Content-Type: text/plain; name="ooprob.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="ooprob.txt"
Thank you very much if you took the time to take a look at this. I'm
pretty new at this, but I have tried to detail as much relevant info as I
could below. If you need anything else at all I will, of course, be happy
to
provide it!
First off, this is the info about what I'm using:
FreeBSD
3.3-release
gmake 3.77
gcc/g++ 2.95.2
BUILD PROBLEMS
--------------
In
order to build omniORB, I followed the omniORB 2.7.1 and FreeBSD 3.2
directions with the following changes to x86_freebsd_3.2.mk:
1. I
uncommented the relevant parts at the end to get static linking (I
didn't
want to do this, but I couldn't get it to build otherwise).
2. I changed
the c and c++ compilers from the made up egcs and egcs++ compilers to
gcc295 and g++295, the most recent versions of these I could get my hands
on.
When I compiled, it went fine for a while until I got
here:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
gcc295 -c -O2 -DHOSTS_ACCESS -DLIBC_CALLS_STRTOK -DBROKEN_FGETS
-DHOSTS_DENY=\"/etc/hosts.deny\" -DHOSTS_ALLOW=\"/etc/hosts.allow\"
-DRFC931_TIMEOUT=10 -DSOLARIS_24_GETHOSTBYNAME_BUG -DGETPEERNAME_BUG
-D_REENTRANT -I. -I../.. -I../../.. -I. -I../../../../../../include
-D__x86__ -D__freebsd__ -D__OSVERSION__=3 -o percent_m.o
percent_m.c
percent_m.c:18: conflicting types for
`sys_errlist'
/usr/include/stdio.h:225: previous declaration of
`sys_errlist'
gmake[5]: *** [percent_m.o] Error 1
gmake[5]: Leaving
directory
`/usr/local/omniORB/src/lib/omniORB2/orbcore/gatekeepers/tcpwrapper'
%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Not
wanting to mess around with stdio, I looked at the offending file in
"src/lib/omniORB2/orbcore/gatekeepers/tcpwrapper/percent_m.c" where I
found the following:
extern int errno;
#if !(defined(__GLIBC__) &&
__GLIBC__ >=2)
#if !defined(SYS_ERRLIST_DEFINED) ||
!defined(__freebsd__)
extern char *sys_errlist[];
extern int
sys_nerr;
#endif
#endif
To me, this read that it should not be executing
"extern char
*sys_errlist[];" on FreeBSD so I decided to comment it out
and force it not to
execute (hopefully my interpretation of the code was
not too wrong!).
After doing this everything else compiled without a
problem and I was able
to go through and do everything with omniName
without any problems. Then I
proceeded to try to compile the
examples:
EXAMPLE PROBLEMS
----------------
When I tried to build the
examples to test everything, I did the following:
1. Manually built the
.hh files by running omniidl2 in each directory
2. Tried "gmake all" in the
main examples directory.
Nearly immediately I got the following
compilation errors in the echo test
directory:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%
+ g++295 -pthread -s -o eg1 -O2 -Wall -Wno-unused
-L../../../lib/x86_freebsd_3.2
eg1.o -Wl,-Bstatic -lomniORB2
-lomniDynamic2 -ltcpwrapGK -lomnithread -Wl,-Bdynam
ic
eg1.o: In function
`hello(CORBA::Object *)':
eg1.o(.text+0x23): undefined reference to
`Echo::_narrow(CORBA::Object *)'
eg1.o(.text+0x91): undefined reference to
`Echo_Helper::release(Echo *)'
eg1.o(.text+0x1cc): undefined reference to
`Echo_Helper::release(Echo *)'
eg1.o(.text+0x207): undefined reference to
`Echo_Helper::release(Echo *)'
eg1.o: In function
`main':
eg1.o(.text+0x29e): undefined reference to `Echo::omniObject
virtual table'
eg1.o(.text+0x2a7): undefined reference to
`Echo::CORBA::Object virtual table'
eg1.o(.text+0x2ae): undefined reference
to `Echo virtual table'
eg1.o(.text+0x2fe): undefined reference to
`_sk_Echo::omniObject virtual table'
eg1.o(.text+0x309): undefined
reference to `_sk_Echo::CORBA::Object virtual table
'
eg1.o(.text+0x312):
undefined reference to `_sk_Echo::Echo virtual table'
eg1.o(.text+0x3c6):
undefined reference to `Echo::_duplicate(Echo *)'
eg1.o: In function
`Echo_i::Echo_i(int)':
eg1.o(.text+0x517): undefined reference to
`Echo::omniObject virtual table'
eg1.o(.text+0x520): undefined reference to
`Echo::CORBA::Object virtual table'
eg1.o(.text+0x527): undefined reference
to `Echo virtual table'
eg1.o(.text+0x57e): undefined reference to
`_sk_Echo::omniObject virtual table'
eg1.o(.text+0x589): undefined
reference to `_sk_Echo::CORBA::Object virtual table
'
eg1.o(.text+0x592):
undefined reference to `_sk_Echo::Echo virtual table'
eg1.o: In function
`Echo_i::~Echo_i(void)':
eg1.o(.text+0x664): undefined reference to
`_sk_Echo::~_sk_Echo(void)'
eg1.o(.text+0x672): undefined reference to
`Echo::~Echo(void)'
eg1.o(.rodata+0x1e4): undefined reference to `_sk_Echo
type_info node'
eg1.o: In function `virtual function thunk (delta:0) for
_sk_Echo::76_dispatch(GI
OP_S &, char const *,
bool)':
eg1.o(.gnu.linkonce.t.__thunk_n76_dispatch__8_sk_EchoR6GIOP_SPCcb+0x6):
undefined
reference to `_sk_Echo::dispatch(GIOP_S &, char const *,
bool)'
eg1.o: In function
`__thunk_n76__widenFromTheMostDerivedIntf__8_sk_EchoPCcb':
eg1.o(.gnu.linkonce.t
.__thunk_n76__widenFromTheMostDerivedIntf__8_sk_EchoPCcb+0x6
): undefined
reference to `_sk_Echo::_widenFromTheMostDerivedIntf(char const *,
b
ool)'
eg1.o: In function `Echo_i type_info
function':
eg1.o(.gnu.linkonce.t.__tf6Echo_i+0x16): undefined reference to
`_sk_Echo type_in
fo function'
collect2: ld returned 1 exit
status
gmake[1]: *** [eg1] Error
1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
As
suggested in the README.FreeBSD, I tried to use -lpthread, but this gave
the error: "/usr/libexec/elf/ld: cannot open -lpthread: No such file or
directory" and after searching through FreeBSD archives, it turns out
that,
for some reasons I don't understand, the -pthread is FreeBSD
specific for
gcc/g++ and -lpthread isn't supported.
omniORBpy
PROBLEMS
-------------------
Running gmake export on the omniORBpy
distribution (just cvsed today) gave
the
following:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%
gcc295 -c -O2 -DHAVE_CONFIG_H -I. -I. -I../../../../../../include
-D__x86__
-D__freebsd__ -D__OSVERSION__=3 -o cexp.o cexp.c
cexp.y: In
function `yylex':
cexp.y:688: `SIZEOF_UNSIGNED_CHAR' undeclared (first use
in this function)
cexp.y:688: (Each undeclared identifier is reported only
once
cexp.y:688: for each function it appears in.)
cexp.y:694: `SIZEOF_INT'
undeclared (first use in this function)
cexp.y: In function
`left_shift':
cexp.y:1023: `SIZEOF_INT' undeclared (first use in this
function)
cexp.y: In function `right_shift':
cexp.y:1034: `SIZEOF_INT'
undeclared (first use in this function)
gmake[3]: *** [cexp.o] Error
1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
I'm
not sure how I should proceed to fix this at all. The real reason I am
trying all of this is to use the python bindings, so I'm very interested
in anything I can do to fix this problem!
Well, if you made it all of
the way here I would like to offer my
sincerest thanks. If you need any
other info at all, please don't hesitate
to ask. Any advice anyone can
offer would be greatly appreciated! Thanks
again.
Brad
chapmanb@arches.uga.edu
--============_-1267260500==_============--
From rodrigc@mediaone.net Sat Dec 11 01:38:17 1999
From: rodrigc@mediaone.net (Craig Rodrigues)
Date: Fri, 10 Dec 1999 20:38:17 -0500
Subject: [omniORB] Support for GIOP 1.2?
Message-ID: <19991210203817.A4180@mediaone.net>
Hi,
Does omniORB support GIOP 1.2?
If not, does anyone know of any of the free CORBA ORB's which support it?
As an aside, has anyone read "IIOP Complete", by William Ruh?
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@mediaone.net
From biguo@263.net Sun Dec 12 07:28:12 1999
From: biguo@263.net (biguo@263.net)
Date: Sun, 12 Dec 1999 15:28:12 +0800 (CST)
Subject: [omniORB] A relation between IIOP Engine and MinimumCORBA
Message-ID: <38534E8C.25821@mta2>
Hello,folks!As we know,OMG MinimumCORBA specifications is uesd in limited resources system.Whereas in embedded system,IIOP Engine presently is a mainstream technology in solving interoperability.IIOP is also a reduced ORB function library.Is IIOP Engine is implemented according to OMG MinimumCORBA specifications?Anyone can help me?Thanks.
_____________________________________________
Ê׶¼ÔÚÏß--ÏȽøÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net
Ãâ·ÑÓÊÏä ÓʼþÔÓÖ¾ Ç©ÃûÓʼþ Óʼþ¼ÓÃÜ Óʼþ×·Éíºô
ËÑË÷ÒýÇæ ¸öÈËÕ¾µã ÔÚÏßÓÎÏ· ÍøÉÏÁÄÌì ÍøÉϹҺÅ
½ðÈÚÍõ¹ú ÔÚÏßɱ¶¾ ÌøÔéÊг¡ Èí¼þÏÂÔØ ÐÝÏÐÓéÀÖ
ŵ·½°²È«£¬ÖúÄúe·ƽ°²
From sekiya@nagoya.ydc.co.jp Mon Dec 13 08:47:27 1999
From: sekiya@nagoya.ydc.co.jp (Masaaki Sekiya)
Date: Mon, 13 Dec 1999 17:47:27 +0900 (JST)
Subject: [omniORB] how to get a RootContext
Message-ID: <199912130847.RAA07577@deer1.nagoya.ydc.co.jp>
Hello there.
I'm new to the omniORB.
And I'm trying to get a RootContextObject of a arbitary Naming Server.
I made a code like below. It works how I expect.
But I am concerned whether this code has some bugs.
Are there any harmful point in this code or a better code ?
If you are aware of , I would be extremely appreciative for it.
===============
const ropeFactoryType* t;
ropeFactory_iterator next(globalOutgoingRopeFactories);
const ropeFactory* f;
while ((f = next())) {
t = f->getType();
if (t->is_IOPprofileId(IOP::TAG_INTERNET_IOP))
break;
}
if (f){
CORBA::Char* host= .. // arbitary
CORBA::UShort port= .. // arbitary
tcpSocketEndpoint addr(host,port);
CORBA::Char objkey[4];
objkey[0] = 'I'; objkey[1] = 'N'; objkey[2] = 'I';
objkey[3] = 'T';
IOP::TaggedProfileList p;
p.length(1);
t->encodeIOPprofile((Endpoint*)&addr,objkey,4,p[0]);
CORBA::String_var ior((char*) IOP::iorToEncapStr(
(const CORBA::Char*)CORBA_InitialReferences_IntfRepoID,&p));
CORBA::Object_var o((CORBA::Object_ptr) (
omni::stringToObject(ior)->_widenFromTheMostDerivedIntf(0)));
CORBA_InitialReferences_var bagent;
bagent = CORBA_InitialReferences::_narrow(o);
bagent->noExistentCheck();
CORBA::Object_ptr obj = pagent->get("NameService");
...
===============
Masaaki Sekiya
From s.starkie@ic.ac.uk Mon Dec 13 17:18:50 1999
From: s.starkie@ic.ac.uk (Stephen Starkie)
Date: Mon, 13 Dec 1999 17:18:50 +0000
Subject: [omniORB] Visual C++ Assertions
Message-ID: <38552A65.8E2FB2DC@ic.ac.uk>
Hi,
I'm just starting with OmniORB (2.8.0) on Visual C++ on Windows NT,
and I have been trying the Name Service version of the Echo example.
It seems to work apart from a whole load of failed assertions at the end
to do with valid heap pointers in the client.
Anybody any ideas as to why? And how I can stop it.
Steve
From gtrudel@mediatrix.com Mon Dec 13 17:57:09 1999
From: gtrudel@mediatrix.com (Guy Trudel)
Date: Mon, 13 Dec 1999 12:57:09 -0500
Subject: [omniORB] Visual C++ Assertions
Message-ID: <80E2FF0AC64DD311AC3700E02910AE0A136985@INTERNAL>
be careful not to mix debug/release static/dll versions of MSVC and OmniOrb
runtimes.
Guy Trudel
From taukerman@logici.com Mon Dec 13 18:04:24 1999
From: taukerman@logici.com (Theo Aukerman)
Date: Mon, 13 Dec 1999 10:04:24 -0800
Subject: [omniORB] static/dll MSVC with omniORB
Message-ID: <9BF81AC2F664D311A56600A0C9AC979A1A9B6F@gateway.logici.com>
On 12/13/99 at 9:57 AM Guy Trudel wrote:
be careful not to mix debug/release static/dll versions of MSVC and OmniOrb
runtimes.
Guy Trudel
_________________________________
While it is clear to me how to determine if I am using a debug vs. release
build of the omniORB dll's, how do I know if I am using omniORB dll's built
with static vs. dll versions of MSVC?
I'm using a 2.7.1 distribution which included binaries, and I have not had a
need (so far) to build the omniORB dll's myself.
Theo Aukerman
From gtrudel@mediatrix.com Mon Dec 13 20:53:42 1999
From: gtrudel@mediatrix.com (Guy Trudel)
Date: Mon, 13 Dec 1999 15:53:42 -0500
Subject: [omniORB] static/dll MSVC with omniORB
Message-ID: <80E2FF0AC64DD311AC3700E02910AE0A136986@INTERNAL>
>From README.win32:
c) Set up macros and libraries:
1. Under Build->Settings, select the "C/C++" tab.
2. In the "Category" box, select "C++ Language". Tick the
"Enable exception handling" box.
3. In the "Category" box, select "Code Generation". In the
"Use run-time library" box, select "Multithreaded DLL".
4. **This is an import step.**
In the "Category" box, select "Preprocessor". In the
"Preprocessor" box, add the macros __WIN32__,__x86__.
If this is NT 4.0, add the macros __NT__ and __OSVERSION__=4 as well.
5. Select the "Link" tab.
6. In the "Category" box, select "Input". In the "Object/library
modules"
box, add the following libraries: wsock32.lib, advapi32.lib,
omniORB280_rt.lib, omnithread2_rt.lib
If you are building a debug executable, the debug version of the
libraries:
omniORB280_rtd.lib and omnithread2_rtd.lib should be used.
d) Your project is now set up, and you can build it.
If you want to use the static versions of omniORB2 and omnithread, you must
add the macro _WINSTATIC (see step (c) 4, above), and replace the libraries
omniORB2_rt.lib and omnithread2_rt.lib with omniORB2.lib and omnithread.lib
(see step (c) 6, above).
From virtualcyber@erols.com Tue Dec 14 05:35:45 1999
From: virtualcyber@erols.com (Ji-Yong D. Chung)
Date: Tue, 14 Dec 1999 00:35:45 -0500
Subject: [omniORB] python and scheme
Message-ID: <000501bf45f5$14467890$0a0a0a0a@cradle>
omniORB developers:
Just a comment on omniORBpy.
I know that there are many advantages to using interpreters for
development -- so it makes sense that you guys wrote python ORB -- I think
it's a great idea.
I wish, though, you guys developed a language binding for "Scheme" (a
dialect of lisp) rather than python. Python is really mutated Scheme. And
as such, Scheme interpreters, provide all the features of python
interpreters, but with better syntax.
Of course, there is no Scheme language mappings published by OMG.
From douglask@dstc.edu.au Tue Dec 14 01:37:53 1999
From: douglask@dstc.edu.au (Douglas Kosovic)
Date: Tue, 14 Dec 1999 11:37:53 +1000
Subject: [omniORB] #pragma version
Message-ID: <38559F71.6C4EC6@dstc.edu.au>
Hi,
Is anyone able to use '#pragma version' in IDL files with the OmniORB
2.8 or later IDL compiler (on Solaris)?
With the following IDL:
interface IRObject {
#pragma version IRObject 2.3
readonly attribute DefinitionKind def_kind;
void destroy();
};
I get the following error message:
line 2: Illegal syntax following interface '{' opener
Currently I'm commenting out all occurrences of '#pragma version' and
then manually modifying the version numbers in the .hh stub that gets
generated.
Thanks,
Doug.
From brent.fulgham@xpsystems.com Tue Dec 14 00:45:16 1999
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Mon, 13 Dec 1999 16:45:16 -0800
Subject: [omniORB] Conflict with other ORBs?
Message-ID:
Hello Omniorber's:
I run omniorb (2.8) on Debian GNU/Linux (potato). This is roughly
comparable
with the most recent release of RedHat (glibc 2.1.2).
I have the omniorb nameservice start up at boot time, and it runs in the
background like any other service on my system.
I have found that if I start the GNOME environment, however, that as soon
as the gnome-orb starts up omniorb dies. I thought initially that it might
be due to them fighting over the same port, but a quick check with `fuser`
does not show this.
Has anyone else experienced problems when orbs from multiple vendors
are running on the same system? I would have thought that they would not
be visible to each other, since the BOA::Init call seems to include
a unique identifier for the Nameservice in use (omniORB in this case).
Thanks,
-Brent
From dgrisby@uk.research.att.com Tue Dec 14 10:17:52 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 10:17:52 +0000
Subject: [omniORB] #pragma version
In-Reply-To: Your message of "Tue, 14 Dec 1999 11:37:53 +1000."
<38559F71.6C4EC6@dstc.edu.au>
Message-ID: <199912141017.KAA12089@pineapple.cam-orl.co.uk>
On Tuesday 14 December, Douglas Kosovic wrote:
> interface IRObject {
> #pragma version IRObject 2.3
> readonly attribute DefinitionKind def_kind;
> void destroy();
> };
>
> I get the following error message:
> line 2: Illegal syntax following interface '{' opener
Unfortunately, omniidl2 is broken, and doesn't support the above
IDL. It is, however, happy with
interface IRObject {
readonly attribute DefinitionKind def_kind;
void destroy();
};
#pragma version IRObject 2.3
We're not especially keen to fix it since our new IDL compiler does
support #pragma inside an interface. The new omniidl is already used
by the Python ORB, and will soon be used with omniORB3.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Tue Dec 14 10:21:47 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 10:21:47 +0000
Subject: [omniORB] omniORBpy: Nameserver IOR via HTTP
In-Reply-To: Your message of "Fri, 10 Dec 1999 13:09:56 +0100."
<19991210130956.B21801@beteigeuze.cs.tu-berlin.de>
Message-ID: <199912141021.KAA12131@pineapple.cam-orl.co.uk>
On Friday 10 December, Robert Sander wrote:
> In standard omniORB config I have a Nameserver IOR string in omniORB.cfg,
> but I have a special case, where I only get the IOR via HTTP, because the
> nameserver changes from time to time. Is it possible to set the nameserver
> IOR in the program, before calling CORBA.ORB_init. Maybe it is stated
> somewhere in the docs, so a reference is also useful.
Is there any particular reason that you have to get the object
reference with resolve_initial_references()? If not, the easiest
thing is to just get the IOR with HTTP and use string_to_object().
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Tue Dec 14 10:41:15 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 10:41:15 +0000
Subject: [omniORB] FreeBSD and omniORBpy
In-Reply-To: Your message of "Fri, 10 Dec 1999 16:39:43 EST."
Message-ID: <199912141041.KAA12185@pineapple.cam-orl.co.uk>
On Friday 10 December, Brad Chapman wrote:
> In order to build omniORB, I followed the omniORB 2.7.1 and FreeBSD
> 3.2 directions with the following changes to x86_freebsd_3.2.mk:
Is anyone successfully using omniORB 2.8.0 on FreeBSD? If so, what
did you need to do to compile it?
> 1. I uncommented the relevant parts at the end to get static linking
> (I didn't want to do this, but I couldn't get it to build
> otherwise).
What problems did you have with dynamic linking? I'd be surprised if
you can successfully build omniORBpy without working dynamic linking.
[...]
> When I tried to build the
> examples to test everything, I did the following:
>
> 1. Manually built the
> .hh files by running omniidl2 in each directory
Why did you manually build the stubs rather than letting the makefiles
do it?
> 2. Tried "gmake all" in the
> main examples directory.
> + g++295 -pthread -s -o eg1 -O2 -Wall -Wno-unused
> -L../../../lib/x86_freebsd_3.2 eg1.o -Wl,-Bstatic -lomniORB2
> -lomniDynamic2 -ltcpwrapGK -lomnithread -Wl,-Bdynamic
> eg1.o(.text+0x23): undefined reference to
> `Echo::_narrow(CORBA::Object *)'
The link line doesn't link with echoSK.o, which is why you got lots of
errors about undefined references. I don't know why the make files
aren't doing the right thing.
> Running gmake export on the omniORBpy distribution (just cvsed
> today) gave the following:
> cexp.y:688: `SIZEOF_UNSIGNED_CHAR' undeclared (first use
You need to edit cccp/config.h to add a FreeBSD configuration file. It
will probably be the same as config-linux.h.
HTH,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Tue Dec 14 10:50:44 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 10:50:44 +0000
Subject: [omniORB] Support for GIOP 1.2?
In-Reply-To: Your message of "Fri, 10 Dec 1999 20:38:17 EST."
<19991210203817.A4180@mediaone.net>
Message-ID: <199912141050.KAA12235@pineapple.cam-orl.co.uk>
On Friday 10 December, Craig Rodrigues wrote:
> Does omniORB support GIOP 1.2?
Support for GIOP 1.2 is on the way, but isn't available quite yet.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Tue Dec 14 10:54:31 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 10:54:31 +0000
Subject: [omniORB] how to get a RootContext
In-Reply-To: Your message of "Mon, 13 Dec 1999 17:47:27 +0900."
<199912130847.RAA07577@deer1.nagoya.ydc.co.jp>
Message-ID: <199912141054.KAA12257@pineapple.cam-orl.co.uk>
On Monday 13 December, Masaaki Sekiya wrote:
> And I'm trying to get a RootContextObject of a arbitary Naming Server.
> I made a code like below. It works how I expect.
> But I am concerned whether this code has some bugs.
> Are there any harmful point in this code or a better code ?
> If you are aware of , I would be extremely appreciative for it.
[...code to talk to bootstrap agent...]
The code you posted will work, provided both the client and the Naming
service are omniORB. It is extremely non-standard. It stands no chance
of working with other ORBs. Once the interoperable naming service
specification is finalised, there will be a standard way to do this
(with much less code).
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Tue Dec 14 13:29:53 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 13:29:53 +0000
Subject: [omniORB] Conflict with other ORBs?
In-Reply-To: Your message of "Mon, 13 Dec 1999 16:45:16 PST."
Message-ID: <199912141329.NAA12605@pineapple.cam-orl.co.uk>
On Monday 13 December, Brent Fulgham wrote:
> I have the omniorb nameservice start up at boot time, and it runs in the
> background like any other service on my system.
>
> I have found that if I start the GNOME environment, however, that as soon
> as the gnome-orb starts up omniorb dies. I thought initially that it might
> be due to them fighting over the same port, but a quick check with `fuser`
> does not show this.
The ORBs should not be visible to each other unless they are
explicitly introduced by passing an IOR between them. Unless ORBit is
maliciously looking for and killing omniNames, it should never see
it. Maybe you could try running omniNames in a console, rather than in
the background, to see if it prints anything meaningful when it dies.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Tue Dec 14 14:04:16 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 14:04:16 +0000
Subject: [omniORB] python and scheme
In-Reply-To: Your message of "Tue, 14 Dec 1999 00:35:45 EST."
<000501bf45f5$14467890$0a0a0a0a@cradle>
Message-ID: <199912141404.OAA12880@pineapple.cam-orl.co.uk>
On Tuesday 14 December, "Ji-Yong D. Chung" wrote:
> I wish, though, you guys developed a language binding for "Scheme" (a
> dialect of lisp) rather than python. Python is really mutated Scheme. And
> as such, Scheme interpreters, provide all the features of python
> interpreters, but with better syntax.
I'd dispute the fact that Python is mutated Scheme. The programming
paradigms are completely different. That's not to say that Python is
more or less useful than Scheme -- some things are best written in a
language like Python, others are best written in a language like
Scheme.
You're welcome to propose a CORBA Scheme mapping, and implement it for
omniORB. We'll add it to our distribution. :-)
In the mean time, ILU from Xerox PARC supports Common Lisp and Guile.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From David.Chung@USPTO.GOV Tue Dec 14 14:16:48 1999
From: David.Chung@USPTO.GOV (Chung, David)
Date: Tue, 14 Dec 1999 09:16:48 -0500
Subject: [omniORB] Using Compare and Swap for 2.8 and 3.0?
Message-ID: <966B307EF37DD311A3B1002048400F1B87C95D@uspto-is-104.uspto.gov>
In email archives, I saw several messages regarding one-time memory
allocation for synchronization objects that are never cleaned up (as they
are needed for orderly shutdown). The objects manifests as memory leaks on
both omniORB 3.0 and 2.8
Perhaps the thing to do here is not to leave this "feature" alone,
but to fix it using more "primitive" synchronization calls, such as compare
and swap (CAS) or Bit Test and Set (BTS). Using these will eliminate the
need to create mutexe/semaphore objects that need to stay around.
Unfortunately, CAS and BTS are not uniformly implemented on
different platforms, so to do this right, you will need to create proper
platform abstraction layer (or wrapper functions). Some would argue that
implementing these are more trouble than they are worth; but then, the same
argument can be made for staying with all kludges, which tend to be good
only as short term solutions.
From Brecht.Vermeulen@rug.ac.be Tue Dec 14 15:06:30 1999
From: Brecht.Vermeulen@rug.ac.be (Brecht Vermeulen)
Date: Tue, 14 Dec 1999 16:06:30 +0100 (MET)
Subject: [omniORB] Naming Server Crash
Message-ID:
Hello,
We've found a bug in the omniNames implementation we think. (sorry, I've
got no time to search the archives, because I don't see it as a big
problem for us now, sorry if it's already mentioned or solved in the newer
versions).
It's with the 2.8.0 version (Linux debian 2.1). If you take the eg3
example and you change in the client
orb->resolve_initial_references("NameService")
by (thus a typo :-) )
orb->resolve_initial_references("NamyService")
then the naming service blocks on next calls. Ideal for denial of service
attacks !
yours sincerely,
Brecht Vermeulen
ATLANTIS IP-ATM testlab
University of Ghent
From dgrisby@uk.research.att.com Tue Dec 14 15:27:23 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 14 Dec 1999 15:27:23 +0000
Subject: [omniORB] Naming Server Crash
In-Reply-To: Your message of "Tue, 14 Dec 1999 16:06:30 +0100."
Message-ID: <199912141527.PAA13800@pineapple.cam-orl.co.uk>
On Tuesday 14 December, Brecht Vermeulen wrote:
> It's with the 2.8.0 version (Linux debian 2.1). If you take the eg3
> example and you change in the client
> orb->resolve_initial_references("NameService")
> by (thus a typo :-) )
> orb->resolve_initial_references("NamyService")
> then the naming service blocks on next calls. Ideal for denial of service
> attacks !
This is sort of a bug. It only arises if omniNames has been started
with -ORBInitialHost and -ORBInitialPort. In that case, it deadlocks
trying to resolve initial references with itself. The workaround for
now is to start omniNames without the ORBInitialHost/Port.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From barbara.mathae@sdm.de Tue Dec 14 18:05:00 1999
From: barbara.mathae@sdm.de (barbara.mathae@sdm.de)
Date: Tue, 14 Dec 1999 19:05:00 +0100
Subject: [omniORB] chrash with MSC++5.0
Message-ID:
Here is the message without the zip file. I hope the listet parts of =
the
source code are enough to get a notion of the problem!
Barbara
> ----------
> From: Math=E4, Barbara
> Sent: Tuesday, December 14, 1999 4:59 PM
> To: 'omniorb-list@uk.research.att.com'
> Subject: chrash with MSC++5.0=20
>=20
> Hello Omniorber's:
>=20
> I run omniorb (2.8) on Windows Nt40. I am using Visual Studio C++ =
5.0. I
> can establish a connection and send data from one side to the other =
and
> vice versa. But when trying to send the following data (see also the
> attached zip file) a crash occurs. HEAP[try50.exe]: Invalid Address
> specified to RtlValidateHeap
> the crash occurs in:
>=20
> operator delete(void * 0x00a07b60) line 49 + 16 bytes
> _CORBA_String_member::~_CORBA_String_member()=20
>=20
> as I can see from the call stack.=20
>=20
> // the idl file
> oneway void putResult(in ImageDecodingResult result);
>=20
> struct ImageDecodingResult {
> ImageId id;
> DecodingResult result;
> };
>=20
> const long IMAGEIDSIZE =3D 32;=20
> typedef sequence ImageId;
>=20
> struct DecodingResult {
> CodingDepth curCodingDepth;
> unsigned long rejectReason;
> unsigned long confLevelDc;
> DistribCode dc;
> unsigned long addInfo;
> AddrElementList elements;
> };
>=20
> struct AddrElement {
> ElementType type;
> unsigned long confLevelNominal;
> unsigned long confLevelReference;
> string<63> nominalElement;
> string<63> referenceElement;
> };
>=20
> typedef sequence AddrElementList;
>=20
> enum CodingDepth { UnknownCodingDepth,=09
> NoCodDepth, =09
> AoiCodDepth, =09
> OutwardCodDepth,=09
> InwardCodDepth,=09
> SequencingCodDepth=09
> };
>=20
> //
>=20
> // a part of the source Code:
>=20
> Imm_var myImm =3D Imm::_narrow(obj);
> =20
> ImageDecodingResult *vdecodingResult =3D new =
ImageDecodingResult();
> // Struktur aufbauen
> vdecodingResult->id.length(1);=20
> vdecodingResult->id[0] =3D 1;
> vdecodingResult->result.curCodingDepth =3D UnknownCodingDepth;
> vdecodingResult->result.rejectReason =3D 0;
> vdecodingResult->result.confLevelDc =3D 0;
> vdecodingResult->result.dc =3D strdup("Test");
> vdecodingResult->result.addInfo =3D 0;
> vdecodingResult->result.elements.length(1);
> vdecodingResult->result.elements[0].type =3D CountryElement;
> vdecodingResult->result.elements[0].confLevelNominal =3D 1;
> vdecodingResult->result.elements[0].confLevelReference =3D 2;
> vdecodingResult->result.elements[0].nominalElement =3D =
strdup("Addr");
> vdecodingResult->result.elements[0].referenceElement =3D =
strdup("Hallo");
> =20
> myImm->putResult( *vdecodingResult );=20
> // =20
>=20
> I have no idea why this happens. I also used the CORBA::string_dup =
for
> copying strings, but the same crash occurs.=20
> I tried the use of CORBA::string_dup standalone. I can transfer a =
string
> only when using strdup instead of CORBA::string_dup!
>=20
> In the attachement you will find the idls and the source code (as a =
zip
> file). =20
> The object implementation you will find in the folder gegenpart. This =
is
> only a quick "hack" to test the transfer of the data I have =
difficulties
> with.=20
>=20
> I am using CORBA for the first time, therefore I am not sure whether =
the
> C++ binding I used is ok. Thank you for every comment or advice in =
this
> case.=20
>=20
> Barbara=20
>=20
From gtrudel@mediatrix.com Tue Dec 14 18:27:56 1999
From: gtrudel@mediatrix.com (Guy Trudel)
Date: Tue, 14 Dec 1999 13:27:56 -0500
Subject: [omniORB] chrash with MSC++5.0
Message-ID: <80E2FF0AC64DD311AC3700E02910AE0A136987@INTERNAL>
Instead of using strdup, try this instead (I think it should work)
decodingResult->result.dc = (const char*)"Test";
doing this it will call
_CORBA_String_member& operator= (const char* s)
which will make the copy.
The need to cast "Test" as (const char*)is because by default string
litteral are char* (and not const char*) with msvc compiler.
Guy Trudel
From chapmanb@arches.uga.edu Tue Dec 14 19:37:02 1999
From: chapmanb@arches.uga.edu (Brad Chapman)
Date: Tue, 14 Dec 1999 14:37:02 -0500
Subject: [omniORB] FreeBSD and omniORBpy
In-Reply-To: <199912141041.KAA12185@pineapple.cam-orl.co.uk>
References: Your message of "Fri, 10 Dec 1999 16:39:43 EST."
Message-ID:
Thanks for getting back with me regarding this!
Duncan Grisby wrote:
>> 1. I uncommented the relevant parts at the end to get static linking
>> (I didn't want to do this, but I couldn't get it to build
>> otherwise).
>
>What problems did you have with dynamic linking? I'd be surprised if
>you can successfully build omniORBpy without working dynamic linking.
>
The lines at the end of the x86_freebsd_3.2.mk makefile, according to the
comments, cause "utils and examples build in this tree to [be] statically
linked with the omniORB libraries." So if I leave these four lines
commented, the compile will proceed okay until I get to the omniNames
directory, when I will get the following error:
-----------------------------------------------------------------------
gmake[2]: Entering directory `/usr/local/omniORB/src/appl/omniNames'
+ rm -f omniNames
+ g++295 -pthread -s -o omniNames -O2 -Wall -Wno-unused
-L../../../lib/x86_freebsd_3.2 omniNames.o NamingContext_i.o log.o
omniNames.o: In function `main':
omniNames.o(.text+0x433): undefined reference to `CORBA::ORB_init(int &,
char **, char const *)'
omniNames.o(.text+0x44a): undefined reference to `CORBA::ORB::BOA_init(int
&, char **, char const *)'
omniNames.o(.text+0x45d): undefined reference to
`CORBA::BOA::impl_is_ready(CORBA::ImplementationDef *, bool)'
omniNames.o(.text+0x4bb): undefined reference to `omni_mutex::omni_mutex(void)'
[...snip a whole lot of pages of this sort of complaining...]
-------------------------------------------------------------------------
However, when the 4 lines at the bottom of the makefile are uncommented,
everything proceeds without a problem.
>
>Why did you manually build the stubs rather than letting the makefiles
>do it?
>
The makefiles didn't build the stubs first. If I don't manually run
omniidl2, the compile with complain about missing echo.hh files.
>
>The link line doesn't link with echoSK.o, which is why you got lots of
>errors about undefined references. I don't know why the make files
>aren't doing the right thing.
I updated to the most recent gmake I could (3.78.1) but still had the same
issues. Any suggestions about anything I could try? :)
>
>You need to edit cccp/config.h to add a FreeBSD configuration file. It
>will probably be the same as config-linux.h.
>
That was exactly the problem. I added config-freebsd.h (just a copy of
config_linux.h) and edited the config.h main file and everything built
without a problem. The catch--I'm having problems once again dealing with
the examples. When I try to run omniidl on the echo_example.idl to generate
the stubs I get the following:
$ omniidl echo.idl
Traceback (innermost last):
File "/usr/local/omniORB/bin/scripts/omniidl", line 30, in ?
import omniidl.main
File "/usr/local/omniORB/lib/python/omniidl/main.py", line 66, in ?
import _omniidl
ImportError: No module named _omniidl
Similary, if I just try to start up the server without generating stubs:
$ ./echo_example_srv.py &
[2] 29419
insomniac# Traceback (innermost last):
File "./echo_example_srv.py", line 4, in ?
from omniORB import CORBA, PortableServer
File "/usr/local/omniORB/lib/python/omniORB/__init__.py", line 88, in ?
import _omnipy
ImportError: No module named _omnipy
I have PYTHONPATH, LD_LIBRARY_PATH and regular ol' PATH set according to
the omniORBpy readme and the README.unix.
Sorry for the continual problems. Any advice anyone could give
would be greatly appreciated. Meanwhile I'm keep messing around!
Brad
chapmanb@arches.uga.edu
From SLatham@acdnj.itt.com Tue Dec 14 19:47:06 1999
From: SLatham@acdnj.itt.com (Latham, Steve)
Date: Tue, 14 Dec 1999 14:47:06 -0500
Subject: [omniORB] omniORB WARNING: - Proxy Object not Released
Message-ID:
Hi, I'm using a port of the omniORB pre 2.80 on linux/strongARM and I
compiled the orb with the static flag. When my client completes its calls it
hangs with the warning (twice) omniORB:WARNING - Proxy Object not Released.
Anything I can do? - I've tried various methods such as exit() etc to force
an exit but I end up having to use cntrl-c to kill it.
Steve
From seefelds@MAGELLAN.UMontreal.CA Tue Dec 14 20:00:12 1999
From: seefelds@MAGELLAN.UMontreal.CA (Stefan Seefeld)
Date: Tue, 14 Dec 1999 20:00:12 +0000
Subject: [omniORB] omniORB WARNING: - Proxy Object not Released
References:
Message-ID: <3856A1CC.BB4356F8@magellan.umontreal.ca>
"Latham, Steve" wrote:
>
> Hi, I'm using a port of the omniORB pre 2.80 on linux/strongARM and I
> compiled the orb with the static flag. When my client completes its calls it
> hangs with the warning (twice) omniORB:WARNING - Proxy Object not Released.
> Anything I can do? - I've tried various methods such as exit() etc to force
> an exit but I end up having to use cntrl-c to kill it.
you probably missed some CORBA::release calls from within your code.
Using var types instead of ptr types will help avoiding such pitfalls.
May be the ORB is not exiting 'cause he thinks therte might still be pending
requests for that object (proxy).
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
From David.Chung@USPTO.GOV Tue Dec 14 20:13:35 1999
From: David.Chung@USPTO.GOV (Chung, David)
Date: Tue, 14 Dec 1999 15:13:35 -0500
Subject: [omniORB] scheme
Message-ID: <966B307EF37DD311A3B1002048400F1B87C962@uspto-is-104.uspto.gov>
(1) I am just curious to how long did it take you to write python
ORB and the IDL compiler? I'd assume that most efforts were spent on
writing the ORBpy, right?
(2) Is there a plan to implement a CosTransaction service? With
recovery, and other good stuff (that is not par of CORBA spec).
P.S.
There are more similarities than meets the eye between Scheme and
python. See http://www.python.org/doc/pythonVSscheme.html
From brent.fulgham@xpsystems.com Tue Dec 14 22:27:11 1999
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Tue, 14 Dec 1999 14:27:11 -0800
Subject: [omniORB] Naming Server Crash
Message-ID:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BF4682.5D3507B4
Content-Type: text/plain;
charset="iso-8859-1"
> > It's with the 2.8.0 version (Linux debian 2.1). If you take the eg3
> > example and you change in the client
> > orb->resolve_initial_references("NameService")
> > by (thus a typo :-) )
> > orb->resolve_initial_references("NamyService")
> > then the naming service blocks on next calls. Ideal for
> denial of service
> > attacks !
>
> This is sort of a bug. It only arises if omniNames has been started
> with -ORBInitialHost and -ORBInitialPort. In that case, it deadlocks
> trying to resolve initial references with itself. The workaround for
> now is to start omniNames without the ORBInitialHost/Port.
>
Would this also occur with an /etc/omniorb.cfg such as:
host blah
port 8088
Or is it only if these are passed on the command line?
-Brent
------_=_NextPart_001_01BF4682.5D3507B4
Content-Type: text/html;
charset="iso-8859-1"
RE: [omniORB] Naming Server Crash
> > It's with the 2.8.0 version (Linux debian 2.1). If you take the eg3
> > example and you change in the client
> > orb->resolve_initial_references("NameService")
> > by (thus a typo :-) )
> > orb->resolve_initial_references("NamyService")
> > then the naming service blocks on next calls. Ideal for
> denial of service
> > attacks !
>
> This is sort of a bug. It only arises if omniNames has been started
> with -ORBInitialHost and -ORBInitialPort. In that case, it deadlocks
> trying to resolve initial references with itself. The workaround for
> now is to start omniNames without the ORBInitialHost/Port.
>
Would this also occur with an /etc/omniorb.cfg such as:
host blah
port 8088
Or is it only if these are passed on the command line?
-Brent
------_=_NextPart_001_01BF4682.5D3507B4--
From mdb@jimi.nwest.mccaw.com Wed Dec 15 06:08:24 1999
From: mdb@jimi.nwest.mccaw.com (Mark Borges)
Date: 14 Dec 1999 22:08:24 -0800
Subject: [omniORB] omniORBpy: segfault/bus errors using Any?
Message-ID:
I'm not sure if this is an obscure compiler/optimization bug, a
misunderstanding of the Python mapping for Any on my part, or
something else entirely different.
Running the following snippet of code (which is boiled down from a
larger application and basically nonsensical as-is) I consistently get
a segmentation fault:
-----------------------------------------------------------------------
$ ./srv.py &
IOR:000000000000001049444c3a592f5265706c793a312e300000000001000000000000002c000100000000000f3134312e3230342e3137382e3638000299e100000000000c38572cf3a7abb22b00000002
$ ./clt.py
xx= PENDING
typecode=
{'dueDate': '01/01/2000', 'woState': PENDING, 'woId': '12345'}
zsh: 16940 segmentation fault (core dumped) ./clt.py
-----------------------------------------------------------------------
Can anyone verify if this is reproducible elsewhere, or if I should
focus more on the local installation of omniORBpy and the specific
build I'm using on this OS:
$ gcc -dumpversion -dumpmachine
2.95.2
$ gcc -dumpmachine
sparc-sun-solaris2.6
$ uname -a
SunOS jimi 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-5_10
Or if I've done something boneheaded in the appended code?
-----------------------------------------------------------------------
$ cat Y.idl
module Y {
enum jobState {
PENDING,
COMPLETED
};
struct Foo {
string woId;
jobState woState;
string dueDate;
};
interface Reply {
oneway void result (in unsigned long id,
in boolean success,
in any data);
}; //end of interface
}; // end of module
-----------------------------------------------------------------------
$ cat srv.py
#!/usr/bin/env python
import sys
from omniORB import CORBA, PortableServer
# Import the skeletons
import POA_Y
# Initialise the ORB
orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
# Find the POA
poa = orb.resolve_initial_references("RootPOA")
# Activate the POA
poaManager = poa._get_the_POAManager()
poaManager.activate()
class PushMe_i (POA_Y.Reply):
def result(self, id,ok,data):
print "result() called"
print "id=",id
print "ok code=",ok
print data.typecode()
print data.value().woId
print data.value().woState
# Create an instance of it
ei = PushMe_i()
# Create an object reference, and implicitly activate the object
eo = ei._this()
# Print out the IOR
ior = orb.object_to_string(eo)
print ior
# Stash it in a file
open('srv.ior', 'w').write(ior)
# Everything is running now, but if this thread drops out of the end
# of the file, the process will exit. orb.run() just blocks for ever
orb.run()
-----------------------------------------------------------------------
$ cat clt.py
#!/usr/bin/env python
import sys
# Import the CORBA module
from omniORB import CORBA
# Import the stubs
import Y
# Initialise the ORB
orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
# Read the server's stringified IOR from a file.
my_ior = open('srv.ior', 'r').read()
# Convert the IOR to an object reference
object = orb.string_to_object(my_ior)
xx=Y.PENDING
print 'xx=',xx
c = Y.Foo('12345',Y.PENDING,'01/01/2000')
# Now create the "Any".
tc = CORBA.TypeCode('IDL:Y/Foo:1.0')
print "typecode=",tc
# -----------------------------------------------------------------------
aa = CORBA.Any(tc, c)
print aa.typecode
print aa.value().__dict__
id = 3
success = 1
object.result(id,success,aa)
print "oneway push done"
From johannes@ees2.oulu.fi Wed Dec 15 07:27:47 1999
From: johannes@ees2.oulu.fi (Janne Haverinen)
Date: Wed, 15 Dec 1999 09:27:47 +0200
Subject: [omniORB] omniidl3 problem?
Message-ID: <385742F3.7C9D16EE@ee.oulu.fi>
Hi,
I get compilation errors when using following interface (only relevant
parts shown):
interface BMC {
...
struct State
{
float fX;
float fY;
float fZ;
};
...
attribute State Rotation;
attribute State Translation;
};
Here is one error:
../../../..//stub/BMCSK.cc:432: parse error before `&'
../../../..//stub/BMCSK.cc:433: prototype for `void
_objref_BMC::Rotation(...)' does not match any in class `_objref_BMC'
../../../../stub/BMC.hh:187: candidates are: void
_objref_BMC::Rotation(const struct BMC::State &)
../../../..//stub/BMCSK.cc:414: struct BMC::State
_objref_BMC::Rotation()
This is the prototype from BMCSK.cc:
void _objref_BMC::Rotation(const State& arg_0)
{
_0RL_cd_697bfb3c3ca689ef_60000000
_call_desc(_0RL_lcfn_697bfb3c3ca689ef_80000000, "_set_Rotation", 14, 0,
arg_0);
_invoke(_call_desc);
}
And here is the canditate from BMC.hh:
class _objref_BMC :
public virtual CORBA::Object, public virtual omniObjRef
{
public:
...
BMC::State Rotation();
void Rotation(const BMC::State&);
BMC::State Translation();
void Translation(const BMC::State&);
...
Is this a omniidl3 problem or am I doing something wrong?
// Janne Haverinen
From afo@numlock.org Wed Dec 15 08:29:37 1999
From: afo@numlock.org (afo@numlock.org)
Date: Wed, 15 Dec 1999 09:29:37 +0100
Subject: [omniORB] FreeBSD and omniORBpy
In-Reply-To: from "Brad Chapman" at Dec 14, 1999 02:37:02 PM
Message-ID: <19991215082937.26185.qmail@big.muc.de>
Brad Chapman wrote:
>
>
>That was exactly the problem. I added config-freebsd.h (just a copy of
>config_linux.h) and edited the config.h main file and everything built
>without a problem. The catch--I'm having problems once again dealing with
>the examples. When I try to run omniidl on the echo_example.idl to generate
>the stubs I get the following:
>
>$ omniidl echo.idl
>Traceback (innermost last):
> File "/usr/local/omniORB/bin/scripts/omniidl", line 30, in ?
> import omniidl.main
> File "/usr/local/omniORB/lib/python/omniidl/main.py", line 66, in ?
> import _omniidl
>ImportError: No module named _omniidl
>
>Similary, if I just try to start up the server without generating stubs:
>
>$ ./echo_example_srv.py &
>[2] 29419
>insomniac# Traceback (innermost last):
> File "./echo_example_srv.py", line 4, in ?
> from omniORB import CORBA, PortableServer
> File "/usr/local/omniORB/lib/python/omniORB/__init__.py", line 88, in ?
> import _omnipy
>ImportError: No module named _omnipy
>
>I have PYTHONPATH, LD_LIBRARY_PATH and regular ol' PATH set according to
>the omniORBpy readme and the README.unix.
> Sorry for the continual problems. Any advice anyone could give
>would be greatly appreciated. Meanwhile I'm keep messing around!
due to missing FreeBSD sections in
omniORB-2.8.0/src/lib/omniORBpy/omniidl/cxx/dir.mk
and
omniORB-2.8.0/src/lib/omniORBpy/modules/omnipy/dir.mk
neither the _omnipymodule.so nor _omniidlmodule.so native modules
for python were created
after applying the following 2 patches i finally managed to get omniORBpy
working on FreeBSD (3.3-RELEASE,omniORB 2.8.0,omniORBpy 19991214)
at least the echo_example sample runs:
--- tmp/omniORB-2.8.0/src/lib/omniORBpy/modules/omnipy/dir.mk Thu Nov 25 12:49
:32 1999
+++ omniORB-2.8.0/src/lib/omniORBpy/modules/omnipy/dir.mk Wed Dec 15 02:31
:12 1999
@@ -65,6 +65,41 @@
)
endif
+#############################################################################
+# Make rules for FreeBSD #
+#############################################################################
+
+ifdef FreeBSD
+
+CXXOPTIONS += -fPIC
+
+libname = _omnipymodule.so
+soname = $(libname).$(OMNIPY_MAJOR)
+lib = $(soname).$(OMNIPY_MINOR)
+
+$(lib): $(OBJS)
+ (set -x; \
+ $(RM) $@; \
+ $(CXXLINK) $(CXXLINKOPTIONS) -shared -o $@ -Wl,-soname,$(soname) $(IMPOR
T_LIBRARY_FLAGS) $(OMNIORB2_LIB_NODYN_DEPEND)\
+ $(filter-out $(LibSuffixPattern),$^) $(OMNIORB2_LIB)\
+ )
+
+all:: $(lib)
+
+clean::
+ $(RM) $(lib)
+
+export:: $(lib)
+ @$(ExportLibrary)
+ @(set -x; \
+ cd $(EXPORT_TREE)/$(LIBDIR); \
+ $(RM) $(soname); \
+ ln -s $(lib) $(soname); \
+ $(RM) $(libname); \
+ ln -s $(soname) $(libname); \
+ )
+endif
+
#############################################################################
# Make rules for Solaris 2.x #
--- tmp/omniORB-2.8.0/src/lib/omniORBpy/omniidl/cxx/dir.mk Wed Dec 1 12:35
:22 1999
+++ omniORB-2.8.0/src/lib/omniORBpy/omniidl/cxx/dir.mk Wed Dec 15 03:15:41 1999
@@ -87,6 +87,42 @@
endif
+#############################################################################
+# Make rules for FreeBSD #
+#############################################################################
+
+ifdef FreeBSD
+
+CXXOPTIONS += -fPIC
+
+libname = _omniidlmodule.so
+soname = $(libname).$(IDLMODULE_MAJOR)
+lib = $(soname).$(IDLMODULE_MINOR)
+
+all:: $(lib)
+
+$(lib): $(OBJS) $(PYOBJS)
+ (set -x; \
+ $(RM) $@; \
+ $(CXXLINK) $(CXXLINKOPTIONS) -shared -o $@ -Wl,-soname,$(soname) $(IMPOR
T_LIBRARY_FLAGS) \
+ $(filter-out $(LibSuffixPattern),$^) $(LIBS)\
+ )
+
+export:: $(lib)
+ @$(ExportLibrary)
+ @(set -x; \
+ cd $(EXPORT_TREE)/$(LIBDIR); \
+ $(RM) $(soname); \
+ ln -s $(lib) $(soname); \
+ $(RM) $(libname); \
+ ln -s $(soname) $(libname); \
+ )
+
+clean::
+ $(RM) $(lib)
+
+endif
+
#############################################################################
# Make rules for Solaris 2.x #
-------- end diff --------------------------------------------------------
anybody knows why i get the following error for an make export
in omniORBpy ?
make[5]: *** No rule to make target ie.py', needed by xport'. Stop.
make[5]: Leaving directory /home/GLOBAL/src/omniORB-2.8.0/src/lib/omniORBpy/omni
idl/python/be/cxx/header'
after commenting out the the rule for tie.py in dir.mk the make export runs fine
ps: duncan can you please change in config/config.mk line 67
from
#platform = i386_freebsd_3.2
into
#platform = x86_freebsd_3.2
thank you
--
// Andre Fornacon
// afo zlug org
// hardware lebt und ist boese ...
From dgrisby@uk.research.att.com Wed Dec 15 10:23:25 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 15 Dec 1999 10:23:25 +0000
Subject: [omniORB] scheme
In-Reply-To: Your message of "Tue, 14 Dec 1999 15:13:35 EST."
<966B307EF37DD311A3B1002048400F1B87C962@uspto-is-104.uspto.gov>
Message-ID: <199912151023.KAA16760@pineapple.cam-orl.co.uk>
On Tuesday 14 December, "Chung, David" wrote:
> (1) I am just curious to how long did it take you to write python
> ORB and the IDL compiler? I'd assume that most efforts were spent on
> writing the ORBpy, right?
It didn't take too long to write the Python ORB itself -- three or
four months I suppose. Most of the time I spent on the IDL compiler
was writing the new front end. Now that's done, writing back-ends is
pretty easy.
> (2) Is there a plan to implement a CosTransaction service? With
> recovery, and other good stuff (that is not par of CORBA spec).
We have no plans to do a transaction service ourselves, but there is
one commercial one available for omniORB. See:
http://www.uk.research.att.com/omniORB/contribapp.html#OTSArjuna
> P.S.
> There are more similarities than meets the eye between Scheme and
> python. See http://www.python.org/doc/pythonVSscheme.html
That reads to me as saying that they're significantly different. It's
true that to a large extent you can use either language as if it was
the other, but I think that rather perverts the intent of both
languages.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From djr@uk.research.att.com Wed Dec 15 10:21:20 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Wed, 15 Dec 1999 10:21:20 +0000 (GMT)
Subject: [omniORB] omniidl3 problem?
In-Reply-To: <385742F3.7C9D16EE@ee.oulu.fi>
Message-ID:
Hi Janne,
I have just compiled this IDL, and the resulting c++ code without
problems. Do you get this problem if your IDL file contains only the IDL
you have given here?
David
On Wed, 15 Dec 1999, Janne Haverinen wrote:
> Hi,
>
> I get compilation errors when using following interface (only relevant
> parts shown):
>
> interface BMC {
>
> ...
>
> struct State
> {
> float fX;
> float fY;
> float fZ;
> };
>
> ...
>
> attribute State Rotation;
> attribute State Translation;
>
> };
From dgrisby@uk.research.att.com Wed Dec 15 10:56:50 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 15 Dec 1999 10:56:50 +0000
Subject: [omniORB] omniORBpy: segfault/bus errors using Any?
In-Reply-To: Your message of "14 Dec 1999 22:08:24 PST."
Message-ID: <199912151056.KAA18705@pineapple.cam-orl.co.uk>
On Tuesday 14 December, Mark Borges wrote:
> I'm not sure if this is an obscure compiler/optimization bug, a
> misunderstanding of the Python mapping for Any on my part, or
> something else entirely different.
It's an omniORBpy bug! Here's a patch. It will appear in CVS
overnight.
Cheers,
Duncan.
RCS file: /project/omni/cvsroot/omniORBpy/modules/omnipy/pyTypeCode.cc,v
retrieving revision 1.5
diff -u -r1.5 pyTypeCode.cc
--- pyTypeCode.cc 1999/09/24 09:22:02 1.5
+++ pyTypeCode.cc 1999/12/15 10:51:48
@@ -371,7 +371,7 @@
PyObject* mems = PyTuple_GET_ITEM(d_o, 3); assert(PyTuple_Check(mems));
PyObject* mem;
- int cnt = PyTuple_GET_SIZE(t_o);
+ int cnt = PyTuple_GET_SIZE(mems);
for (int i=0; i
Message-ID: <199912151103.LAA18749@pineapple.cam-orl.co.uk>
On Tuesday 14 December, Brent Fulgham wrote:
[...deadlock in omniNames...]
> Would this also occur with an /etc/omniorb.cfg such as:
>
> host blah
> port 8088
Yes. You can easily point omniNames to a different config file by
setting the OMNIORB_CONFIG environment variable. omniNames doesn't
need to know the host and port of the Naming service of course...
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Wed Dec 15 11:18:52 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 15 Dec 1999 11:18:52 +0000
Subject: [omniORB] FreeBSD and omniORBpy
In-Reply-To: Your message of "Wed, 15 Dec 1999 09:29:37 +0100."
<19991215082937.26185.qmail@big.muc.de>
Message-ID: <199912151118.LAA18830@pineapple.cam-orl.co.uk>
On Wednesday 15 December, afo@numlock.org wrote:
> due to missing FreeBSD sections in
> omniORB-2.8.0/src/lib/omniORBpy/omniidl/cxx/dir.mk
> and
> omniORB-2.8.0/src/lib/omniORBpy/modules/omnipy/dir.mk
>
> neither the _omnipymodule.so nor _omniidlmodule.so native modules
> for python were created
Thanks for your make rule contributions. They will appear in CVS
overnight.
> anybody knows why i get the following error for an make export
> in omniORBpy ?
>
> make[5]: *** No rule to make target ie.py', needed by xport'. Stop.
> make[5]: Leaving directory /home/GLOBAL/src/omniORB-2.8.0/src/lib/omniORBpy/omni
> idl/python/be/cxx/header'
>
> after commenting out the the rule for tie.py in dir.mk the make
> export runs fine
tie.py appears to be in the CVS repository now. I guess you managed to
check it out when dir.mk had been updated by tie.py hadn't been added.
As you might have guessed, all the files in be/cxx are
work-in-progress towards the new back-end for omniORB 3. You can
safely ignore it.
> ps: duncan can you please change in config/config.mk line 67
> from
> #platform = i386_freebsd_3.2
> into
> #platform = x86_freebsd_3.2
Will do.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Wed Dec 15 11:22:06 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 15 Dec 1999 11:22:06 +0000
Subject: [omniORB] FreeBSD and omniORBpy
In-Reply-To: Your message of "Tue, 14 Dec 1999 14:37:02 EST."
Message-ID: <199912151122.LAA18848@pineapple.cam-orl.co.uk>
On Tuesday 14 December, Brad Chapman wrote:
[...]
> gmake[2]: Entering directory `/usr/local/omniORB/src/appl/omniNames'
> + rm -f omniNames
> + g++295 -pthread -s -o omniNames -O2 -Wall -Wno-unused
> -L../../../lib/x86_freebsd_3.2 omniNames.o NamingContext_i.o log.o
> omniNames.o: In function `main':
> omniNames.o(.text+0x433): undefined reference to `CORBA::ORB_init(int &,
For some reason, the link command isn't including the omniORB
libraries.
[...]
> The makefiles didn't build the stubs first. If I don't manually run
> omniidl2, the compile with complain about missing echo.hh files.
The makefiles should automatically build the stubs. I think there must
be something broken about either your set-up or the platform file for
FreeBSD. I'm afraid that we don't have any FreeBSD machines here, so
it's very hard for me to help.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From AGONNE@acxiom.co.uk Wed Dec 15 14:19:21 1999
From: AGONNE@acxiom.co.uk (agonne - Andrew Gonnet)
Date: Wed, 15 Dec 1999 14:19:21 -0000
Subject: [omniORB] omniORB on Alpha NT
Message-ID:
Hello,
I want to compile version 2.8.0 to run on an Alpha NT 4.0 machine.
I've found a reference to this in "README.win32", the config/config.mk
setting "platform = alpha_nt_4.0" and the win32.mk/alpha_nt_4.0.mk files.
But this is all.
Is there any further information available, or can anyone tell me what to
do? The sentence under "Building omniORB2 from the source files" in
"README.win32" just says, "For alpha NT, the binary distribution is compiled
under Interix (OpenNT) posix subsystem".
Any help would be very appreciated.
Thanks,
Andrew Gonnet.
P.S. Happy Christmas to everyone on the list!
From brent.fulgham@xpsystems.com Wed Dec 15 17:24:41 1999
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Wed, 15 Dec 1999 09:24:41 -0800
Subject: [omniORB] Naming Server Crash
Message-ID:
> [...deadlock in omniNames...]
>
> > Would this also occur with an /etc/omniorb.cfg such as:
> >
> > host blah
> > port 8088
>
> Yes. You can easily point omniNames to a different config file by
> setting the OMNIORB_CONFIG environment variable. omniNames doesn't
^^^^^^^^^^^^^^^^^
> need to know the host and port of the Naming service of course...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
I'm not sure I follow. If I don't use this configuration file,
then I *must* assign a hostname and port at the command line,
don't I? How does the Nameserver know which port to listen on
otherwise?
-Brent
From dgrisby@uk.research.att.com Wed Dec 15 17:30:25 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Wed, 15 Dec 1999 17:30:25 +0000
Subject: [omniORB] Naming Server Crash
In-Reply-To: Your message of "Wed, 15 Dec 1999 09:24:41 PST."
Message-ID: <199912151730.RAA22065@pineapple.cam-orl.co.uk>
On Wednesday 15 December, Brent Fulgham wrote:
> > Yes. You can easily point omniNames to a different config file by
> > setting the OMNIORB_CONFIG environment variable. omniNames doesn't
> ^^^^^^^^^^^^^^^^^
> > need to know the host and port of the Naming service of course...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> I'm not sure I follow. If I don't use this configuration file,
> then I *must* assign a hostname and port at the command line,
> don't I? How does the Nameserver know which port to listen on
> otherwise?
ORBInitialHost and ORBInitialPort tell clients of the Naming service
where the Naming service lives. omniNames does not use this mechanism
to decide where to put itself. It obviously knows the host, since it's
running on it; it gets the port number from -start or from the
omniNames log file.
HTH,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From r28558@email.sps.mot.com Thu Dec 16 03:14:19 1999
From: r28558@email.sps.mot.com (David Woodbury)
Date: Wed, 15 Dec 1999 20:14:19 -0700
Subject: [omniORB] oneway messaging question
Message-ID: <3858590B.BDE5F869@email.sps.mot.com>
Hi:
Does OmniOrb's oneway messaging support distribution/broadcast to
multiple concurrent subscribers? I'd try this out myself but am in a
holding pattern while my test system is upgraded with latest compiler.
Thanks!
Dave Woodbury
Motorola SPS
From dgrisby@uk.research.att.com Thu Dec 16 09:39:41 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Thu, 16 Dec 1999 09:39:41 +0000
Subject: [omniORB] oneway messaging question
In-Reply-To: Your message of "Wed, 15 Dec 1999 20:14:19 MST."
<3858590B.BDE5F869@email.sps.mot.com>
Message-ID: <199912160939.JAA24381@pineapple.cam-orl.co.uk>
On Wednesday 15 December, "David Woodbury" wrote:
> Does OmniOrb's oneway messaging support distribution/broadcast to
> multiple concurrent subscribers? I'd try this out myself but am in a
> holding pattern while my test system is upgraded with latest compiler.
No, and that's not what oneways are for. oneway just does a possibly
non-blocking, unreliable, call to a single server. In omniORB, oneways
are non-blocking unless you send so many that the TCP buffer fills up,
and almost always arrive. The only situation in which oneways are lost
is when the server-side closes the TCP connection while a oneway call
is in flight. Since there is no reply to a oneway, the ORB can't
detect this situation.
You can use oneway to make multiple concurrent calls to different
servers by just doing them one after the other, but that's nothing
like a broadcast / multicast. I guess what you want is an event
service which uses multicast to contact all subscribers. omniORB
doesn't have one of them.
HTH,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From brent.fulgham@xpsystems.com Thu Dec 16 19:42:30 1999
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Thu, 16 Dec 1999 11:42:30 -0800
Subject: [omniORB] Conflict with other ORBs?
Message-ID:
[ ... omniorb in the background seems to die when
GNOME is running ...]
>
> The ORBs should not be visible to each other unless they are
> explicitly introduced by passing an IOR between them. Unless ORBit is
> maliciously looking for and killing omniNames, it should never see
> it. Maybe you could try running omniNames in a console, rather than in
> the background, to see if it prints anything meaningful when it dies.
>
I tried this experiment, but it did not reveal too much. One interesting
note is that omniorb does not die when GNOME starts, or even once I've
accessed GNOME applications (running with Gnorba).
However, if I terminate X (CTRL-ALT-BACKSPACE) omniorb gets killed
along with everything running under X. I don't think this is the
only case where omniorb gets killed, because I have experienced
omniorb stopping even when I have not terminated X.
Could signals meant for Gnorba to instruct it to shut down somehow
get passed to OmniORB? There are no interesting messages printed
on the console...
-Brent
From seefelds@MAGELLAN.UMontreal.CA Fri Dec 17 16:35:47 1999
From: seefelds@MAGELLAN.UMontreal.CA (Stefan Seefeld)
Date: Fri, 17 Dec 1999 16:35:47 +0000
Subject: [omniORB] request: omniidl command line options
Message-ID: <385A6663.B6C6BAB5@magellan.umontreal.ca>
I'd like to propose the following two command line options
to make life easier:
* include a user defined header file on top of each generated
header. This could be extremely useful for config.h files
where all the system dependant #define's could be hidden in.
like: omniidl2 -c[onfig] config.hh Graphic.idl
* prefix all include statements for other auto generated headers
with a user defined directory to make it possible to output the
generated headers in a different location without the need of
endlessly long -I options
like: omniidl2 -p[refix] Warsaw Warsaw/Graphic.idl
Thanks, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
From sxthree@penfeld.tls.mms.fr Fri Dec 17 15:43:20 1999
From: sxthree@penfeld.tls.mms.fr (F. Michel)
Date: Fri, 17 Dec 1999 16:43:20 +0100
Subject: [omniORB] Introduction..
Message-ID: <385A5A17.5501FE96@penfeld.tls.mms.fr>
Hi omniORB users & developpers.
I'm new on this list, though I've been using omniORB
for a few months. My name is Francis Michel (the
email is not really explicit about this), working as
a SW engineer in Matra, Toulouse, south of France.
I'm currently using version 2.8.0 (last stable release) and
my job for now is to provide an "industrial" version of a
product that was initially developped with Iona's Orbix.
I had to make a few changes in the compiler in order to
compile the idls and have them work the way we expected
them to when using Orbix. I tried to introduce fonctionalities
without modifying the nominal behaviour using command line
options to omniidl2 and ifdefs in CORBA.h.
I'd like to know which of those patches may be integrated in
new releases and which may not. Some may have better
implementations, some may break OMG compliance.
Here is a list:
- RefCounting. For explicit object management we need to
know the refount of CORBA objects as well as our local objects.
omniObject only provides a private method for refCount retrieval.
Is there a reason why it couldn't be public (or at least protected) ?
- Naming service. Our product provides its own naming service
with an externalization method. It was initially developped using
OMG specification and now that all ORBs implement this service
we experience lots of name clashes. Well, I won't really agree with
this initial choice, but I have to deal with, so... Could it be possible
to
make omniORB naming service an optional feature ? (few ifdefs...)
- Keep include paths in generated stubs. This is a "nice to have"
feature. I've implemented a "-K" options which allows to keep
include paths and to remove given prefixes from the absolute paths.
- Skeleton generation. The purpose is to generate a dispatch method
inside the interface class rather than generating a skeleton class
for servers. This is a quite personal approach of the BOA but it allows
diamond inheritance between interfaces.
- CORBA::Environment. Orbix provides an additional parameter to
all distributed methods. We never use this parameter but it's in the
code. I've added an option to generate this parameter with default
values for operations and attribute access methods.
Of course each point should be given further explanations, this is just
an introduction.
=========================================================
Something different: I've noticed a problem with name lookup. An
identifier is now searched only in the first inherited level.
( An interface A defines an exception ex. B inherits from A and C
inherits from B. C defines a method which raises an ex. There, ex
is said not to be defined.)
This worked with omniidl2 V 2.7.1.
Is there a change in scoping policy ?
Thanks for any information about this.
salutations.
Nyny
From ceyhun_ozgun@hotmail.com Fri Dec 17 15:11:23 1999
From: ceyhun_ozgun@hotmail.com (Ceyhun ÖZGÜN)
Date: Fri, 17 Dec 1999 07:11:23 PST
Subject: [omniORB] If client deads method continues to run in server ?
Message-ID: <19991217151123.28443.qmail@hotmail.com>
Hi,
I have a question.
A client performs an operation on an object. While server method runs
a while, for example one or two hours, client programs terminates.
I wonder if OmniOrb delete the thread while runnig that long method.
Can OmniOrb distinguish that client terminated?.
I am using omniOrb 2.7. I am doing a long calculation taking hours. And if
client terminates server thread continues running without knowing that
client terminated.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From flynch@usa.net Fri Dec 17 17:29:29 1999
From: flynch@usa.net (flynch@usa.net)
Date: 17 Dec 1999 17:29:29 -0000
Subject: ?Re: [omniORB] Introduction..
Message-ID: <19991217172929.16010.qmail@host1.11net.com>
Some comments in-line...
>I'm currently using version 2.8.0 (last stable release) and
>my job for now is to provide an "industrial" version of a
>product that was initially developped with Iona's Orbix.
For "industrial" work I'd recommend a POA based ORB like omniORB3 or Orbix2000
>Here is a list:
>- RefCounting. For explicit object management we need to
>know the refount of CORBA objects as well as our local objects.
>omniObject only provides a private method for refCount retrieval.
>Is there a reason why it couldn't be public (or at least protected) ?
>
I agree 100% being able to get the refCount of a CORBA object is extremely usefull. (Even if it requires a non-standard API :-)
>- Naming service. Our product provides its own naming service
>with an externalization method. It was initially developped using
>OMG specification and now that all ORBs implement this service
>we experience lots of name clashes. Well, I won't really agree with
>this initial choice, but I have to deal with, so... Could it be possible
>to
>make omniORB naming service an optional feature ? (few ifdefs...)
AFAIK Using the omniORB naming service is optional, resolve_initial_references returns an object reference that you have specified (in a strinafied form) in the config file. So provided you have implemented a CORBA compliant namgin service (ie you implement CosNaming::NamingContext) this should not be an issue.
>- Skeleton generation. The purpose is to generate a dispatch method
>inside the interface class rather than generating a skeleton class
>for servers. This is a quite personal approach of the BOA but it allows
>diamond inheritance between interfaces.
I agree with this again, there is no point in having all the generated code linked with both clients and servers. FATWARE is not good. Splitting the client and server side generated code is a good thing.
>- CORBA::Environment. Orbix provides an additional parameter to
>all distributed methods. We never use this parameter but it's in the
>code. I've added an option to generate this parameter with default
>values for operations and attribute access methods.
This CORBA::Environment is used in Orbix to support compilers that do not have native C++ exceptions, and also for timeouts on operation calls.
This parameter has been dropped with Orbix2000, and I don't think that there is any reason that it should be added to omniORB.
BTW Orbix's use of this parameter *IS* CORBA compliant. The spec states that each method *may* take CORBA::Environment as a parameter. I suggest that you consider implementing a portability layer that would allow you to target several different ORB's.
Regards,
Frank
From dgrisby@uk.research.att.com Fri Dec 17 17:58:32 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Fri, 17 Dec 1999 17:58:32 +0000
Subject: [omniORB] Introduction..
In-Reply-To: Your message of "Fri, 17 Dec 1999 16:43:20 +0100."
<385A5A17.5501FE96@penfeld.tls.mms.fr>
Message-ID: <199912171758.RAA07308@pineapple.cam-orl.co.uk>
On Friday 17 December, "F. Michel" wrote:
> - Naming service. Our product provides its own naming service
> with an externalization method. It was initially developped using
> OMG specification and now that all ORBs implement this service
> we experience lots of name clashes. Well, I won't really agree with
> this initial choice, but I have to deal with, so... Could it be possible
> to
> make omniORB naming service an optional feature ? (few ifdefs...)
You don't have to use omniORB's Naming service if you don't want to.
> - Keep include paths in generated stubs. This is a "nice to have"
> feature. I've implemented a "-K" options which allows to keep
> include paths and to remove given prefixes from the absolute paths.
This is a potentially useful feature, but becomes less important if
you use a sensible makefile set-up. If you send us your patches, we'll
consider including them.
> - Skeleton generation. The purpose is to generate a dispatch method
> inside the interface class rather than generating a skeleton class
> for servers. This is a quite personal approach of the BOA but it allows
> diamond inheritance between interfaces.
I don't understand this. Can you explain more? There's nothing
preventing you using diamond inheritance with the current IDL compiler
is there?
> - CORBA::Environment. Orbix provides an additional parameter to
> all distributed methods. We never use this parameter but it's in the
> code. I've added an option to generate this parameter with default
> values for operations and attribute access methods.
The C++ mapping makes Environment an option if you don't have genuine
C++ exceptions. Its use isn't necessary with omniORB, and I think it
would be a backward step to provide an option to include it.
> Something different: I've noticed a problem with name lookup. An
> identifier is now searched only in the first inherited level.
> ( An interface A defines an exception ex. B inherits from A and C
> inherits from B. C defines a method which raises an ex. There, ex
> is said not to be defined.)
> This worked with omniidl2 V 2.7.1.
This is a bug which was introduced in fixing a similar bug :-(. The
fix will appear in CVS and FTP snapshots overnight.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From ceyhun_ozgun@hotmail.com Fri Dec 17 19:14:22 1999
From: ceyhun_ozgun@hotmail.com (Ceyhun ÖZGÜN)
Date: Fri, 17 Dec 1999 11:14:22 PST
Subject: [omniORB] Is not possible to invoke same method from different threads at client?
Message-ID: <19991217191422.53766.qmail@hotmail.com>
Hi,
I am using omniORB 2.7.1.
When one thread invokes a method and while it is running
other threads of client blocks.
I think these threads use same socket. And because server side of that
socket is busy, threads are blocking.
Any idea about this situation.
Thanks.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From dcmay@object-workshops.com Fri Dec 17 22:41:50 1999
From: dcmay@object-workshops.com (Dietmar May)
Date: Fri, 17 Dec 1999 17:41:50 -0500
Subject: [omniORB] omniidl3 problem?
Message-ID: <01BF489C.BEDCC260@host254.lan.wythe.naxs.com>
> ../../../..//stub/BMCSK.cc:432: parse error before `&'
This message looks like "State" is not being recognized.
> void _objref_BMC::Rotation(const State& arg_0)
> {
> ...
> }
Should this be
void _objref_BMC::Rotation(const BMC::State& arg_0)
instead of:
void _objref_BMC::Rotation(const /*missing namespace*/State& arg_0)
??
Dietmar
From djr@uk.research.att.com Sat Dec 18 13:18:46 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Sat, 18 Dec 1999 13:18:46 +0000 (GMT)
Subject: [omniORB] If client deads method continues to run in server ?
In-Reply-To: <19991217151123.28443.qmail@hotmail.com>
Message-ID:
On Fri, 17 Dec 1999, Ceyhun =D6ZG=DCN wrote:
> I have a question.
> A client performs an operation on an object. While server method runs
> a while, for example one or two hours, client programs terminates.
> I wonder if OmniOrb delete the thread while runnig that long method.
> Can OmniOrb distinguish that client terminated?.
No, there is no way omniORB can tell if a client has died during a call.
You could implement that yourself though. For example the client could
pass an object reference to the server, and the server would periodically
'ping' that object (in the client) to see if it is still alive.
Cheers,
David
From djr@uk.research.att.com Sat Dec 18 13:20:50 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Sat, 18 Dec 1999 13:20:50 +0000 (GMT)
Subject: [omniORB] Is not possible to invoke same method from different
threads at client?
In-Reply-To: <19991217191422.53766.qmail@hotmail.com>
Message-ID:
On Fri, 17 Dec 1999, Ceyhun =D6ZG=DCN wrote:
> I am using omniORB 2.7.1.
> When one thread invokes a method and while it is running
> other threads of client blocks.
> I think these threads use same socket. And because server side of that=20
> socket is busy, threads are blocking.
No -- omniORB will spawn multiple connections between a client and a
server to support multiple concurrent calls. Unless you are holding on to
some mutex in your server object implementation code, other clients should
not block.
David
From djr@uk.research.att.com Sat Dec 18 14:43:25 1999
From: djr@uk.research.att.com (David Riddoch)
Date: Sat, 18 Dec 1999 14:43:25 +0000 (GMT)
Subject: [omniORB] omniidl3 problem?
In-Reply-To: <01BF489C.BEDCC260@host254.lan.wythe.naxs.com>
Message-ID:
Hi
Ooops -- fixed this a few days ago and forgot to tell anyone!
As Dietmar says, it was a scoping problem for the argument to attribute
mutators.
Its in CVS.
David
On Fri, 17 Dec 1999, Dietmar May wrote:
> > ../../../..//stub/BMCSK.cc:432: parse error before `&'
>
> This message looks like "State" is not being recognized.
>
> > void _objref_BMC::Rotation(const State& arg_0)
> > {
> > ...
> > }
>
> Should this be
> void _objref_BMC::Rotation(const BMC::State& arg_0)
>
> instead of:
> void _objref_BMC::Rotation(const /*missing namespace*/State& arg_0)
>
> ??
> Dietmar
From dgrisby@uk.research.att.com Mon Dec 20 09:37:32 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 20 Dec 1999 09:37:32 +0000
Subject: [omniORB] Conflict with other ORBs?
In-Reply-To: Your message of "Thu, 16 Dec 1999 11:42:30 PST."
Message-ID: <199912200937.JAA02823@pineapple.cam-orl.co.uk>
On Thursday 16 December, Brent Fulgham wrote:
> [ ... omniorb in the background seems to die when
> GNOME is running ...]
> However, if I terminate X (CTRL-ALT-BACKSPACE) omniorb gets killed
> along with everything running under X. I don't think this is the
> only case where omniorb gets killed, because I have experienced
> omniorb stopping even when I have not terminated X.
Is this when omniNames is running in an Xterm? Or started from one
and running in the background? If not, killing X shouldn't have any
effect on omniNames.
> Could signals meant for Gnorba to instruct it to shut down somehow
> get passed to OmniORB? There are no interesting messages printed
> on the console...
I don't see how a signal for one process could cause another to die.
I suppose one obscure possibility is that your kernel is dodgy, and
randomly sends signals to incorrect processes. I would have thought
that you would see other things dying if that was the case.
Unless anyone else is seeing this problem, I can only assume that
there's something very strange about your set-up.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From dgrisby@uk.research.att.com Mon Dec 20 09:31:03 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 20 Dec 1999 09:31:03 +0000
Subject: [omniORB] Any Sun C++ 5.0 updates???
In-Reply-To: Your message of "Fri, 10 Dec 1999 01:54:38 EST."
<3850A3AE.E394AE4E@redconnect.net>
Message-ID: <199912200931.JAA02801@pineapple.cam-orl.co.uk>
On Friday 10 December, Alex Agranov wrote:
> Any news on this front? We're moving to production soon with the 5.0
> compiler (client choice, not ours) and the thing makes me feel real uneasy.
> I've applied the new libC patch (there's been a new one since the omni 2.8.0
> release notes) which is stated as fixing some exception handling snafus but
> it doesn't seem to have any effect. And yes, the compile times are
> flabbergasting...
omniORB 2.8.0 works OK with Sun's 5.0 compiler, but I believe you
still need to compile everything with -g, although you can have -O2
-g.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From sxthree@penfeld.tls.mms.fr Mon Dec 20 13:32:28 1999
From: sxthree@penfeld.tls.mms.fr (F. Michel)
Date: Mon, 20 Dec 1999 14:32:28 +0100
Subject: [omniORB] Introduction..
References: <199912171758.RAA07308@pineapple.cam-orl.co.uk>
Message-ID: <385E2FEB.FC72FBD2@penfeld.tls.mms.fr>
Duncan Grisby wrote:
> On Friday 17 December, "F. Michel" wrote:
>
> > - Naming service. Our product provides its own naming service
> > with an externalization method. It was initially developped using
> > OMG specification and now that all ORBs implement this service
> > we experience lots of name clashes. Well, I won't really agree with
> > this initial choice, but I have to deal with, so... Could it be possible
> > to
> > make omniORB naming service an optional feature ? (few ifdefs...)
>
> You don't have to use omniORB's Naming service if you don't want to.
Since, CosNaming::NamingContext is part of libomniORB2, we cannot mixit with
our implementation of this object. An additional compile flag
(NO_OMNI_NAMES for instance) gives us the behaviour we need with
really little changes to the source and does not impact the nominal
behaviour.
>
>
> > - Keep include paths in generated stubs. This is a "nice to have"
> > feature. I've implemented a "-K" options which allows to keep
> > include paths and to remove given prefixes from the absolute paths.
>
> This is a potentially useful feature, but becomes less important if
> you use a sensible makefile set-up. If you send us your patches, we'll
> consider including them.
The patch consists in maintaining a list of prefixes which may beremoved from
absolute paths. The functionality is implemented
in stripped_name in idl.ll. Instead of keeping only the last component
of the path, we remove the given prefix.
In what form do you expect patches, I can join diffs to my next mail.
>
>
> > - Skeleton generation. The purpose is to generate a dispatch method
> > inside the interface class rather than generating a skeleton class
> > for servers. This is a quite personal approach of the BOA but it allows
> > diamond inheritance between interfaces.
>
> I don't understand this. Can you explain more? There's nothing
> preventing you using diamond inheritance with the current IDL compiler
> is there?
Well, this is not a simple issue. I'm currently trying to isolate a
simplecase where the skel inheritance won't work. I'll submit it to you
later.
>
>
> > - CORBA::Environment. Orbix provides an additional parameter to
> > all distributed methods. We never use this parameter but it's in the
> > code. I've added an option to generate this parameter with default
> > values for operations and attribute access methods.
>
> The C++ mapping makes Environment an option if you don't have genuine
> C++ exceptions. Its use isn't necessary with omniORB, and I think it
> would be a backward step to provide an option to include it.
Agreed. Indeed one of our targets does not support C++ eh. However
we can implement locally an additional "portability" layer.
> > Something different: I've noticed a problem with name lookup. An
> > identifier is now searched only in the first inherited level.
> > ( An interface A defines an exception ex. B inherits from A and C
> > inherits from B. C defines a method which raises an ex. There, ex
> > is said not to be defined.)
> > This worked with omniidl2 V 2.7.1.
>
> This is a bug which was introduced in fixing a similar bug :-(. The
> fix will appear in CVS and FTP snapshots overnight.
>
OK applied, thanx.
(The firewall here won't allow cvs access. Is there any repository
where I could find diffs instead of the whole source tree ?)
About refcount retrieval, the patch I'd propose consists in moving
a method of the omniObject class from the private space to the
public. I think omniObject is not part of OMG standard, is it ?
Nyny
From dgrisby@uk.research.att.com Mon Dec 20 14:07:09 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Mon, 20 Dec 1999 14:07:09 +0000
Subject: [omniORB] Introduction..
In-Reply-To: Your message of "Mon, 20 Dec 1999 14:32:28 +0100."
<385E2FEB.FC72FBD2@penfeld.tls.mms.fr>
Message-ID: <199912201407.OAA03790@pineapple.cam-orl.co.uk>
On Monday 20 December, "F. Michel" wrote:
> Since, CosNaming::NamingContext is part of libomniORB2, we cannot mixit with
> our implementation of this object. An additional compile flag
> (NO_OMNI_NAMES for instance) gives us the behaviour we need with
> really little changes to the source and does not impact the nominal
> behaviour.
Oh I see -- you have an interface which calls itself
CosNaming::NamingContext, which has a different interface to the
standard one! I definitely don't think we should encourage such nasty
behaviour by adding make options. Is there any way you can convince
the necessary people to make a different interface, derived from
CosNaming::NamingContext?
[...IDL compiler name stripping...]
> In what form do you expect patches, I can join diffs to my next mail.
Feel free to send some diffs. Note that we won't necessarily include
them in the distribution. Also, we're in the process of re-writing the
IDL compiler to be completely different, so we're not enormously keen
to keep fiddling with the old one.
[...]
> > The C++ mapping makes Environment an option if you don't have genuine
> > C++ exceptions. Its use isn't necessary with omniORB, and I think it
> > would be a backward step to provide an option to include it.
>
> Agreed. Indeed one of our targets does not support C++ eh. However
> we can implement locally an additional "portability" layer.
Are you going to try to run omniORB on a platform without C++
exceptions? omniORB absolutely requires exceptions.
> (The firewall here won't allow cvs access. Is there any repository
> where I could find diffs instead of the whole source tree ?)
I think it would be far too much hassle to automatically maintain
diffs between different revisions. That's what CVS is for afterall.
There is, however,
http://www.uk.research.att.com/omniORB/omniORBbug.html
which contains patches for some bugs.
> About refcount retrieval, the patch I'd propose consists in moving
> a method of the omniObject class from the private space to the
> public. I think omniObject is not part of OMG standard, is it ?
Unfortunately, that change will make the interface incompatible with
the old interface (on some platforms anyway), so it would require a
major version number change. We'll consider making the change to later
versions.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From rceci@master.adams.com Mon Dec 20 22:58:35 1999
From: rceci@master.adams.com (Rob Cecil)
Date: Mon, 20 Dec 1999 17:58:35 -0500
Subject: [omniORB] COMM_FAILURE and shutdown
Message-ID: <385EB49B.B7837F4A@adams.com>
--------------4A0028F4C34D1F65E9079C2B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I have implemented server process shutdown via the method invocation method,
i.e.
void
Server::shutdown()
{
... cleanup ...
spawn thread to run BOA->impl_shutdown();
}
This technique works fine, with the exception that the client throws
COMM_FAILURE. The server shuts down, but the client aborts (because I am not
handling this exception in this particular case). If the client has not
performed any method calls prior to the shutdown() call, then no COMM_FAILURE
is thrown. However, something simple like invoking a method that sends a
IOR back to the client, will cause subsequent shutdown() calls to throw the
exception. I was under the understanding that spawning a thread in the server
to run the impl_shutdown() is the preferred way, because it allows the client
method call to return. So what am I missing?
Thanks
Rob
ps.
omniORB28
Solaris2.5.1
--
| Rob Cecil | Senior Development Engineer |
| rceci@adams.com | Product Development |
| (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
--------------------------------------------------------------------
Modern Quantum Physics has found that the universe is composed of
25% protons, 15% electrons, 15% neutrons, and 45% morons.
--------------4A0028F4C34D1F65E9079C2B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I have implemented server process shutdown via the method invocation
method, i.e.
void
Server::shutdown()
{
... cleanup ...
spawn thread to run BOA->impl_shutdown();
}
This technique works fine, with the exception that the client throws
COMM_FAILURE. The server shuts down, but the client aborts (because
I am not handling this exception in this particular case). If the
client has not performed any method calls prior to the shutdown() call,
then no COMM_FAILURE is thrown. However, something simple like invoking
a method that sends a IOR back to the client, will cause subsequent
shutdown() calls to throw the exception. I was under the understanding
that spawning a thread in the server to run the impl_shutdown() is
the preferred way, because it allows the client method call to return.
So what am I missing?
Thanks
Rob
ps.
omniORB28
Solaris2.5.1
--
| Rob Cecil | Senior Development Engineer |
| rceci@adams.com | Product Development |
| (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
--------------------------------------------------------------------
Modern Quantum Physics has found that the universe is composed of
25% protons, 15% electrons, 15% neutrons, and 45% morons.
--------------4A0028F4C34D1F65E9079C2B--
From brent.fulgham@xpsystems.com Mon Dec 20 23:39:48 1999
From: brent.fulgham@xpsystems.com (Brent Fulgham)
Date: Mon, 20 Dec 1999 15:39:48 -0800
Subject: [omniORB] Conflict with other ORBs?
Message-ID:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BF4B43.84D0696A
Content-Type: text/plain;
charset="iso-8859-1"
> > [ ... omniorb in the background seems to die when
> > GNOME is running ...]
>
> > However, if I terminate X (CTRL-ALT-BACKSPACE) omniorb gets killed
> > along with everything running under X. I don't think this is the
> > only case where omniorb gets killed, because I have experienced
> > omniorb stopping even when I have not terminated X.
>
> Is this when omniNames is running in an Xterm? Or started from one
> and running in the background? If not, killing X shouldn't have any
> effect on omniNames.
>
Right. omniNames starts up during system boot (init.d script). I
can't explain the X11 connection.
> Unless anyone else is seeing this problem, I can only assume that
> there's something very strange about your set-up.
>
Possibly. I just noticed that if I start the name server up at the
console (as root: bash# omninames -start) without passing PORT or
hostname data, things seem to work fine. I am wondering if we might
be seeing the same "bug" we spoke about last week, wherein a slight
typo in the BOA initializaton string might cause a lock condition
or "denial-of-service" type of problem.
In this case, my X11 connection might just have been simple
coincidence.
I will modify my startup script and see how this affects things.
Thanks,
-Brent
------_=_NextPart_001_01BF4B43.84D0696A
Content-Type: text/html;
charset="iso-8859-1"
RE: [omniORB] Conflict with other ORBs?
> > [ ... omniorb in the background seems to die when
> > GNOME is running ...]
>
> > However, if I terminate X (CTRL-ALT-BACKSPACE) omniorb gets killed
> > along with everything running under X. I don't think this is the
> > only case where omniorb gets killed, because I have experienced
> > omniorb stopping even when I have not terminated X.
>
> Is this when omniNames is running in an Xterm? Or started from one
> and running in the background? If not, killing X shouldn't have any
> effect on omniNames.
>
Right. omniNames starts up during system boot (init.d script). I
can't explain the X11 connection.
> Unless anyone else is seeing this problem, I can only assume that
> there's something very strange about your set-up.
>
Possibly. I just noticed that if I start the name server up at the
console (as root: bash# omninames -start) without passing PORT or
hostname data, things seem to work fine. I am wondering if we might
be seeing the same "bug" we spoke about last week, wherein a slight
typo in the BOA initializaton string might cause a lock condition
or "denial-of-service" type of problem.
In this case, my X11 connection might just have been simple
coincidence.
I will modify my startup script and see how this affects things.
Thanks,
-Brent
------_=_NextPart_001_01BF4B43.84D0696A--
From omniorb@beteigeuze.cs.tu-berlin.de Tue Dec 21 13:20:19 1999
From: omniorb@beteigeuze.cs.tu-berlin.de (Robert Sander)
Date: Tue, 21 Dec 1999 14:20:19 +0100
Subject: [omniORB] omniORBpy: import _GlobalIDL
Message-ID: <19991221142019.A27743@beteigeuze.cs.tu-berlin.de>
Hi!
I am experiencing a strange behaviour and can't help myself:
I have an idl-File compiled with "omniidl -bpython", resulting the
directory _GlobalIDL and a file_idl.py, which is imported from
_GlobalIDL/__init__.py
Now when I do an interactive python session starting with the interpreter
and the importing _GlobalIDL by hand, I see everything I need with
dir(_GlobalIDL). But within a "#!/usr/bin/python"-script importing
_GlobalIDL and the dir(_Global_IDL) reveals only ['__doc__', '__name__'].
What can I do?
Thanks for your help
--
Robert Sander
home.pages.de/~gurubert, pgp available there
tel 0700-GURUBERT
From omniorb@beteigeuze.cs.tu-berlin.de Tue Dec 21 13:21:03 1999
From: omniorb@beteigeuze.cs.tu-berlin.de (Robert Sander)
Date: Tue, 21 Dec 1999 14:21:03 +0100
Subject: [omniORB] Re: omniORBpy: import _GlobalIDL
In-Reply-To: <19991221142019.A27743@beteigeuze.cs.tu-berlin.de>; from omniorb on Tue, Dec 21, 1999 at 02:20:19PM +0100
References: <19991221142019.A27743@beteigeuze.cs.tu-berlin.de>
Message-ID: <19991221142103.B27743@beteigeuze.cs.tu-berlin.de>
On Tue, Dec 21, 1999 at 02:20:19PM +0100, Robert Sander wrote:
> _GlobalIDL and the dir(_Global_IDL) reveals only ['__doc__', '__name__'].
^^^^^^^^^^^ surely is _GlobalIDL
--
Robert Sander
home.pages.de/~gurubert, pgp available there
tel 0700-GURUBERT
From dgrisby@uk.research.att.com Tue Dec 21 13:40:15 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Tue, 21 Dec 1999 13:40:15 +0000
Subject: [omniORB] omniORBpy: import _GlobalIDL
In-Reply-To: Your message of "Tue, 21 Dec 1999 14:20:19 +0100."
<19991221142019.A27743@beteigeuze.cs.tu-berlin.de>
Message-ID: <199912211340.NAA27139@pineapple.cam-orl.co.uk>
On Tuesday 21 December, Robert Sander wrote:
> I have an idl-File compiled with "omniidl -bpython", resulting the
> directory _GlobalIDL and a file_idl.py, which is imported from
> _GlobalIDL/__init__.py
>
> Now when I do an interactive python session starting with the interpreter
> and the importing _GlobalIDL by hand, I see everything I need with
> dir(_GlobalIDL). But within a "#!/usr/bin/python"-script importing
> _GlobalIDL and the dir(_Global_IDL) reveals only ['__doc__', '__name__'].
I don't know why it isn't working for you. I've just tried it, and it
works as expected -- the same things are visible from a script as from
the interactive command line. Are you sure that /usr/bin/python is the
same python executable as you get if you just run "python"? Are you
sure that the PYTHONPATH is the same each time?
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From omniorb@beteigeuze.cs.tu-berlin.de Tue Dec 21 16:23:31 1999
From: omniorb@beteigeuze.cs.tu-berlin.de (Robert Sander)
Date: Tue, 21 Dec 1999 17:23:31 +0100
Subject: [omniORB] omniORBpy: import _GlobalIDL
In-Reply-To: <199912211340.NAA27139@pineapple.cam-orl.co.uk>; from dgrisby@uk.research.att.com on Tue, Dec 21, 1999 at 01:40:15PM +0000
References: <19991221142019.A27743@beteigeuze.cs.tu-berlin.de> <199912211340.NAA27139@pineapple.cam-orl.co.uk>
Message-ID: <19991221172331.A29733@beteigeuze.cs.tu-berlin.de>
On Tue, Dec 21, 1999 at 01:40:15PM +0000, Duncan Grisby wrote:
> I don't know why it isn't working for you. I've just tried it, and it
> works as expected -- the same things are visible from a script as from
> the interactive command line. Are you sure that /usr/bin/python is the
> same python executable as you get if you just run "python"? Are you
> sure that the PYTHONPATH is the same each time?
Yes, that is the same. That's why I am so confused.
--
Robert Sander
home.pages.de/~gurubert, pgp available there
tel 0700-GURUBERT
From taras@deka.kp.km.ua Tue Dec 21 08:03:05 1999
From: taras@deka.kp.km.ua (Viacheslav N Tararin)
Date: Tue, 21 Dec 1999 10:03:05 +0200
Subject: [omniORB] omniORBpy and omniORB3
Message-ID: <385F3439.952071B0@deka.kp.km.ua>
Hi.
Is available omniORBpy for omniORB3?
Regards.
From ceyhun_ozgun@hotmail.com Wed Dec 22 07:26:55 1999
From: ceyhun_ozgun@hotmail.com (Ceyhun ÖZGÜN)
Date: Tue, 21 Dec 1999 23:26:55 PST
Subject: [omniORB] Is there another way to get a reference other than NameService
Message-ID: <19991222072655.53484.qmail@hotmail.com>
Hi,
I want to use specific server machines with static IP to implement objects.
And I don't want to use NameService.
I want to get a reference with given an IP address and a port number of
server machine.
Is it possible to do this?
Or is there any other way ?
Thanks in advance.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From floris.korbijn@NECS.nl Wed Dec 22 14:18:46 1999
From: floris.korbijn@NECS.nl (Floris Korbijn)
Date: Wed, 22 Dec 1999 15:18:46 +0100
Subject: [omniORB]Reusing IOR on restart.
Message-ID:
Hello,
I have the following problem. I have a Corba server with a main object
registered by the
naming service. When the server restarts I would like the 'new' main object
to reuse the
IOR of the previous instance. The main server object is stateless so
creating a new one
should not be a problem.
I tried to retrieve the IOR from the previous instance and to convert this
IOR to an
omniORB::objectKey using the octetSequenceToKey method. This results in an
CORBA::MARSHAL
exception.
Is this the right approach, and if so, how should I do this.
F.Korbijn.
Sr Software Engineer
Nederlof EC Solutions
From gtrudel@mediatrix.com Wed Dec 22 14:33:09 1999
From: gtrudel@mediatrix.com (Guy Trudel)
Date: Wed, 22 Dec 1999 09:33:09 -0500
Subject: [omniORB] Is there another way to get a reference other than
NameService
Message-ID: <80E2FF0AC64DD311AC3700E02910AE0A136996@INTERNAL>
Glad you ask this question. I found a way to do it using the
omniORB::loader.
My goal is to replace a NT service named pipe server by a Nt service corba
server,
so clients already know the server ip address.
The code below is part of my test (with OmniOrb 2.8) of doing it, I'm quite
new
with OmniOrb, so I don't pretend it's the way to do it.
On the server side:
int main(int argc, char* argv[])
{
int nArcg = 7;
char *ppArg[] = { argv[0] ,
"-ORBInitialHost", "xxx.xxx.xxx.xxx",
"-ORBInitialPort", "1000",
"-BOAiiop_port", "1002" };
CORBA::ORB_ptr orb = CORBA::ORB_init(nArcg,ppArg,"omniORB2");
CORBA::BOA_ptr boa = orb->BOA_init(nArcg,ppArg,"omniORB2_BOA");
// Set the loader (found below)
omniORB::loader::set(loader);
CCorbaServerImpl server;
m_pUniqueServer = &server;
server._obj_is_ready(boa);
cout << orb->object_to_string(&server) << " is ready" << endl;
boa->impl_is_ready();
...
}
static CORBA::Object_ptr loader(const omniORB::objectKey& key)
{
if( (key.hi == 0) && (key.med == 0) && (key.lo == 1) )
{
if( m_pUniqueServer == NULL )
return CORBA::Object::_nil();
else
return CORBA::Object::_duplicate(m_pUniqueServer);
}
else
{
return CORBA::Object::_nil();
}
}
On client side:
void encodeIOPprofile(IOP::TaggedProfile& profile)
{
int objkeysize = sizeof(omniORB::objectKey);
profile.tag = IOP::TAG_INTERNET_IOP;
// ORBInitialHost
CORBA::ULong hlen = strlen((const char *)"xxx.xxx.xxx.xxx") + 1;
{
// calculate the total size of the encapsulated stream
CORBA::ULong total = 8 + hlen; // first 4 bytes + aligned
host
total = ((total + 1) & ~(1)) + 2; // aligned port value
total = ((total + 3) & ~(3)) + 4 + // aligned object key
objkeysize;
profile.profile_data.length(total);
}
profile.profile_data[0] = omni::myByteOrder;
profile.profile_data[1] = 1; // IIOP major version no. = 1
profile.profile_data[2] = 0; // IIOP minor version no. = 0
profile.profile_data[3] = 0;
{
CORBA::ULong &l = (CORBA::ULong &) profile.profile_data[4];
l = hlen;
}
// ORBInitialHost
memcpy((void *)&(profile.profile_data[8]),(void
*)"xxx.xxx.xxx.xxx",hlen);
CORBA::ULong idx = ((8 + hlen) + 1) & ~(1);
{
CORBA::UShort &l = (CORBA::UShort &) profile.profile_data[idx];
//### BOAiiop_port
l = 1002;
}
idx = ((idx + 2) + 3) & ~(3);
{
CORBA::ULong &l = (CORBA::ULong &) profile.profile_data[idx];
l = objkeysize;
}
if (objkeysize)
{
// Put objkey.hi and objkey.med to 0 so loader will know
// it's a "special" load
omniORB::objectKey objkey;
objkey.hi = 0;
objkey.med = 0;
// Use objkey.lo as the object key (see server loader)
objkey.lo = 1;
idx += 4;
memcpy((void *)&profile.profile_data[idx],
(void *)&objkey,objkeysize);
}
}
MyCorbaServer_ptr GetMyCorbaServer()
{
int nArcg = 7;
char *ppArg[] = { argv[0] ,
"-ORBInitialHost", "xxx.xxx.xxx.xxx",
"-ORBInitialPort", "1000",
"-BOAiiop_port", "1002" };
CORBA::ORB_ptr orb = CORBA::ORB_init(nArcg,ppArg,"omniORB2");
MyCorbaServer_ptr pServer = NULL;
IOP::TaggedProfileList taggedProfileList;
taggedProfileList.length(1);
encodeIOPprofile(taggedProfileList[0]);
omniObject* pOmniObject;
pOmniObject = omni::createObjRef(MyCorbaServer_IntfRepoID,NULL,
&taggedProfileList,false);
if( pOmniObject != NULL )
{
CORBA::Object_ptr pCorbaObject;
pCorbaObject =
(CORBA::Object_ptr)pOmniObject->_widenFromTheMostDerivedIntf(0);
if( pCorbaObject != NULL )
{
pServer = MyCorbaServer::_narrow(pCorbaObject);
}
}
return pServer;
}
Guy Trudel
-----Original Message-----
From: Ceyhun ÖZGÜN [mailto:ceyhun_ozgun@hotmail.com]
Sent: Wednesday, December 22, 1999 2:27 AM
To: djr@uk.research.att.com
Cc: omniorb-list@uk.research.att.com
Subject: [omniORB] Is there another way to get a reference other than
NameService
Hi,
I want to use specific server machines with static IP to implement objects.
And I don't want to use NameService.
I want to get a reference with given an IP address and a port number of
server machine.
Is it possible to do this?
Or is there any other way ?
Thanks in advance.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From yana@ParadigmGeo.com Wed Dec 22 14:58:38 1999
From: yana@ParadigmGeo.com (Yana Vaisman)
Date: Wed, 22 Dec 1999 16:58:38 +0200
Subject: [omniORB] Naming service.
Message-ID: <3860E71E.5A16E5F@geodepth.com>
Hi,
I'm doing my first steps with omniORB. So, according to the omniORB2
version 2.8 User's Guide recommendation I'm carefully studying the
examples. I compiled /src/examples/echo examples on Unix and tried
to run them.
eg1, eg2_impl examples are OK.
But I have a problem with the eg3_impl example. I've done everything
according to README file explanations:
I've run the COS Naming service, then I've run the eg3_impl.
Everything is seemed all right, the eg3_clt clients successfully get the
particular IOR from the omniNames server. Then I killed the eg3_impl
process and tryed to run it again. As a result, the Naming Service was
crashed (Segmentation fault).
Can you kindly explain me this situation and what can I do to avoid it.
From amcc@uk.research.att.com Wed Dec 22 16:59:22 1999
From: amcc@uk.research.att.com (Aideen McConville)
Date: Wed, 22 Dec 1999 16:59:22 +0000 (GMT)
Subject: [omniORB] Digest version of omniorb-list now available
Message-ID: <14433.333.552370.623777@onion>
A digest version of the omniorb-list (omniorb-list-digest) is now
available. The digest carries the same messages as omniorb-list, but
is posted once a day and contains all of the last day's messages.
To change to the digest, send a message to
majordomo@uk.research.att.com
with the following lines in the body of the message.
unsubscribe omniorb-list
subscribe omniorb-list-digest
For more information see:
See: http://www.uk.research.att.com/omniORB/intouch.html
-- Aideen (list admin)
From amcc@uk.research.att.com Wed Dec 22 17:18:55 1999
From: amcc@uk.research.att.com (Aideen McConville)
Date: Wed, 22 Dec 1999 17:18:55 +0000 (GMT)
Subject: [omniORB] Digest version of omniorb-list now available
In-Reply-To: <14433.333.552370.623777@onion>
References: <14433.333.552370.623777@onion>
Message-ID: <14433.1646.953091.438987@onion>
PS
1) Continue to post messages to omniorb-list (even if you're
subscribed to omniorb-list-digest)
2) NB: ensure that your mailer is configured to send "plain text"
to omniorb-list
Thanks,
-- Aideen
From jdiaz@eunet.es Thu Dec 23 11:58:18 1999
From: jdiaz@eunet.es (=?iso-8859-1?Q?Jos=E9?= Manuel =?iso-8859-1?Q?D=EDaz=20Rodr=EDguez?=)
Date: Thu, 23 Dec 1999 12:58:18 +0100
Subject: [omniORB] CORBA server objects with persistent references with omniORB
Message-ID: <38620E5A.E0FF0A57@eunet.es>
Hi,
I would appreciate any suggestion to solve the following problem:
-- I need a CORBA server object to use the reference I tell it to use,
not the reference associated by the broker by default.
I use the C++ implementation of the broker.
I already create objects from stringified references, but only in the
client side. I now want the implementation or server object to adopt the
reference I pass it through a string variable.
Thank you very much,
--=20
Jos=E9 Manuel D=EDaz Rodr=EDguez
From renzo.tomaselli@tecnotp.it Fri Dec 24 09:43:08 1999
From: renzo.tomaselli@tecnotp.it (Renzo Tomaselli)
Date: Fri, 24 Dec 1999 10:43:08 +0100
Subject: [omniORB] anys and sequence
Message-ID: <000001bf4df3$62e6d570$a8c649c1@big>
This is a multi-part message in MIME format.
------=_NextPart_000_0034_01BF4DFB.AA90F560
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi OmniORB developers,
I noticed as OmniORB 2.8 deals with inserting/extracting sequences =
to/from anys.
Sequence elements are handled one-by-one in tcParser::copyFrom/to (in =
tcParser.cc) resulting in a terrific performance dropping in case of =
long sequences of octets, such as for graphical bitmaps. Each octet goes =
through a long number of operations to be copied in/out the any.
While tcParser::copyFrom(MemBufferedStream& mbuf) is optimized for this, =
resulting in a memcpy for the best case, =
tcParser::copyFrom(tcDescriptor& desc) is not, raising the above =
performance issue. The net result is that sending a octet sequence is =
fast, sending the same into an any is a double disaster.
This topic is somewhat related to a similar one in DynAnys (see a =
related posting sometime ago).
Thanks,
Renzo Tomaselli =20
-------------------------------------------------------------------------=
--
TecnoTP s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi Valsugana, Trento TN ITALY
Tel. +39 0461 773164 Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.it =20
-------------------------------------------------------------------------=
--
------=_NextPart_000_0034_01BF4DFB.AA90F560
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi OmniORB developers,
I noticed as OmniORB 2.8 deals =
with=20
inserting/extracting sequences to/from anys.
Sequence elements are handled one-by-one in=20
tcParser::copyFrom/to (in tcParser.cc) resulting in a terrific =
performance=20
dropping in case of long sequences of octets, such as for graphical =
bitmaps.=20
Each octet goes through a long number of operations to be copied in/out =
the=20
any.
While tcParser::copyFrom(MemBufferedStream& =
mbuf) is=20
optimized for this, resulting in a memcpy for the best case,=20
tcParser::copyFrom(tcDescriptor& desc) is not, raising the above =
performance=20
issue. The net result is that sending a octet sequence is fast, sending =
the same=20
into an any is a double disaster.
This topic is somewhat related to a similar one in =
DynAnys=20
(see a related posting sometime ago).
Thanks,
&nbs=
p; =
; =
=20
Renzo Tomaselli =20
---------------------------------------------------------------------=
------
TecnoTP=20
s.n.c. Special Information System Design
Maso Pelauchi I38050 Ronchi=20
Valsugana, Trento TN ITALY
Tel. +39 0461=20
773164 Fax. +39 0461 771514
e-mail: renzo.tomaselli@tecnotp.it=
=20
---------------------------------------------------------------------=
------
------=_NextPart_000_0034_01BF4DFB.AA90F560--
From dgrisby@uk.research.att.com Fri Dec 24 15:05:14 1999
From: dgrisby@uk.research.att.com (Duncan Grisby)
Date: Fri, 24 Dec 1999 15:05:14 +0000
Subject: [omniORB] omniORBpy and omniORB3
In-Reply-To: Your message of "Tue, 21 Dec 1999 10:03:05 +0200."
<385F3439.952071B0@deka.kp.km.ua>
Message-ID: <199912241505.PAA00703@pineapple.cam-orl.co.uk>
On Tuesday 21 December, Viacheslav N Tararin wrote:
> Is available omniORBpy for omniORB3?
Not yet. It will be available some time in the new year.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
From omniorb@beteigeuze.cs.tu-berlin.de Mon Dec 27 14:33:43 1999
From: omniorb@beteigeuze.cs.tu-berlin.de (Robert Sander)
Date: Mon, 27 Dec 1999 15:33:43 +0100
Subject: [omniORB] omniORBpy: import _GlobalIDL
In-Reply-To: <19991221172331.A29733@beteigeuze.cs.tu-berlin.de>; from omniorb@beteigeuze.cs.tu-berlin.de on Tue, Dec 21, 1999 at 05:23:31PM +0100
References: <19991221142019.A27743@beteigeuze.cs.tu-berlin.de> <199912211340.NAA27139@pineapple.cam-orl.co.uk> <19991221172331.A29733@beteigeuze.cs.tu-berlin.de>
Message-ID: <19991227153343.A20411@beteigeuze.cs.tu-berlin.de>
Hi!
It works now, I am now importing _GlobalIDL before any other things,
espacially CORBA, maybe that's the trick.
#!/usr/bin/python
import _GlobalIDL
from omniORB import CORBA
Greetings
--
Robert Sander
home.pages.de/~gurubert, pgp available there
tel 0700-GURUBERT
From alik@oxiris.net Tue Dec 28 13:42:54 1999
From: alik@oxiris.net (Alik Kurdjukov)
Date: Tue, 28 Dec 1999 16:42:54 +0300
Subject: [omniORB] omniidl2 bug?
Message-ID:
Hello!
I have a strange bug compiling IDL files on Win32. I need to compile IDL
file that is not in the dir where omniidl2 is running. If I give omniidl2
absolute path to the file it works ok, but if I give it relative path it
makes files ".h" and "SK.cpp", just as I said. In my project I have no
possibility to retrieve full path ;(. What can I do with it?
Best regards,
Alik.
From glowstars@gmx.de Wed Dec 29 13:02:06 1999
From: glowstars@gmx.de (Thorsten Roskowetz)
Date: Wed, 29 Dec 1999 14:02:06 +0100 (MET)
Subject: [omniORB] omniORBpy and attributes in IDL (server side)
Message-ID: <8758.946472526@www11.gmx.net>
Hi,
can someone please enlighten me on how to implement
interface attributes server-side with omniORBpy?
The Python Language Mapping only mentions attributes
client side (basically an attribute is mapped to two
methods on the corresponding Python stub class, an
accessor an a modifier prefixed with '_get_' and
'_set_' respectively).
Cheers,
Thorsten
--
Sent through Global Message Exchange - http://www.gmx.net
From jfd@silicomp.fr Thu Dec 30 09:31:23 1999
From: jfd@silicomp.fr (Jean-Francois Denise)
Date: Thu, 30 Dec 1999 10:31:23 +0100
Subject: [omniORB] Generating IOR
Message-ID: <386B266B.27B01603@silicomp.com>
Hello,
Is it possible using omniorb2 to set at creation time an object IOR. I
need to create a specific multiple profile IOR.
Thanks.
--
^
/ \
/ \ Jean-Francois Denise
+---/ \---+ Software Engineer
| / \ | e-mail : jfd@silicomp.com
| /silicomp \ |
|/ingenierie \| Phone: (33) 4 76 41 66 66 Fax: (33) 4 76 41 66 67
|-------------|
| | 195, rue Lavoisier - BP 1
| G R O U P E | 38330 Montbonnot St Martin
+-------------+ FRANCE
S I L I C O M P
From rgruet@ina.fr Thu Dec 30 10:58:35 1999
From: rgruet@ina.fr (Richard Gruet)
Date: Thu, 30 Dec 1999 11:58:35 +0100
Subject: [omniORB] omniORBpy and attributes in IDL (server side)
References: <8758.946472526@www11.gmx.net>
Message-ID: <386B3ADB.3235EF94@ina.fr>
--------------18426228C7ED9E1DD3444ECC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thorsten Roskowetz wrote:
> can someone please enlighten me on how to implement
> interface attributes server-side with omniORBpy?
> The Python Language Mapping only mentions attributes
> client side (basically an attribute is mapped to two
> methods on the corresponding Python stub class, an
> accessor an a modifier prefixed with '_get_' and
> '_set_' respectively).
It's exactly the same on the server side. In your implementation class,
for a given attribute XXX,
you just have to define a pair of methods:
class MyInterfaceImpl(POA_MyModule.MyInterface):
...
def _get_XXX(self):
return theValueOfXXX
def _set_XXX(self, value):
# sets XXX to value
Cheers,
Richard
--------------18426228C7ED9E1DD3444ECC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thorsten Roskowetz wrote:
can someone please enlighten me on how to implement
interface attributes server-side with omniORBpy?
The Python Language Mapping only mentions attributes
client side (basically an attribute is mapped to two
methods on the corresponding Python stub class, an
accessor an a modifier prefixed with '_get_' and
'_set_' respectively).
It's exactly the same on the server side. In your implementation class,
for a given attribute XXX,
you just have to define a pair of methods:
class MyInterfaceImpl(POA_MyModule.MyInterface):
...
def _get_XXX(self):
return theValueOfXXX
def _set_XXX(self, value):
# sets XXX to value
Cheers,
Richard
--------------18426228C7ED9E1DD3444ECC--
From nickr@harlequin.co.uk Thu Dec 30 11:31:22 1999
From: nickr@harlequin.co.uk (Nick Reeves)
Date: Thu, 30 Dec 1999 11:31:22 GMT
Subject: [omniORB] Portable Interceptor
Message-ID: <199912301131.LAA23272@gpo.cam.harlequin.co.uk>
The competing proposals for Portable Interceptors have been formally
merged into a single revised spec orbos/99-12-02, and the nonsense of
the earlier specs has been removed.
Given the wide backing it seems likely to go through with only minor
amendments.
So this seems like a good time to ask what is the official omniORB
position on it.
Thanks again for the great work on adding POA !
--
Nick Reeves nickr@harlequin.co.uk
From glowstars@gmx.de Thu Dec 30 12:50:07 1999
From: glowstars@gmx.de (Thorsten Roskowetz)
Date: Thu, 30 Dec 1999 13:50:07 +0100 (MET)
Subject: [omniORB] omniORBpy and attributes in IDL (server side)
References: <386B3ADB.3235EF94@ina.fr>
Message-ID: <1075.946558207@www12.gmx.net>
Thanks! I was somewhat confused by the C++ mapping which
effectively hides that it invokes the _get_xxxx and _set_xxxx
methods too.
--
Sent through Global Message Exchange - http://www.gmx.net
From tei@elca.ch Thu Dec 30 15:25:31 1999
From: tei@elca.ch (Eicher Thomas)
Date: Thu, 30 Dec 1999 16:25:31 +0100
Subject: [omniORB] use 2.8 client with 2.7.1 server?
Message-ID: <000001bf52da$1f808dd0$1c9248c1@elca.ch>
Is it possible to use a client side built with omniORB 2.8 together with =
a
server side that was built using omniORB 2.7.1? I am not using Any's.
Thanks, Tom
______________________________________________
Tom Eicher ELCA Informatik AG
tei@elca.ch Steinstrasse 21
+41 (0)1 456 32 47 8003 Z=FCrich
http://www.elca.ch Switzerland
From taras@deka.kp.km.ua Thu Dec 30 08:16:42 1999
From: taras@deka.kp.km.ua (Viacheslav N Tararin)
Date: Thu, 30 Dec 1999 10:16:42 +0200
Subject: [omniORB] omniidl2 bug
Message-ID: <386B14EA.25C43720@deka.kp.km.ua>
This is a multi-part message in MIME format.
--------------E14C31724C1DC26ED2606274
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Hi.
1. First idl file:
module a {
module b {
interface Ziro {
short get_short();
};
};
};
2. Second idl file
module a {
typedef long TheLong;
module b {
interface One {
TheLong get_long();
};
};
};
3. Produced omniidl2 test.hh don't contain lines
typedef long TheLong;
I'm attach test files.
Environment: WinNT 4.0 SP3 VC6.0 omniORB2 2.8.0.
Happy New Year.
Tararin Slavik.
--------------E14C31724C1DC26ED2606274
Content-Type: application/x-unknown-content-type-idlfile;
name="test0.idl"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="test0.idl"
bW9kdWxlIGEgew0KICAgIG1vZHVsZSBiIHsNCiAgICAgICAgaW50ZXJmYWNlIFppcm8gew0K
ICAgICAgICAgICAgc2hvcnQgZ2V0X3Nob3J0KCk7DQogICAgICAgIH07DQogICAgfTsNCn07
--------------E14C31724C1DC26ED2606274
Content-Type: application/x-unknown-content-type-idlfile;
name="test.idl"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="test.idl"
I2luY2x1ZGUgPHRlc3QwLmlkbD4NCm1vZHVsZSBhIHsNCiAgICB0eXBlZGVmIGxvbmcgVGhl
TG9uZzsgDQogICAgbW9kdWxlIGIgew0KICAgICAgICBpbnRlcmZhY2UgT25lIHsNCiAgICAg
ICAgICAgIFRoZUxvbmcgZ2V0X2xvbmcoKTsNCiAgICAgICAgfTsNCiAgICB9Ow0KfTs=
--------------E14C31724C1DC26ED2606274--
From taras@deka.kp.km.ua Wed Dec 29 14:58:26 1999
From: taras@deka.kp.km.ua (Viacheslav N Tararin)
Date: Wed, 29 Dec 1999 16:58:26 +0200
Subject: [omniORB] omniidl2 bug
Message-ID: <386A2191.6980C494@deka.kp.km.ua>
Hi.
It's part of CosCollection.idl
interface KeyCollection : Collection {
// c o m p u t i n g t h e k e y s
void key (in any element, out any key)
raises (ElementInvalid);
void keys (in AnySequence elements, out AnySequence keys)
raises (ElementInvalid);
};
Prodused file CosCollection.hh containts:
(5114) virtual void key(const CORBA::Any & element, CORBA::Any *&
key) = 0;
(5115) virtual void _0RL__key(const CORBA::Any & element, CORBA::Any
*& key) {
(5116) key(element, key);
(5117) }
(5118) virtual void keys(const AnySequence & elements, AnySequence *&
keys) = 0;
(5119) virtual void _0RL__keys(const AnySequence & elements,
AnySequence *& keys) {
(5120) keys(elements, keys);
(5121) }
On WinNT it's prodused error
cl.exe /c /nologo /D__x86__ /D__NT__ /D__WIN32__ /GX /TP /MD
-I..\..\..\..\omni\include -I..\..\include -I..\..\include\ui
LLsControlsDynSK.cpp /Fo..\..\obj\LLsControlsDynSK.obj
LLsControlsDynSK.cpp
..\..\include\omg/CosCollection.hh(5114) : error C2064: term does not
evaluate to a function
..\..\include\omg/CosCollection.hh(5118) : error C2064: term does not
evaluate to a function
Environment WinNT 4.0 SP3 VC6.0 omniORB2 (2.8.0).
Happy New Year.
Tararin Slavik.
From jfd@silicomp.com Mon Dec 27 09:30:21 1999
From: jfd@silicomp.com (jfd)
Date: Mon, 27 Dec 1999 10:30:21 +0100
Subject: [omniORB] Implementation over multiple IP hosts
Message-ID: <386731AD.769FDC13@silicomp.com>
Il s'agit d'un message multivolet au format MIME.
--------------C884274C6704C9CD025577FC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I need to create an object implementation on a server running on an host
having multiple IP addresses. I want the implementation being accessible
through both IP interfaces. I can set a prefered host IP address or name
using OMNIORB_USEHOSTNAME but not a list of IP addresses.
I know that my question doesn't fit IOR single profile management. Host
name being part of IOR, if an implementation object is created using 2
different IP addresses, 2 profiles must be generated by the BOA when
creating the object implementation.
Is there a way using omniorb to do so.
Thanks.
--------------C884274C6704C9CD025577FC
Content-Type: text/x-vcard; charset=us-ascii;
name="jfd.vcf"
Content-Description: Carte pour jfd
Content-Disposition: attachment;
filename="jfd.vcf"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.ri.silicomp.fr id KAA08294
begin:vcard=20
n:Jean-Fran=E7ois;Denise
tel;work:+33-04/76/634863
x-mozilla-html:FALSE
url:www.ri.silicomp.com
org:Silicomp Research Institute;AppliBus
version:2.1
email;internet:jfd@silicomp.com
title:Research and Development
adr;quoted-printable:;;2 Avenue de Vignate=3D0D=3D0A;Gi=E8res;;F38610;Fra=
nce
fn:Denise Jean-Fran=E7ois
end:vcard
--------------C884274C6704C9CD025577FC--