gmane.comp.corba.omniorb.devel

omniORB subversion repository moved

Duncan Grisby — 2013-05-23T14:51:57

Hello,

SourceForge has moved the omniORB subversion repository to a new home.
if you have a checkout, you need to tell svn is has been relocated. To
do so, go to the top-level directory of the checkout and run a command
like this for a checkout of trunk:

  svn relocate https://svn.code.sf.net/p/omniorb/svn/trunk

or if you have the 4_1 branch:

  svn relocate https://svn.code.sf.net/p/omniorb/svn/branches/4_1


If you have an older svn version, you need to use svn switch instead,
e.g.:

  svn switch --relocate https://omniorb.svn.sourceforge.net/svnroot/omniorb/trunk https://svn.code.sf.net/p/omniorb/svn/trunk


Let me know if there are any problems...

Cheers,

Duncan.

Building for Mac OS X Lion

Thomas Lockhart — 2012-02-12T03:03:07

I'm trying to get code running on Mac OS X including omniORB and omniORBpy.

The current MacPorts ports are for 4.1.4 and 3.4, respectively, and 
fails to build on my recent MacBook with XCode-4.2.1. I've updated my 
copy of the port of omniORB to 4.1.6 and after setting DYLD_LIBRARY_PATH 
in the port script so the linker would find libraries in the build area 
I'm getting the following error:

/Developer/usr/bin/clang++ -o catior -L/opt/local/lib -arch x86_64 -pipe 
-O2 -arch x86_64 -fno-common -bind_at_load -L../../../../lib 
-L../../../../lib catior.o -lomniORB4 -lomnithread
Undefined symbols for architecture x86_64:
   "operator<<=(unsigned int&, cdrStream&)", referenced from:
       
_CORBA_Unbounded_Sequence<IOP::TaggedProfile>::operator<<=(cdrStream&) 
in catior.o

Which I see is indeed undefined in both catior.o and in 
libomniORB4.dylib (along with undefined operators for a few other int 
types). I'm guessing it is an implicit template issue but...

... when I look at libomniORB4.so on my Linux box I don't see any 
definition for operator<<=() with two arguments except for a strong 
symbol with "long double&" as the first argument. None with "unsigned int&".

Does this ring a bell with anyone? Any hints on where to look? Has 
anyone had success building with clang++ rather than gcc?

TIA

                - Tom

maximum size of -ORBgiopMaxMsgSize

adeeshah — 2011-11-28T12:31:18

Hi,

I have a omniorb server and client implementation and i set the
-ORBgiopMaxMsgSize on both to 10485760. But still sometime my corba server
crashed. And it usually happens when the size of the message is larger than
10485760. Can anyone tell me what is the maximum value that i can set for
-ORBgiopMaxMsgSize?

Adeel.

RPM spec files for 4.1.6 and 3.6

Thomas Lockhart — 2011-08-08T05:12:33

I've done some light patching to get the as-shipped spec files happy 
with the new release. For some reason Fedora 15 seems to require that 
the library names be explicitly mentioned in the "provides" clause for 
the library package; I haven't run into this before and don't know if it 
is a change in rpm or a defect in FC15.

I've also parameterized the omniORB version number for the omniORBpy 
spec file since file names based on this version are mentioned farther 
down in the spec file.

                                         - Tom

_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

Minor documentation patch

Floris Bruynooghe — 2011-03-29T20:18:47

Hi

One of Debian's QA analysis efforts was to spot insecure usage of
PYTHONPATH, i.e. PYTHON=$PYTHONPATH:/some/path which could potentially
put the current working directory on the PYTHONPATH.  In OmniORBpy
this occurs only in the documentation, however they still regard that
as a security bug ;-).

As I'm always interested in keeping Debian's patches to a minimum
attached is the patch we applied to the documentation to fix this
issue, in case you would like to apply it upstream.

Regards
Floris

omniORB4.1.3 compilation error

Naga Ram M Chavakula — 2010-11-24T13:00:23

Hi,

I got omniORB4.1.3 code from SVN, while I tried to make export, I get below error

making export in src/tool...
make[1]: Entering directory `/cygdrive/e/Nag/omniORB/src/tool'
making export in src/tool/omniidl...
make[2]: Entering directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl'
making export in src/tool/omniidl/cxx...
make[3]: Entering directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl/cxx'
make[3]: *** No rule to make target `/e/nag/omniorb/include/omniORB4/CORBA_sysde
p.h', needed by `idlc.d'.  Stop.
make[3]: Leaving directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl/cxx'
make[2]: *** [export] Error 2
make[2]: Leaving directory `/cygdrive/e/Nag/omniORB/src/tool/omniidl'
make[1]: *** [export] Error 2
make[1]: Leaving directory `/cygdrive/e/Nag/omniORB/src/tool'
make: *** [export] Error 2

It is stopping while compiling idlc.d. Any suggestions how to resolve the issue

Thanks,
Naga Ram

_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

libwrapper compiler issue

Naga Ram M Chavakula — 2010-11-24T09:09:23

Hi,

The  compilation of omniORB4.1.3 in XP with VC6 failed, I followed readme.win32 & did all necessary configuration.
I am getting below error while I run make export in the src folder as explained in readme file, I checked in static folder the files exist, but still libwrapper is causing below error

+ ../../../bin/x86_win32/libwrapper -gnuwin32 static/omnithread.lib static/nt.o
lib /OUT:static\omnithread.lib static\nt.o
lib: No such file or directory
make[2]: *** [static/omnithread"".lib] Error 1
make[2]: Leaving directory `/cygdrive/e/Nag/omniORB-4.1.3/omniORB-4.1.3/src/lib/
omnithread'
make[1]: *** [export] Error 2
make[1]: Leaving directory `/cygdrive/e/Nag/omniORB-4.1.3/omniORB-4.1.3/src/lib'

make: *** [export] Error 2




Thanks,
Naga Ram M Chavakula | Senior Project Manager
O: 608.448.3117|M: 0091.9885778079 | nagaram.chavakula< at >symphonycorp.com<mailto:nagaram.chavakula< at >symphony.com>
Symphony Corporation<http://www.symphony.cc/> | Hyderabad, A.P.India-500 082 | A SEI-CMMI Level 4 Company
 We synchronize business, technology and people
" It is not difficult to be on TOP...It is difficult when you carry Truth,Commitment and Transparency with you"

_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

patch to allow disabling the long double support

Mika Laitio — 2010-10-13T00:15:31

In some systems like mips or arm the gcc toolchain fails to build 
long double code that is generated from the corbaidl.idl
If we are in addition building in the cross compile environment, we must also call 
external omniidl instead of the just build one. Therfore the disabling of 
long double support from the just generated omniidl version would not 
work on crosscompile environment.

include/omniORB4/CORBA_sysdep_trad.h:
-#  define HAS_LongDouble
+#if defined(_GLIBCXX_USE_C99)
+#  define HAS_LongDouble
+#endif

Therefore I created attached patch which adds "--disbale-longdouble" option to configure. (once
regenerated with autoreconf command) If --disable-longdouble is given, 
then -DDISABLE_LONGDOUBLE option is passed to omniidl when it is reguested 
to generate stups from corbaidl.idl. corbaidl.idl instead have new "ifndef 
DISABLE_LONGDOUBLE" check which surrounds the part of the idl which 
defines the long double sequence.

In addition of this patch, when crosscompiling for example to mips, I need 
to remove the $(TOOLBINDIR) from the omniidl path definition in 
mk/beforeauto.mk.in file so that my build systems omniidl will get called 
instead of this target system crosscompiled one.

Maybe another configure option for allowing to define the path to omniidl 
version used, would be a good idea? At the moment I do not have that 
available, but if that approach is good, I can try to create something.

Mikadiff -Naur omniorb_41_branch_orig/acinclude.m4 omniorb_41_branch_new/acinclude.m4
--- omniorb_41_branch_orig/acinclude.m42010-10-13 00:01:31.821617703 +0300
+++ omniorb_41_branch_new/acinclude.m42010-10-13 01:38:41.471615078 +0300
< at >< at > -420,6 +420,18 < at >< at >
 fi
 ])
 
+dnl Disable support for long double even if the toolchain claims to support it. (does really not work on mipsel or arm)
+AC_DEFUN([OMNI_DISABLE_LONGDOUBLE],
+[AC_CACHE_CHECK(whether to disable long double support even if toolchain supports it,
+omni_cv_enable_longdouble,
+[AC_ARG_ENABLE(longdouble,
+               AC_HELP_STRING([--disable-longdouble],
+                  [disable long double suppor (default enable-longdouble)]),
+               omni_cv_enable_longdouble=$enableval,
+               omni_cv_enable_longdouble=yes)
+])
+AC_SUBST(ENABLE_LONGDOUBLE, $omni_cv_enable_longdouble)
+])
 
 dnl
 dnl Tests from http://www.gnu.org/software/ac-archive/
diff -Naur omniorb_41_branch_orig/configure.ac omniorb_41_branch_new/configure.ac
--- omniorb_41_branch_orig/configure.ac2010-10-13 00:01:20.549617644 +0300
+++ omniorb_41_branch_new/configure.ac2010-10-13 01:14:17.435865139 +0300
< at >< at > -134,7 +134,7 < at >< at >
 OMNI_DISABLE_THREAD_TRACING
 OMNI_DISABLE_IPV6_CHECK
 OMNI_DISABLE_ALLOCA
-
+OMNI_DISABLE_LONGDOUBLE
 
 dnl ** Compiler name
 
diff -Naur omniorb_41_branch_orig/idl/corbaidl.idl omniorb_41_branch_new/idl/corbaidl.idl
--- omniorb_41_branch_orig/idl/corbaidl.idl2010-10-11 22:43:09.334511122 +0300
+++ omniorb_41_branch_new/idl/corbaidl.idl2010-10-13 01:13:11.990614981 +0300
< at >< at > -73,9 +73,11 < at >< at >
 #endif
   typedef sequence<float>              FloatSeq;
   typedef sequence<double>             DoubleSeq;
+#ifndef DISABLE_LONGDOUBLE
 #ifdef HAS_LongDouble
   typedef sequence<long double>        LongDoubleSeq;
 #endif
+#endif
   typedef sequence<string>             StringSeq;
   typedef sequence<wstring>            WStringSeq;
 
diff -Naur omniorb_41_branch_orig/mk/beforeauto.mk.in omniorb_41_branch_new/mk/beforeauto.mk.in
--- omniorb_41_branch_orig/mk/beforeauto.mk.in2010-10-13 01:18:36.027617578 +0300
+++ omniorb_41_branch_new/mk/beforeauto.mk.in2010-10-13 01:47:49.339615274 +0300
< at >< at > -718,6 +718,10 < at >< at >
 NoStaticLibrary = 1
 endif
 
+ifeq (< at >ENABLE_LONGDOUBLE< at >,no)
+NoLongDouble = 1
+endif
+
 
 ###########################################################################
 #
diff -Naur omniorb_41_branch_orig/src/lib/omniORB/dir.mk omniorb_41_branch_new/src/lib/omniORB/dir.mk
--- omniorb_41_branch_orig/src/lib/omniORB/dir.mk2010-10-13 01:07:48.069617556 +0300
+++ omniorb_41_branch_new/src/lib/omniORB/dir.mk2010-10-13 02:02:30.616870659 +0300
< at >< at > -11,6 +11,12 < at >< at >
 SUBDIRS += dynamic codesets connections
 endif
 
+ifdef NoLongDouble
+OPT_DISABLE_LONGDOUBLE="-DDISABLE_LONGDOUBLE"
+else
+OPT_DISABLE_LONGDOUBLE=""
+endif
+
 EXPORTHEADERS = omniORB4/distdate.hh \
                 omniORB4/Naming.hh \
                 omniORB4/corbaidl_defs.hh \
< at >< at > -89,7 +95,7 < at >< at >
 
 omniORB4/corbaidl_defs.hh omniORB4/corbaidl_operators.hh omniORB4/corbaidl_poa.hh: corbaidl.idl
 < at >(dir=omniORB4; $(CreateDir))
-$(OMNIORB_IDL) -v -nf -P -WbF -ComniORB4 $<
+$(OMNIORB_IDL) -v -nf -P -WbF -ComniORB4 $(OPT_DISABLE_LONGDOUBLE) $<
 
 omniORB4/boxes_defs.hh omniORB4/boxes_operators.hh omniORB4/boxes_poa.hh: boxes.idl
 < at >(dir=omniORB4; $(CreateDir))
_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

autoreconf patch

Mika Laitio — 2010-10-11T19:55:56

Hi

I checked out the 4.1 svn branch in order to test crosscompilation for 
mips with openwrt toolchain.

Therefore I wanted to reconfigure everything by running these 3 commands 
from the openwrt makefile. (still working on for creating it)

 libtoolize --automake --force --copy
 autoreconf --force --install
 ./configure --prefix=/usr/local

autoreconf command will however give a following error:

configure:4489: error: possibly undefined macro: PKG_CONFIG_LIBDIR
       If this token and others are legitimate, please use 
m4_pattern_allow.
       See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

Attached patch fixes it, would it be possible to apply it?
Note, I noticed a similar type of patch has also been added to 
openembedded by somebody.

Mika


diff -Naur omniorb_41_branch_orig/configure.ac omniorb_41_branch/configure.ac
--- omniorb_41_branch_orig/configure.ac2010-10-11 22:17:59.552521620 +0300
+++ omniorb_41_branch/configure.ac2010-10-11 22:18:15.304538752 +0300
< at >< at > -10,6 +10,8 < at >< at >
 
 AC_CONFIG_HEADERS(include/omniORB4/acconfig.h)
 
+dnl to prevent error from autoreconf while crosscompiling
+m4_pattern_allow(PKG_CONFIG_LIBDIR)
 
 dnl ** CFLAGS / CXXFLAGS
 
_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

Suspicious omnithread problem

Christoph Becker — 2010-10-01T14:29:04

Hi,

my program got a core dump with signal 11 < at > omnithread lib. But I
don't know why:

#0  0x084baca9 in virtual thunk to
CosNotifyChannelAdmin::_impl_SupplierAdmin::_dispatch(omniCallHandle&)
() at /usr/include/omnithread.h:648
648static omni_thread::init_t omni_thread_init;

Any idea?

Cheers,
 Christoph

Linking libCOS against libomniDynamic on all platforms

Floris Bruynooghe — 2010-08-08T13:44:15

Hi

Attached is the patch I've made in Debian to link libCOS with
libomniDynamic and link libCOSDynamic with libCOS (in version 4.1.4).
Both these libraries use symbols from these libraries however the
default UNIX build did not bother resolving them because (I presume)
any application using them would be linking against these libs anyway.

Both AIX and Cygwin linkers where not happy with this and had
exceptions added to them however.  But it also turns out that the new
GOLD linker in GNU binutils is not too happy with leaving these
symbols not resolved either (though it's not a hard failure), see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558942.

So the attached patch does add the linking by default to any UNIX
platform.  Do you have any comments on this?  Is this a very bad idea
or is this something you'd accept upstream?  Is there a better way of
doing this?

Thanks
Floris

Modify omniORB to use blocking connect only

Haitham — 2010-08-03T18:29:20

Hi, 

I am trying to modify the implementation of omniORB so that it will use
blocking socket connect only, I modified the tcpAddress.c file but I am
still getting "Failed to set socket to non-blocking mode: " from the trace
file, my question is, is there any other place that I need to modify?

Regards
--Haitham

plcs orbs

PurencoolGmail — 2010-06-30T23:33:32

Hi all

Hi I am a software developer that has a love for linux. I am currently 
employed to
develop software for scada systems and have found that linux does not have a
opc server. I know that you can used corba like an opc server.
I have a quick question can omniorb achieve the same objective?

Find _invoke function

Haitham — 2010-06-24T13:42:40

Hello, 

I am trying to understand the implementation of omniORB, I have a problem of
finding _invoke function, which is in the following files  bootstrapSK.cc ,
irSK.cc, and  NamingSK.cc?


Thanks
--Haitham

String exceptions in cxx omniidl backend

Floris Bruynooghe — 2010-06-17T19:14:04

Hi

The cxx backend of omniidl still uses string exceptions, which no
longer work in Python 2.6 (that was a mistake, they where supposed to
work till 3.x but it's too late now).  These exceptions now raise a
TypeError, which for all practical purposes leaves most code working
since to catch string exceptions you pretty much have to catch all
exceptions anyway.  However it would still be good to get rid of them.

Before I prepare a patch I'd like to know if any of these exceptions
are governed by the OMG standards.  My guess is they aren't since they
only occur in the IDL backend, but I'm not an expert and don't feel
like reading the standards...

Cheers
Floris


PS: The execeptions (with slight offset due to previous version) are:

omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/ast.py:355
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/cxx.py:139
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/cxx.py:142
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/dynskel/typecode.py:375
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/impl/main.py:247
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/types.py:786
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/types.py:788
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/types.py:821
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/types.py:856
omniidl_4.1.3-1 E string-literal-exception /usr/share/pyshared/omniidl_be/cxx/util.py:248

'CORBA::LongDoubleSeq' has not been declared

adeeshah — 2010-06-15T15:15:05

Hi,

I am new in OmniORB. I have downloaded the ready built zip of OmniORB for
windows. I am using OmniORB on Windows Vista with MinGw. I created the stub
files using the omniidl.exe -bcxx. I am using Qt Creator IDE. My project
file looks like this,

# -------------------------------------------------
# Project created by QtCreator 2010-06-11T17:33:28
# -------------------------------------------------
TARGET = OMCcorba
TEMPLATE = app

# -------For OMNIorb
DEFINES += __x86__ \
 __NT__ \
 __OSVERSION__=4 \
 __WIN32__
LIBS += -LE:\Thesis\omniORB-4.1.4\bin\x86_win32 \
 -LE:\Thesis\omniORB-4.1.4\lib\x86_win32
INCLUDEPATH += E:\Thesis\omniORB-4.1.4\include

SOURCES += main.cpp \
    mainwindow.cpp \
    omc_communication.cpp
HEADERS += mainwindow.h \
    omc_communication.h 

#---------------------------------------------------------------------
#---------------------------------------------------------------------

I also created a Environment variable named OMNIORB_CONFIG that points to
E:\Thesis\omniORB-4.1.4\config directory.

I am getting the following error when i try to run my programme. Please see
below for compile output,

#--------------------------------------------------------------------------------------------
#---------------------------------------------------------------------------------------------
Running build steps for project OMCcorba...
Configuration unchanged, skipping QMake step.
Starting: E:/appl/Qt/2010.02.1/mingw/bin/mingw32-make.exe -w 
mingw32-make: Entering directory `E:/Thesis/OMCcorba'
E:/appl/Qt/2010.02.1/mingw/bin/mingw32-make -f Makefile.Debug
mingw32-make[1]: Entering directory `E:/Thesis/OMCcorba'
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE
-DQT_LARGEFILE_SUPPORT -D__x86__ -D__NT__ -D__OSVERSION__=4 -D__WIN32__
-DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN
-I"..\..\appl\Qt\2010.02.1\qt\include\QtCore"
-I"..\..\appl\Qt\2010.02.1\qt\include\QtGui"
-I"..\..\appl\Qt\2010.02.1\qt\include" -I"..\omniORB-4.1.4\include"
-I"..\..\appl\Qt\2010.02.1\qt\include\ActiveQt" -I"debug"
-I"..\..\appl\Qt\2010.02.1\qt\mkspecs\win32-g++" -o debug\main.o main.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE
-DQT_LARGEFILE_SUPPORT -D__x86__ -D__NT__ -D__OSVERSION__=4 -D__WIN32__
-DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN
-I"..\..\appl\Qt\2010.02.1\qt\include\QtCore"
-I"..\..\appl\Qt\2010.02.1\qt\include\QtGui"
-I"..\..\appl\Qt\2010.02.1\qt\include" -I"..\omniORB-4.1.4\include"
-I"..\..\appl\Qt\2010.02.1\qt\include\ActiveQt" -I"debug"
-I"..\..\appl\Qt\2010.02.1\qt\mkspecs\win32-g++" -o debug\mainwindow.o
mainwindow.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE
-DQT_LARGEFILE_SUPPORT -D__x86__ -D__NT__ -D__OSVERSION__=4 -D__WIN32__
-DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN
-I"..\..\appl\Qt\2010.02.1\qt\include\QtCore"
-I"..\..\appl\Qt\2010.02.1\qt\include\QtGui"
-I"..\..\appl\Qt\2010.02.1\qt\include" -I"..\omniORB-4.1.4\include"
-I"..\..\appl\Qt\2010.02.1\qt\include\ActiveQt" -I"debug"
-I"..\..\appl\Qt\2010.02.1\qt\mkspecs\win32-g++" -o
debug\omc_communication.o omc_communication.cpp
In file included from ..\omniORB-4.1.4\include/omniORB4/CORBA.h:518,
from omc_communication.h:6,
from omc_communication.cpp:3:
..\omniORB-4.1.4\include/omniORB4/dynAny.h:170: error:
'CORBA::LongDoubleSeq' has not been declared
..\omniORB-4.1.4\include/omniORB4/dynAny.h:190: error: ISO C++ forbids
declaration of 'LongDoubleSeq' with no type
..\omniORB-4.1.4\include/omniORB4/dynAny.h:190: error: invalid use of '::'
..\omniORB-4.1.4\include/omniORB4/dynAny.h:190: error: expected ';' before
'*' token
omc_communication.cpp:13: warning: '_0RL_library_version' defined but not
used
mingw32-make[1]: Leaving directory `E:/Thesis/OMCcorba'
mingw32-make: Leaving directory `E:/Thesis/OMCcorba'
mingw32-make[1]: *** [debug/omc_communication.o] Error 1
mingw32-make: *** [debug] Error 2
Exited with code 2.
Error while building project OMCcorba
When executing build step 'Make'
#---------------------------------------------------------------------------------------------
#---------------------------------------------------------------------------------------------

Please help me. Thanks,

Regards,
Adeel.

Python interceptors - no way to get peer identity -patch

Konstantin Olkhovskiy — 2010-06-10T10:27:54

Hello,
finally i managed to code it down... It should not break any existing code.
One should pass optional second boolean argument to
addServerReceiveRequest or addClientReceiveReply, i.e.:

interceptors.addServerReceiveRequest(validateCredentials, True)
interceptors.addClientReceiveReply(validateCredentials, True)

Sample validateCredentials might look like this:

def validateCredentials(op, contexts, peer_info):
 address = peer_info['address']
 identity = peer_info['identity']
 print "%s< at >%s" % (address, identity)


Patch is attached. Hope i didn't forget anything.
--
Cheers,
Konstantin Olkhovskiy
_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

Ping

Thomas Lockhart — 2010-04-15T01:21:22

It has been very quiet recently.

I've got updates for the RPM spec files to enable clean building on 
64-bit machines. What would be best to get them into the repository and 
next release?

Cheers.

                                 - Tom

[PATCH] signalMainThread interceptor

Felix Nawothnig — 2009-09-06T02:55:16

Here we go... I had some spare time to kill (well. actually I now have
this shiny embedded box sitting beside me and really wanted the feature
:-) and decided to not wait for you to reply on the main list - so here is
the implementation of the signalling callback as an interceptor. Feedback
is welcome.

Cheers,

Felix

_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

Unhandled Exception on Debug Mode

Alexander Duda — 2009-08-21T08:24:22

_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

Unhandled Exception on Debug Mode

Alexander Duda — 2009-08-21T08:24:22

_______________________________________________
omniORB-dev mailing list
omniORB-dev< at >omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev