Re: [mico-devel] CORBA Request Interceptor and Collector
On Wed, 14 Sep 2005, Brian Lindahl wrote: I need to generically intercept CORBA requests, queue them up until a connection can be made to the real server (intermittent connections) and then send the requests. The clients retrieve object references from a naming service and invoke methods statically. They expect an exception to be thrown when the connection is down (RequestPending). The objects on the 'intermittent' server are static implementations. OK, so you'd like to use this scheme? C P S | request-> | | | | | <-RequestPending- | | | | | | | | | | | |---request>| | | <---reply---| | | | | | where C is a client, P is an "invocation proxy" and S is a real target and the connection bettwen C and P is "persistent" while connection between P and S is "intermittent". What I don't understand on your scheme is the usage of RequestPending exception. The problem is: if P throws RP exc, then client receive it as a request reply and after processing it it basically removes all the structures kept by ORB for pending requests, hence P is not able to reply real reply obtained from the server. That's why I added to the picture above. Is this what do you expect from your system? When a connection to the 'intermittent' server is finally made, we pop 'Request' objects off the pending queue and call 'invoke' for each of them, recording any exceptions thrown (there are no return values, or 'out' values for these DII requests - they are ignored if they existed in the initial 'client' request). And what do you do with those recorded exceptions then? Are there any problems with this approach? Is there a better approach? Did I miss anything? I'm not sure I 100% understand motivations behind your design. Well, if the only issue is to make client communicate with server over the intermitent connections, then I would probably go different way, either: 1) using some kind of proxy which will manage connection to the target (validate_connection) and send the queued request when possible. Yes, client's will be blocked till the time P invokes real target and get appropriate reply or 2) using AMI in combination with proxy P, the result the same as above, but clients are not blocked. both ways support standard CORBA requet/reply scheme, hence client will receive all the required results of its request (result/inout/out/exceptions) and there is not a need to make the system complex by dividing processing of requests to client and replies to proxy as seems to be the case with your design. BTW: adding support for (1) to our ObjectWall[1] proxy daemon (our CORBA firewall implementation) shouldn't be that hard, if you are really interested in such system. Cheers, Karel [1]: a little bit out-dated flyer: http://www.objectsecurity.com/flyer/b4.pdf -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: RE: [mico-devel] CORBA Request Interceptor and Collector
On Thu, 15 Sep 2005, Brian Lindahl wrote: The mimic object works - generically tricking the client into thinking it supports the interface of the 'true' object and receives the invocation properly: DynamicImplementation::invoke(CORBA::ServerRequest_ptr) For this iteration of the scheme, I throw a 'ForwardRequest' exception at this point, which should forward the request onto the 'true' object. However, the exception is never caught and propogates back up to main() AND a segmentation fault occurs (not the desired behavior). My original assumption was that you can throw a 'ForwardRequest' from 'invoke', but apparently this not possible? One important detail: which main segfaults? This of mimic object server, so exception is not send to the wire or this of client process? I also hope you have exceptions enabled, don't you? What does `idl --config' says? Anyway, if everything is right on your side, then this is probably bug in MICO's DII code. Any patch fixing this is highly welcome! To fix it yourself, please have a look into dii.cc/poa_base.cc for DII related bits and to orb.cc/iop.cc for ForwardRequest related handling. Also please send your fix for review here. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: ***SPAM*** RE: RE: [mico-devel] CORBA Request Interceptor and Collector
On Fri, 16 Sep 2005, Brian Lindahl wrote: The segfault was due to a really obscure bug that I really don't have time to investigate - it involved wrapping initialization of the orb, and the mimic object in one try block and the "work_pending, perform work" in another try block. I didn't bother to investigate further as a work around was just to wrap the entire thing in one try block. It looks like the problem was in your code. Have you reviewed your _var type variables usage? Anyhow, it turns out my scheme won't work because in order for the ServerRequestInterceptor::receive_request to be called, you have to parse the arguments in the DynamicImplementation::invoke method, first. True, you definitelly need to use IR in case you're going to proxify using DSI/DII. As such, I've had to abandon this solution for a hard-coded non-generic solution (the other option being implementing TII or a GIOP server that goes low level to forward requests to different objects - both of which would involve too much time). And do you really need TII? Isn't siple callback-based AMI enough for your application? As I said, this shouldn't be that hard to implement... or you can even use DII and poll for replies periodicaly (kind of what AMI does) On a side note, apparently 'ForwardRequest' exceptions are not caught during invocation, but are only caught during Interceptor, ServantManager and ServantLocator upcalls. True, I've just checked the spec and it seems MICO is right here. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Second release candidate of MICO 2.3.12 is available for testing.
Folks, we are pleased to announce the second release candidate of MICO 2.3.12! You can download it here: http://www.mico.org/snapshots/mico-2.3.12RC1.tar.gz http://www.mico.org/snapshots/mico-2.3.12RC1.zip (only one of these two files is necessary) The list of changes since the first release candidate is below. Please test it on your platform and send success/failures reports to the mico-devel@mico.org mailing list (you need to be subscribed before sending anything there, if you are not subscribed and wouldn't like to be, please send your reports directly to me). Cheers, Karel - fix assert when generating IDL containing CORBA::Principal type (Heiko Jansen) - fix GIOPConn::initialize_reader_key method to initialize key only once - fix IDL compiler dependency builder for inheritance and circular dependency issue - fix name service to properly initialize Binding object returned from `next_one' operation - fix warning about missing virtual dtor by adding it to the GIOPConnMgr class - fix MICO::IIOPProxy::make_conn method memory leak w.r.t. profile cloning - fix CORBA::IOR::copy method to initialize active profile correctly - update certificates for test/mt/stress test - fix to serialise calls to gethostbyname/gethostbyaddr functions (issue reported by Jose Luu) - merge from Wireless MICO branch (Jaakko Kangasharju) - update MANIFEST file - update the Wireless TODO file - remove profile registration from LTP profile - remove the Wireless README file - remove --relative-paths from Wireless IDL compilation - create POA later in Wireless CORBA bridges - correct Bluetooth for non-wireless use -------- Karel Gardas, Principal Software Engineer, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS, UK Tel. +44 1223 420252, Fax. +44 870 762 6041 USA: Tel.+1-800-898-9148, Fax +1-360-933-9591 [EMAIL PROTECTED], www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] IDL generator bug (RE: NAMESPACES (MODULES) IGNORED WHEN COMPILING IDL GENERATED CODE)
Brian,
my bet is that, your idl file is `current.idl'. If this is true, then
there is no wonder that IDL compiler generates __CURRENT_H__ as an ifdef
mark. That's exactly how this should behave. If you have problem with it,
as you seem to have, then I would recommend renaming your own IDL file to
different name.
And no, prefixing ifdef mark with module name is not possible due to
nature of IDL which allows several modules to be defined inside one file.
Anyway, patch enhancing IDL compiler to generate postfix to ifdef mark
containing actual date (which is recommended practice for example in
boost) is welcome. e.g.
#ifndef __CURRENT_20050919205016_H__
#define __CURRENT_20050919205016_H__
[...]
#endif // __CURRENT_20050919205016_H__
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
On Thu, 1 Sep 2005, Brian Lindahl wrote:
The error I encountered earlier is due to a problem with the IDL tool
that generates code from the .idl documents. The include protection
(#ifdef __CURRENT_H__) in the generated include file doesn't add the
namespace (module). For example:
/ IDL FILE ***/
#ifndef SPDV_Current_idl
#define SPDV_Current_idl
module SPDV
{
struct Current
{
double value;
};
};
#endif
/ GENERATED INCLUDE PROTECTION
***/
#ifndef __CURRENT_H__
#define __CURRENT_H__
The generated include protection should be: '__SPDV_CURRENT_H__', not
'__CURRENT_H__'. The result of this error means that, in the same source
file, you cannot use the same IDL-generated symbols (class/struct names)
even if they are differentiated by namespaces, because the generated
include protection won't allow both '.h' files to be included.
Brian Lindahl
Spacecraft Software Engineer
858-375-2077
[EMAIL PROTECTED]
SpaceDev, Inc. <http://www.spacedev.com/>
"We Make Space Happen"
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
RE: [mico-devel] Second release candidate of MICO 2.3.12 is availablefor testing.
-- Forwarded message -- Date: Mon, 19 Sep 2005 19:08:37 +0530 From: "Polimera, Amareswar R (GE Energy, Non GE)" <[EMAIL PROTECTED]> To: Karel Gardas <[EMAIL PROTECTED]> Subject: RE: [mico-devel] Second release candidate of MICO 2.3.12 is availablefor testing. Hello Karel, Sorry for disturbing you once again. we are using AIX 5.3 and Mico version is 2.3.12. I am currently the member of the group you specified. Thanking you, Amareswar Reddy. I would suggest you to subscribe to mico-devel@mico.org mailing list here: http://www.mico.org/mailman/listinfo/mico-devel and post your question there. Also please do not forget that for solving this issue we will need to know more information about your platform: 1) which AIX version do you use 2) which compiler and exact version do you use 3) how (which options) do you configure MICO Thanks for using MICO! Karel On Mon, 19 Sep 2005, Polimera, Amareswar R (GE Energy, Non GE) wrote: Hi I am new to CORBA and I am encountering a problem while installing corba on AIX OS. it is telling that _isnanl and _isinfl have no reference found in the resuective modules. Can you please suggest me any solutions to get installation smooth. Thanks in advance, Amareswar Reddy. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: RE: [mico-devel] Second release candidate of MICO 2.3.12 is availablefor testing.
On Mon, 19 Sep 2005, Karel Gardas wrote: -- Forwarded message -- Date: Mon, 19 Sep 2005 19:08:37 +0530 From: "Polimera, Amareswar R (GE Energy, Non GE)" <[EMAIL PROTECTED]> To: Karel Gardas <[EMAIL PROTECTED]> Subject: RE: [mico-devel] Second release candidate of MICO 2.3.12 is availablefor testing. Hello Karel, Sorry for disturbing you once again. we are using AIX 5.3 and Mico version is 2.3.12. I am currently the member of the group you specified. Hello, as I've already written, we also need to know exact compiler version you use to compile MICO! Anyway, I've cced Nikolay Logvinov who is our AIX/VisualAgeC++ platform maintainer, who in case you use VisualAge C++ compiler might help you with your configure issue. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- Thanking you, Amareswar Reddy. I would suggest you to subscribe to mico-devel@mico.org mailing list here: http://www.mico.org/mailman/listinfo/mico-devel and post your question there. Also please do not forget that for solving this issue we will need to know more information about your platform: 1) which AIX version do you use 2) which compiler and exact version do you use 3) how (which options) do you configure MICO Thanks for using MICO! Karel On Mon, 19 Sep 2005, Polimera, Amareswar R (GE Energy, Non GE) wrote: Hi I am new to CORBA and I am encountering a problem while installing corba on AIX OS. it is telling that _isnanl and _isinfl have no reference found in the resuective modules. Can you please suggest me any solutions to get installation smooth. Thanks in advance, Amareswar Reddy. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] 2.3.11 compile problems on Solaris
Hello, first of all, I would highly recommend you to test MICO 2.3.12 RC1, downloadable from here: http://www.mico.org/snapshots/ And If there are any problems, please report them here. Also if the issue it a compilation error, then please do not forget to post copy of the error together with your message. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Mon, 19 Sep 2005, Donald Dade wrote: Hello list, Are there any known issues with 2.3.11 on Solaris with gcc 3.3.4? When I configure with --enable-threads --enable-pthreads, I get compile errors in os-threads.cpp. A different but similar error when I configure with --enable-solaris-threads. I can post the exact error message soon; I am recompiling now. I can easily switch gcc versions, but has anyone else encountered this? Thank you, Don ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] 2.3.11 compile problems on Solaris
Short question: which Solaris version do you use? Could you be so kind and ensure that it support POSIX reader-writter mutexes? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Mon, 19 Sep 2005, Donald Dade wrote: Dear list, I configured like this: ./configure --prefix=/usr/local/mico-2.3.11 --enable-threads --enable-pthreads --without-x And here is the error from compiling with gcc-3.3.4 on solaris: c++ -I../include -O2 -Wall -D_REENTRANT -DPIC -fPIC -c os-unix.cc -o os-unix.pic.o In file included from ../include/mico/os-thread.h:116, from ../include/CORBA.h:159, from ../include/CORBA-SMALL.h:52, from os-unix.cc:34: ../include/mico/os-thread/pthreads.h:402: error: 'pthread_rwlock_t' is used as a type, but is not defined as a type. ../include/mico/os-thread/pthreads.h: In member function `void MICOMT::RWLock::rdlock()': ../include/mico/os-thread/pthreads.h:366: error: `_rwlock' undeclared (first use this function) ../include/mico/os-thread/pthreads.h:366: error: (Each undeclared identifier is reported only once for each function it appears in.) ../include/mico/os-thread/pthreads.h:366: error: `pthread_rwlock_rdlock' undeclared (first use this function) ../include/mico/os-thread/pthreads.h: In member function `void MICOMT::RWLock::wrlock()': ../include/mico/os-thread/pthreads.h:382: error: `pthread_rwlock_wrlock' undeclared (first use this function) ../include/mico/os-thread/pthreads.h: In member function `void MICOMT::RWLock::unlock()': ../include/mico/os-thread/pthreads.h:398: error: `pthread_rwlock_unlock' undeclared (first use this function) make.3.77[1]: *** [os-unix.pic.o] Error 1 make.3.77[1]: Leaving directory `/export/home/v605909/scheduler.threadsafe/mico/orb' make.3.77: *** [system] Error 1 Thanks to any and all... Don - Original Message From: Karel Gardas <[EMAIL PROTECTED]> To: Donald Dade <[EMAIL PROTECTED]> Cc: mico-devel@mico.org Subject: Re: [mico-devel] 2.3.11 compile problems on Solaris Date: 19/09/05 17:57 Hello, first of all, I would highly recommend you to test MICO 2.3.12 RC1, downloadable from here: http://www.mico.org/snapshots/ And If there are any problems, please report them here. Also if the issue it a compilation error, then please do not forget to post copy of the error together with your message. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Mon, 19 Sep 2005, Donald Dade wrote: > Hello list, > > Are there any known issues with 2.3.11 on Solaris with gcc 3.3.4? > > When I configure with --enable-threads --enable-pthreads, I get compile > errors in os-threads.cpp. A different but similar error when I configure > with --enable-solaris-threads. I can post the exact error message soon; I am > recompiling now. > > I can easily switch gcc versions, but has anyone else encountered this? > > Thank you, > > Don > > ___ > Mico-devel mailing list > Mico-devel@mico.org > http://www.mico.org/mailman/listinfo/mico-devel > ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Re: [Qedo-devel] Second release candidate of MICO 2.3.12 is available for testing.
On Tue, 20 Sep 2005, Tom Ritter wrote: Karel Gardas wrote: Dear Tom, yes, providing pthreads libs is part of our plan to better support threading on MS Windows platform. Please note that threading is enabled on by default in the recent MICO and to keep it this way is also our intention for 2.3.12 release. So for all Win32/VC++ users: please test that MICO builds automatically and smooth with threading enabled. Hint: use `idl --config' to see if the compiled MICO is multi-threaded or not. Dear Karel, I tried to build a Debug version of MICO. I have seen that PThread support is not beeing built in debug version but in release version. Mixing Debug and release versions causes run-time check errors with microsoft compiler. I have made debug version of Pthread by hand and encountered another problem. At the moment I'm not really sure what the problem is, but it is again a debug version problem since there is an assert at closing connections. Is Sorin still the maintainer for Windows version? Does he plan to work on Debug version for 2.3.12? Dear Tom, yes, Sorin is our Win32 port maintainer and he is the author of the framework which allowed to automatically enable pthread support on Windows. Perhaps you guys can both discuss this issue on mico-devel@mico.org mailing list? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] CSIv2
On Fri, 23 Sep 2005, Arnold Mingin wrote: Hello, I wrote here some time ago about security, didn't know how to do authorization. After spending some time walking through CSIv2 code I patched it a little bit so that it could provide functions from within the application like: knowing current user, adding/removing users and changing client user. I totally understand that this is not according to the standard, but I just wanted to ask, will it work at all... Since now it SEEMS to be working. I would also recommend you to give OpenPMF a try: http://www.objectsecurity.com/openpmf/openpmf.html At least it contains MICO SL3 project which is basically API created for CSIv2. The patch is the following: csiv2.idl, csiv2_impl.cc, csiv2_impl.h: Added func. add_server_user to local interface SecurityManager (this function is already in csiv2_impl.cc, so I just added it to IDL and "const" to arguments); Added func. remove_server_user (just like add_server_user); Added attr. current_user (read only, just returns current_user_ whici is set in auth_token function, implemented in csiv2_impl.cc); Added func. client_user (change css_user_ and css_passwd_); I didn't know nothing about multithreading usage of this class, so I added MICO::RWLock to all above functions and also in: CSIv2::SecurityManager_impl::get_gss_init_token (just around the part where css_*_ is read); CSIv2::SecurityManager_impl::auth_token (around the for-loop of finding user); Could you please tell me, will it work OK, especially current_user? Usage in the application is through getting initial reference of CSIv2SecurityManager. If some could explain me how to use "patch" I can send the code here. For sending diff, you need to use diff -u command. Anyway, MICO already support API for CSIv2 in the form of SL3 project which will be merged in shortly after MICO 2.3.12 release. So I'm not going to add yet another un-common API if there is no strong demand for it. FYI: SL3 API was specified by Adiron: http://www.adiron.com/products.html We've just made minor modifications which makes it better IMHO and more simple. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Compilation on Cygwin fails
On Mon, 26 Sep 2005, Patrick Gräbel wrote: Hi, the INSTALL.txt of version 2.3.11 instructs to use the standard Unix procedure for compilation and installation. ./configure succeeds with creating config.h, but make gets stuck. It seems that Cygwin's math.h/cmath does not provide the required asinl-function: ../include/mico/os-math.h:413: error: `asinl' undeclared (first use this function) ../include/mico/os-math.h:413: error: (Each undeclared identifier is reported only once for each function it appears in.) I always running an updated Cygwin environment, currently using gcc 3.4.4. What am I doing wrong? Do I have to use older versions of the compiler and/or Mico? Could you be so kind and let us know if when you use gcc 3.3.x, you are or not able to compile MICO? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- ---___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Problem with nested OBV
Hi,
please provide as simple as possible test-case. I'd like to see if I can
duplicate the issue here and wouldn't like to waste time with writting the
test when you probably do have one already written.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
On Tue, 27 Sep 2005, Valentino Ignoti wrote:
Hi EveryBody. We have a CORBA::MARSHAL_EXCEPTION when trying to send (as
IN) a NESTED valuetype (OBV) from JDK orb (1.4.2_08) to mico ORB (2.3.11)
It seems to be that mico ORB doesn't decode propertly "chunked value-tag".
In all other cases it works fine :
jdkORB->micoORB KO
jdkORB< micoORB OK
jdkORB> jdkORB OK
micoORB < micoORB OK
see down the idl:
valuetype Nested {
public long n;
}
valuetype Base {
public Nested nested;
}
interface ObvService {
void sendNested( in Base b);
}
--
Thanks for all...Any help is appreciate regards...
p.s. we register both factories obviously ;-)
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Solaris 2.6 incompatible with threaded 2.3.11
Hello, On Fri, 30 Sep 2005, Donald A. Dade wrote: A follow-up to some investigating I've done into ny Solaris 2.6 problem with 2.3.11: 1) I tried compiling 2.3.11 with --enable-threads --enable-pthreads and gcc 2.95.2, 3.3.2, and 3.4.4 with no success because apparently 2.6 has no support for POSIX read/write locks. yes, MICO depends on POSIX read-write locks. 2) I tried those same compilers with --enable-threads --enable-solaris-threads, also to no avail because there were a lot of compile errors due to the MICO namespace. solaris threads are probably completely broken. In fact I've never seen them running, since solarises which I have access to, all supported RW locks well and so we used POSIX by default. 3) Compiling without threads worked fine, but my app always gets TRANSIENT failures whenever I compile with -DREENTRANT, regardless of wether I actually have multiple threads in the program or even if I have multiple threads, but only one that interacts with the orb. that's interesting, since this point to probably broken transport or IOP layer. For debugging you can find -ORBDebug GIOP -ORBDebug IIOP useful. If I can find the time, I'll fix it, but for now, I think Solaris 2.6 should be taken off of the compatibility list for multi-threaded 2.3.11 if it were ever explicitly on it. If you need multi-threading and if you really prefer SunOS 5.6, then I would recommend you to write RW lock on top of POSIX mutex. We can also do it for you under the contract agreement if you prefer this way. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] MICO 2.3.5: Callbacks not getting executed
On Fri, 30 Sep 2005, Anjani Achanta wrote: Hi, We have developed a POA based CORBA server application running on a Solaris 2.8 platform, executing callbacks for a client running on the same node and for a client running on Windows 2000 platform. The CORBA server is the gateway for data exchange between other applications running on Windows and Solaris platforms. Once all the applications are started, all the comunication happens smoothly between the server and the two clients [24x7]. Occasionally, [once in 5 days or 10 days] we observed that the callbacks are not getting executed. We observed that the server is processing the requests from client but failing to execute the callback [ netstat -na, snoop and truss commands showed the data did reach the server] What are the circumstances under which server can lose the callback info? We haven't noticed any memory leaks in our server application. The interface functions are specified as oneway in IDL file as we can't block the calls to and from server (this will have adverse affect on other applications). The version of MICO we are using is 2.3.5 and we are using IOR ( ior file is copied to client node automatically) based object reference mechanism. This release is really out-dated now. Could you be so kind and give 2.3.12RC1 a try? You can download it here: http://www.mico.org/snapshots/ IIRC MICO does not throw received oneway calls away even under the load, so they should be executed well. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] mico2.3.11 multithread problem ??
On Mon, 3 Oct 2005, Rafal Kosiuk wrote: ORB::wait for 0x807b7f8 In Data 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 $... 00 00 00 00 00 00 00 00 ^ This is not CORBA message. Are you sure you send correct message back? IIOP: incoming data from inet:rad133.radmor.com.pl:34165 GIOP: cannot decode incoming header from inet:rad133.radmor.com.pl:34165 Out Data 47 49 4f 50 01 00 01 06 00 00 00 00 GIOP GIOPCodec::~GIOPCodec: 0x808b180 pure virtual method called ^^ And here you crash, please use debugger to get more information about it. The same code but without thread work correctly under QNX, and corretly (with thread) under linux (Slackware current && gcc-3.3.6). Has anyone some idea what happend ?? So the problem might be 1) in your application threading, 2) in QNX threading & transport or 3) somewhere else. Also it might be interesting to see if 2.3.12RC1 provides the same results. The code was compilled with : mico2.3.11 (without MT), QNX6.3.0, platform x86, qccV3.3.1,gpp_ntox86_gcc The problem is QNX is not officially supported OS. Have you for example tried to run full MICO testsuite including demos and see what regressions you get on this platform in comparison with reference platforms? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] interceptors
On Sat, 8 Oct 2005, Ali Nikzad wrote: Hi every one, Is there any implementation of interceptor available in MICO? Yes, please use portable interceptors instead of deprecated traditional interceptors. And please use 2.3.12RC1 or upcomming 2.3.12 release. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: ***SPAM*** [mico-devel] Make fails on Cygwin (idl tool aborts)
Patrick, Joost is MICO maintainer for Cygwin platform. If I recall correctly he claimed Cygwin's pthreads implementation is somewhat strange and does not work reliable. Joost, is this right? As a workaround I suggest to disable threading by using --disable-threads configure command-line option. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Sat, 22 Oct 2005, Patrick Gräbel wrote: Hi! The Cygwin make process produces an error (MICO 2.3.12rc1): the idl tool aborts with an assertion message. I am using the most recent gcc 3.4.4 for Cygwin. Any idea what caused this crash or how to solve this issue? I did not succeed in compiling MICO on Cygwin for weeks now, but it seems that I am getting closer to a set of running binaries. I am also using MICO with .NET 2003 VC, which compiled successfully and works fine. Here is the detailed output of gcc/Cygwin: ./make ... c++ -I. -I../include -O2 -DBUILD_MICO_DLL -Wall -D_REENTRANT -L../orb imr_ client.o -lmico2.3.12RC1 -lssl -lcrypto -lm -lpthread -o imr true imr make[1]: Leaving directory `/cygdrive/j/mico12rc1/daemon' make[1]: Entering directory `/cygdrive/j/mico12rc1/auxdir' make[1]: Nothing to be done for `prg'. make[1]: Leaving directory `/cygdrive/j/mico12rc1/auxdir' make[1]: Entering directory `/cygdrive/j/mico12rc1/coss' for i in naming events property time; do make -C $i idlcompile || exit 1; done make[2]: Entering directory `/cygdrive/j/mico12rc1/coss/naming' /cygdrive/j/mico12rc1/./idl/idl -B../.. --c++-skel --name CosNaming \ ../../include/coss/CosNaming.idl assertion "!result" failed: file "os-thread/pthreads.cc", line 360 make[2]: *** [CosNaming.cc] Aborted (core dumped) make[2]: Leaving directory `/cygdrive/j/mico12rc1/coss/naming' make[1]: *** [idlcompile] Error 1 make[1]: Leaving directory `/cygdrive/j/mico12rc1/coss' make: *** [system] Error 1 Patrick Graebel ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Problem with Callback
Hi, please try to duplicate this issue on 2.3.12 RC1 (http://mico.org/snapshots/) and if you are successful, then please send me privately as simple as possible testcase preferably including makefile for linux/unix platform. Thanks, Karel On Tue, 15 Nov 2005, Himanshu Malla wrote: Hi All, I'm new to CORBA. I'm using MICO version 2.3.11. I have a client exe which instantiates a callback object and provides the reference to a server function through server reference . After the Call Back Object function is called by the Server , the client exits calling the orb->destroy function from the executable. This works fine for the first time. When i execute the client exe again(on the same machine where i had ran the client exe previously) the Server Executable exits with segmentation fault during the call back execution. If i comment the orb->destroy() in the client the client and server are working properly. But it may be leaking. The client is created with TRANSIENT and USER_ID POA Policies. Nothing else is being set in the client side other than these. In the server i am using "RootPOA" The stack Trace and error in GDB during segmentation fault of Server are as follows #0 0xb734a4ce in std::_Rb_tree, std::_Select1st >, MICO::IIOPProxy::addrcomp, std::allocator > >::find(CORBA::Address const* const&) () from /usr/local/lib/libmico2.3.11.so #1 0xb7340e9e in MICO::IIOPProxy::make_conn(CORBA::Address const*, unsigned char, unsigned short) () from /usr/local/lib/libmico2.3.11.so #2 0xb7341830 in MICO::IIOPProxy::make_conn(CORBA::Object*) () from /usr/local/lib/libmico2.3.11.so #3 0xb7341ea2 in MICO::IIOPProxy::invoke(CORBA::ORBInvokeRec*, CORBA::Object*, CORBA::ORBRequest*, CORBA::Principal*, unsigned char) () from /usr/local/lib/libmico2.3.11.so #4 0xb7318fb1 in CORBA::ORB::invoke_async(CORBA::Object*, CORBA::ORBRequest*, CORBA::Principal*, unsigned char, CORBA::ORBCallback*, CORBA::ORBInvokeRec*) () from /usr/local/lib/libmico2.3.11.so #5 0xb7364a2e in CORBA::StaticRequest::invoke() () from /usr/local/lib/libmico2.3.11.so #6 0x0805626a in ABCInterface::ABCClient_stub::createABCSessionCb(ABCInterfaceDefs::CreateABCSessionResult const&) () #7 0x0805d519 in ABCServer_impl::createABCSession(long, long, char const*, char const*, char const*) () #8 0x0805a0c9 in POA_ABCInterface::ABCServer::dispatch(CORBA::StaticServerRequest*) () #9 0x0805a8dc in POA_ABCInterface::ABCServer::invoke(CORBA::StaticServerRequest*) () #10 0xb73b4fa6 in PortableServer::StaticImplementation::doinvoke(CORBA::ServerRequestBase*) () from /usr/local/lib/libmico2.3.11.so #11 0xb73c79a2 in MICOPOA::POA_impl::perform_invoke(MICOPOA::POA_impl::InvocationRecord*) () from /usr/local/lib/libmico2.3.11.so #12 0xb73c6ec4 in MICOPOA::POA_impl::local_invoke(MICOPOA::POA_impl::InvocationRecord*) () from /usr/local/lib/libmico2.3.11.so #13 0xb73c66a6 in MICOPOA::POA_impl::invoke(CORBA::ORBInvokeRec*, CORBA::Object*, CORBA::ORBRequest*, CORBA::Principal*, unsigned char) () from /usr/local/lib/libmico2.3.11.so #14 0xb7318fb1 in CORBA::ORB::invoke_async(CORBA::Object*, CORBA::ORBRequest*, CORBA::Principal*, unsigned char, CORBA::ORBCallback*, CORBA::ORBInvokeRec*) () from /usr/local/lib/libmico2.3.11.so #15 0xb73475f8 in MICO::IIOPServer::exec_invoke_request(MICO::GIOPInContext&, CORBA::Object*, CORBA::ORBRequest*, CORBA::Principal*, unsigned char, MICO::GIOPConn*, CORBA::ORBInvokeRec*) () from /usr/local/lib/libmico2.3.11.so #16 0xb734791e in MICO::IIOPServer::handle_invoke_request(MICO::GIOPConn*, MICO::GIOPInContext&) () from /usr/local/lib/libmico2.3.11.so #17 0xb7346e5b in MICO::IIOPServer::handle_input(MICO::GIOPConn*, CORBA::Buffer*) () from /usr/local/lib/libmico2.3.11.so #18 0xb734916f in MICO::IIOPServer::input_callback(MICO::GIOPConn*, CORBA::Buffer*) () from /usr/local/lib/libmico2.3.11.so #19 0xb733e0f0 in MICO::GIOPConn::do_read(unsigned char) () from /usr/local/lib/libmico2.3.11.so #20 0xb733f204 in MICO::GIOPConn::callback(CORBA::Transport*, CORBA::TransportCallback::Event) () from /usr/local/lib/libmico2.3.11.so #21 0xb7331d25 in MICO::SocketTransport::callback(CORBA::Dispatcher*, CORBA::Dispatcher::Event) () from /usr/local/lib/libmico2.3.11.so #22 0xb72faf0b in MICO::SelectDispatcher::handle_fevents(fd_set&, fd_set&, fd_set&) () from /usr/local/lib/libmico2.3.11.so #23 0xb72fb959 in MICO::SelectDispatcher::run(unsigned char) () from /usr/local/lib/libmico2.3.11.so #24 0xb7315510 in CORBA::ORB::run() () from /usr/local/lib/libmico2.3.11.so #25 0x0805e50c in testFun(void*) () #26 0xb75d0dac in start_thread () from /lib/tls/libpthread.so.0 #27 0xb6fde9ea in clone () from /lib/tls/libc.so.6 Could anybody tell me, how to fix this problem. Any specific POA policies need to be set ?? I need to call the client exe to be executed again and again Thanx in advance. Himanshu. -- Karel Gardas [EMAIL PROTECT
Re: [mico-devel] firewall/range of port numbers
Hi Claus, On Fri, 18 Nov 2005, [EMAIL PROTECTED] wrote: Hi All, A client wants to communicate through a firewall to my MICO server. In order not to open all ports, but a range of ports, I want to restrict the choice of port numbers in the server to a particular range. Is this possible? yes, it is possible. Basically you do have two ways: 1. you can purchase our ObjectWall which is nice IIOP-based firewall based on MICO core. We've developed it exactly for scenarios like yours. If you are interested to know more, please let me know off-list and I will send you ObjectWall feature list. 2. the second way is that you can attempt to write something like we did for ObjectWall. Be warned that you need to be high-hearted and that you will also learn quite a lot from not so used CORBA API. Odd thing to talk about "ports" in conjunction with CORBA :-). Ports are just ports! The funny thing starts when you start talking about multi-home firewalls, callbacks and reverse processing. :-) Cheers, Karel -------- Karel Gardas, Principal Software Engineer, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS, UK Tel. +44 1223 420252, Fax. +44 870 762 6041 USA: Tel.+1-800-898-9148, Fax +1-360-933-9591 [EMAIL PROTECTED], www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: ***SPAM*** [mico-devel] MICO 2.3.11problem communicating with JavaIDL
On Sun, 13 Nov 2005, Kevin Batchelor wrote: I am trying to get a MICO client to communicate with JavaIDL. I have had no luck. I start orbd with the following command. orbd -ORBInitialPort 2050 Then I start my Java server. java NameAddressServer -ORBInitRef NameService=corbaloc:iiop:[EMAIL PROTECTED]:2050/NameService It appears to be running correctly. Next I start my MICO client. ./client -ORBInitRef NameService=corbaloc:iiop:[EMAIL PROTECTED]:2050/NameService It to appears to run correctly, but when the client tries to invoke a remote object method, the client crashes. If your MICO-based client crash, please let us known at least backtrace of the crash and full client source code to see if the issue is in MICO itself or somewhere else. Does anyone have any ideas or know of any known issues between javaIDL and MICO? If you mean JDK ORB, then no, at least recent versions of Sun's CORBA are compliant enough to work well. You just need to be prepared that JDK ORB is not that "robust" as others are and so you will for example need to use some other options if you use MICO on server side. Anyway, MICO-based client should work just fine IIRC. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Dear MICO!
On Wed, 9 Nov 2005, Analyzer wrote:
Dear MICO!
I'm currently developping an application in this environment : patform solaris 2.8
& mico.2.3.11.
(using TMF814 v2.0 recomendations)
I have a problem in running my program.
This is what occurs when launched :
$> static.cc:698: failed assertion `(*(_MICO_T *)v)->_ior()'
$> Abort - core dumped
some sources :
[...]
NmsSession_I_impl *client = new NmsSession_I_impl();
EmsSession_I_var emsSessionInterface;
try { EmsSessionFactory_I_var emsSessionFactory =
EmsSessionFactory_I::_narrow (obj);
here is a check for emsSessionFactory missing! You can use something like:
assert(!CORBA::is_nil(emsSessionFactory));
for development.
emsSessionFactory->getEmsSession("userName","TuserPass", client,
emsSessionInterface);
^^
also here, you seems to invoke remote operation, but do not pass CORBA
object!
May I recommend you to read some nice book about CORBA? Although a bit
old, Henning's&Vinoski's Advanced CORBA programming with C++ is still
great.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Segfault
Hi, first of all, please try: http://www.mico.org/snapshots/mico-2.3.12RC1.tar.gz and let us know if it fixes or not your issues. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Thu, 24 Nov 2005, M. Schatzl wrote: Hi, we (want to) use MICO within a plugin for a proprietary graphics application (Tecplot). This plugin serves the purpose of providing an online-interface to an object in Tecplot, that we want to transfer to our own application. Well, with a former version of MICO (2.3.9) everything worked fine. But it doesn't anymore with 2.3.11. I verified that all of the CORBA/MICO code constructs actually work, so I really cannot imagine where the problem lies here. Could be MICO as well as the other application. Our first guess was that it would have to do with multithreading issues, since the symptoms looked like races. E.g. sometimes the plugin gets loaded and spits out an IOR, another time it doesn't load at all... Can anybody offer an educated guess about whats going on here? Thanks very much in advance, /Markus ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Third release candidate of MICO 2.3.12 is available for testing.
Folks, we are pleased to announce the third release candidate of MICO 2.3.12! You can download it here: http://www.mico.org/snapshots/mico-2.3.12RC2.tar.gz http://www.mico.org/snapshots/mico-2.3.12RC2.zip (only one of these two files is necessary) The list of changes since the second release candidate is below. Please test it on your platform and send success/failures reports to the mico-devel@mico.org mailing list (you need to be subscribed before sending anything there, if you are not subscribed and wouldn't like to be, please send your reports directly to me). Cheers, Karel - fix IIOPServer to not break from do_read loop prematurely - update MANIFEST file - fix configure for FreeBSD 6 and shared libraries test - fix wrong variable name in IDL definition of PI (IOP::ServiceId -> IOP::ServiceID) (Tom Ritter) - fix possible race-condition (crash) on server side while receiving GIOP connection close message - fix assert while receiving GIOP close connection message when thread-per-connection CM is used - fix ServerRequestInfo::target_most_derived_interface operation for servant locator usage - fix crash on client side while receiving GIOP connection close message ---- Karel Gardas, Principal Software Engineer, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS, UK Tel. +44 1223 420252, Fax. +44 870 762 6041 USA: Tel.+1-800-898-9148, Fax +1-360-933-9591 [EMAIL PROTECTED], www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] valuetype::demarshal problems
Short question: have you registered your valuetype factory on both sides?
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
On Tue, 29 Nov 2005, Bob Gunion wrote:
This may have more to do with my limited understanding of valuetypes than with
mico, but I've been banging my head against this for a couple of days and need
some more expert input (read: I'm almost out of aspirin). I ran this test on
three development environments, all with the same results:
- micoo 2.3.12RC2, gcc 3.4.4, RedHat Linux 9
- mico 2.3.7, gcc 3.2.1, RedHat Linux 7
- mico 2.3.11, VC++7, Win2k
I've attached my test code, but here's a summary of what's happening:
Using this idl:
module test {
valuetype testvalue {
public long ival;
long foo();
};
interface testinterface {
testvalue getValue();
any getAny();
long dofoo();
};
};
The server side is straightforward. I'm trying to do this on the client side:
(Get a CORBA::Object_var obj..)
testinterface_var intfc = testinterface::_narrow(obj);
if (CORBA::is_nil(intfc)) {
cerr << argv[0] << ": can't narrow testinterface" << endl;
return -1;
}
CORBA::Any_var any = intfc->getAny();
testvalue_impl * pCValue = new testvalue_impl(999);
test::testvalue_var tv = pCValue;
if (any >>= tv) { <<<<<<<<<<<<<<<<<<<<< ERROR!
printf("%s: Extracted the any. ival = %d, foo = %d\n",
argv[0],
pCValue->ival(),
pCValue->foo());
} else {
cerr << argv[0] << ": Failed to extract the any" << endl;
return -1;
}
return 0;
When I try to extract the testvalue from the any, I get a CORBA::Marshal
exception. I've tried using DynAny to parse the any, and that works but is
very clumsy. So I know the correct information is in the any but I can't
extract it.
Using gdb, I got a backtrace of the error. Everything looks fine up to this
point in the c++ code generated from idl:
::CORBA::Boolean _Marshaller_testvalue::demarshal( ::CORBA::DataDecoder &dc,
StaticValueType v ) const
{
::CORBA::ValueBase* vb = NULL;
if (!::CORBA::ValueBase::_demarshal (dc, vb, "IDL:testvalue:1.0")) { <<<<<<
ERROR!
return FALSE;
}
::CORBA::remove_ref (*(_MICO_T *)v);
*(_MICO_T *)v = ::testvalue::_downcast (vb);
if (vb && !*(_MICO_T *)v) {
::CORBA::remove_ref (vb);
return FALSE;
}
return TRUE;
}
The CORBA::ValueBase::_demarshal function takes a const std::string reference
as the third parameter. But according to gdb, the third parameter becomes a
reference to a null pointer. Is gdb lying to me, or is something else
happening here? I admit I have minimal experience with gdb, but I also tried
creating my own test function like this:
long strtestfn(const std::string& str) {
printf("In strtestfn: %s\n", str.c_str());
return 42;
}
int main(int argc, char * argv[]) {
long result = strtestfn("Hello");
}
.. and this worked without problems. So I'm stumped. Please help!
(Note: Here's the big picture: I'd like to deliver valuetypes using the event
service, so I could have all the data passed like a struct, and in rare cases
also have functions I could call to get more info from the server. Maybe I
could accomplish the same thing by having an object reference in my struct, and
only call methods on that object in those rare cases. Thoughts?)
Thanks, and keep up the great work on mico!
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] MICO 2.3.11 and Solaris9/JavaIDL component
On Mon, 28 Nov 2005, Bruno Le Fellic wrote: So, my questions: - Why JavaIDL NameService (orbd) do resolve my component path, but the return failed ? It seems you've made assumption that orbd == name service, but IIRC this is not true. - Where can I have some logs or exception report of MICO.. ? (I've got no other error at all than in my client program) Please have a look at -ORBDebug option and use appropriate parameter for your intended debugging. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Server crashes when clients disconnect
On Thu, 1 Dec 2005, PERKINS Tyler wrote: #4 0xc28b6d0c in __PureVirtualCalled () from /usr/lib/libCsup_v2.2 #5 0xc9ec4a54 in CORBA::Transport::read () from /work/vkononen/core/lib/libmico2.3.11.sl #6 0xc9ef766c in MICO::GIOPConn::do_read () from /work/vkononen/core/lib/libmico2.3.11.sl #7 0xc9ee9b54 in MICO::GIOPConnReader::_run () from /work/vkononen/core/lib/libmico2.3.11.sl This issue should be already fixed in MICO 2.3.12 RC2[1]. Please give it a try and report success or failure to this mailing list. Cheers, Karel [1]: http://www.mico.org/snapshots/ -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] event channel
On Sat, 3 Dec 2005, Alireza khalilipour wrote: Dear friends, I want documents about event service or event channel in Mico. What must I do? Probably download the spec? http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Crash in eventd
On Mon, 19 Dec 2005, Chris Wareham wrote: I'm experiencing regular crashs in the MICO eventd daemon. The following is a stacktrace from the core dump: #0 0xfe59fc3c in _libc_kill () from /usr/lib/libc.so.1 (gdb) bt #0 0xfe59fc3c in _libc_kill () from /usr/lib/libc.so.1 #1 0xfe53598c in abort () from /usr/lib/libc.so.1 #2 0xfe535c30 in _assert () from /usr/lib/libc.so.1 #3 0xfeb60c08 in CORBA::ORBInvokeRec::set_answer_invoke(CORBA::InvokeStatus, CORBA::Object*, CORBA::ORBRequest*, short) (this=0x0, state=2949404, o=0x2c8c20, r=0xff00, ad=32556) at orb.cc:326 Line 326 of orb.cc is the first statement in the set_answer_invoke method: assert (_type == RequestInvoke); The assertion appears to fail because the instance of ORBInvokeRec is null. This problem occurs with MICO 2.3.11 on Solaris 8, compiled with GCC 3.4.2 from the Sun Freeware archive. I have tried using MICO 2.3.12 instead, but my Orbacus Java clients are unable to connect to the MICO Naming Service. There is nothing which should make your OB java clients failing to connect to 2.3.12RCx and working with 2.3.11. I would recommend to try hard to test 2.3.12, since 2.3.11 is really quite out-dated now... On MICO's nsd side you can use various debug option to better see what's going on, I'm sure you can use also similar options on OB side. (on MICO's side: -ORBDebug All switch on debugging of all subsystems...) Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] idl compiler error: identifier defined twice in this scope
Hi,
On Mon, 9 Jan 2006, Gurminder Singh wrote:
Hi All,
I am trying to connect to RMI server through the c++ client using Mico
orb.
But I get the error while compiling the idls generated by the RMIC.
Following is the idl which represent the scenario.
When i compile this with IDL Compiler I get following error:
identifier 'iterator' defined twice in this scope
module M2{
abstract valuetype Iterator{
long iterator();
};
abstract valuetype Collection: Iterator{
long iterator();
};
Yes, the problem is that you use `iterator' twice and since IDL does not
provide operation overloading semantics it just find out that you use
`iterator' operation twice in the Collection valuetype. So please fix your
code accordingly.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] build failure MICO 2.3.11 on AIX
Hello, we do not have a lot of reports using GCC on AIX. Anyway, I'm sure it should run well. What I would propose at the first is to try another GCC release. If I count well, 3.3.1 should be several years old now. I would recommend to give a try to GCC 3.4.5 and GCC 4.0.2 to see if some of them solve your issue. FYI: To be clear, we've seen a lot of such crashes caused by miscompilation of IDL compiler, which uses quite big object tree (inheritance) hiararchy which causes some issue to not so good compilers. Please keep us posted, Karel PS: Also please try: http://www.mico.org/snapshots/mico-2.3.12RC2.tar.gz -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Wed, 11 Jan 2006, Hochstetter, Bernhard wrote: hello, i tried to build mico 2.3.11 RC3 on AIX 4.3.3 with g++ 3.3.1 and got the following error message gmake[2]: Entering directory `/home/temp/mico/coss/naming' /home/temp/mico/./idl/idl --c++-skel --name CosNaming \ ../../include/coss/CosNaming.idl gmake[2]: *** [CosNaming.cc] Segmentation fault (core dumped) gmake[2]: *** Deleting file `CosNaming.cc' gmake[2]: Leaving directory `/home/temp/mico/coss/naming' gmake[1]: *** [idlcompile] Error 1 gmake[1]: Leaving directory `/home/temp/mico/coss' gmake: *** [system] Error 1 I tried an older mico version 2.3.6 and got the same result. gdb gave some additional information Core was generated by `idl'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found)... #0 0xd03cf330 in _ZNSt24__default_alloc_templateILb1ELi0EE10deallocateEPvm ( __p=, __n=) at _start_ :442 I localized that os-unix.cc was causing the segmentation violation. I recompiled and linked it with -g and got some more information #0 0xd03cf330 in _ZNSt24__default_alloc_templateILb1ELi0EE10deallocateEPvm ( __p=, __n=) at _start_ :442 #1 0xd2f462d0 in _ZNSt10_List_baseIPN4MICO11UnixProcessESaIS2_EE7__clearEv ( this=) at /usr/local/include/c++/3.3/bits/stl_alloc.h:242 #2 0xd2f462d0 in _ZNSt10_List_baseIPN4MICO11UnixProcessESaIS2_EE7__clearEv ( this=) at /usr/local/include/c++/3.3/bits/stl_alloc.h:242 #3 0xd2f4605c in _Z41__static_initialization_and_destruction_0ii ( __initialize_p=0, __priority=-257165284) at /usr/local/include/c++/3.3/bits/stl_list.h:312 #4 0xd2e17a3c in _GLOBAL__FD_libmicoir2_3_11_so () #5 0xd018cd54 in mod_fini1 () #6 0xd018cca0 in modfini () #7 0xd018d2c0 in __modfini () #8 0xd0186238 in exit () #9 0x11cc in __start () Are there any hints to solve the problem ? Mit freundlichem Gru? Bernhard Hochstetter PSI-BT GmbH Dircksenstr. 42-44 10178 Berlin email: [EMAIL PROTECTED] Tel.: ++49(30)2801-1847 FAX: ++49(30)2801-1020 Internet: www.psi-bt.de <http://www.psi-bt.de/> -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] (no subject)
Hi, compile and install MICO to some directory. Then, you need to configure env. vars to be able to use it. Depending on your shell, you will do either: . /lib/mico-setup.sh or source /lib/mico-setup.csh And now you should be able to compile and run examples: cd /doc/mico/examples/services/naming make ./account_test cd ../events make ./runit ./runit2 Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- On Mon, 16 Jan 2006, Alireza khalilipour wrote: Hi, I want to compile and run the name-service and event-service examples of mico on linux, but I dont know correct commands.please write me,if it is possible. thanks, Alireza. -- ___ Play 100s of games for FREE! http://games.mail.com/ -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] run naming & event examples
On Mon, 16 Jan 2006, Alireza khalilipour wrote: 5) mico-ld -o server server.o account.o -lmico2.3.11 6) mico-ld -o client client.o account.o -lmico2.3.11 also I do running nsd in separate terminal. but I to face with errors about NameService. what must I do? -lmicocoss2.3.11 is missing here. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] naming examples
On Mon, 16 Jan 2006, Alireza khalilipour wrote: hi where is missed -lmicocoss2.3.11 ? in front of -lmico2.3.11 When you use naming service, you need stubs for it and they are compiled into libmicocoss2.3.11 and not into libmico2.3.11. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/commsup.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] MICO 2.3.12 RC3 is available for testing.
Folks, we are pleased to announce MICO 2.3.12 release candidate 3! You can download it here: http://mico.org/snapshots/mico-2.3.12RC3.tar.gz http://mico.org/snapshots/mico-2.3.12RC3.zip This time changes are a little bit intrusive, but whole beast passed our regression testing so I hope everything will be OK. Anyway test it on your platform(s) and report success/failure to mico-devel@mico.org mailing list or directly to me if you don't like to subscribe there. The list of changes done from RC2 is: - update copyright header years in generated files - re-enable old VC++ sequence reference bug workaround (new option: --vc-sequence-reference-bug-workaround) - fix IDL compiler dependency builder for tk_alias struct member generation issue - fix build issue on Solaris/GCC 3.4.x platform If everything is OK, my plan is to release 2.3.12 during next week or two. Cheers, Karel Karel Gardas, Principal Software Engineer, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS, UK Tel. +44 1223 420252, Fax. +44 870 762 6041 USA: Tel.+1-800-898-9148, Fax +1-360-933-9591 [EMAIL PROTECTED], www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] RE: Mico-devel Digest, Vol 29, Issue 8
Hi,
FYI: one of our customers funded multi-threading port to HP-UX/aCC, so
what you see if just result of this project.
Anyway, simple:
export CXX=aCC
export CC=cc
./configure
make
is enough to compile MICO on this platform.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
On Mon, 23 Jan 2006, PERKINS Tyler wrote:
I'm excited for RC3 because the CHANGES doc lists some of our showstoppers. I
got RC3 to compile/install on HPUX 11.00, but on HPUX
11.11 I get errors.
I do:
export CC="aCC -D_INCLUDE_LONGLONG"
export CXX=aCC
./configure --enable-threads --prefix=/opt/micorc3
gmake
After a few minutes, I see:
gmake[1]: Entering directory `/root/mico/cpp'
aCC -D_INCLUDE_LONGLONG -DHAVE_CONFIG_H -I. -I../include +O2 -Ae-c -o
cexp.o cexp.c
Error 173: "cexp.y", line 245 # Redefined symbol 'constant'; previously
defined at ["cexp.y", line 236].
struct constant {HOST_WIDE_INT value; int signedp;} integer;
^^^
Warning 942: "cexp.y", line 374 # Types 'constant *' and 'YYSTYPE::constant *'
are not assignment-compatible.
yyval.integer.value = right_shift (&yyvsp[-2].i
^
Warning 942: "cexp.y", line 376 # Types 'constant *' and 'YYSTYPE::constant *'
are not assignment-compatible.
yyval.integer.value = left_shift (&yyvsp[-2].in
^
Warning 942: "cexp.y", line 380 # Types 'constant *' and 'YYSTYPE::constant *'
are not assignment-compatible.
yyval.integer.value = left_shift (&yyvsp[-2].in
^
Warning 942: "cexp.y", line 382 # Types 'constant *' and 'YYSTYPE::constant *'
are not assignment-compatible.
yyval.integer.value = right_shift (&yyvsp[-2].i
^
Error 359: "cexp.y", line 1026 # The expression on the left side of the '->'
(arrow member access operator) must be a pointer to completed struct
object type; the type of the left side is 'constant *' and 'struct
constant' has not been defined yet.
return (unsigned HOST_WIDE_INT) a->value << b;
^
Error 359: "cexp.y", line 1035 # The expression on the left side of the '->'
(arrow member access operator) must be a pointer to completed struct
object type; the type of the left side is 'constant *' and 'struct
constant' has not been defined yet.
return a->signedp ? a->value >> (HOST_BITS_PER_WIDE_INT - 1) : 0;
^
Error 359: "cexp.y", line 1036 # The expression on the left side of the '->'
(arrow member access operator) must be a pointer to completed struct
object type; the type of the left side is 'constant *' and 'struct
constant' has not been defined yet.
else if (a->signedp)
^
Error 359: "cexp.y", line 1037 # The expression on the left side of the '->'
(arrow member access operator) must be a pointer to completed struct
object type; the type of the left side is 'constant *' and 'struct
constant' has not been defined yet.
return a->value >> b;
^
Error 359: "cexp.y", line 1039 # The expression on the left side of the '->'
(arrow member access operator) must be a pointer to completed struct
object type; the type of the left side is 'constant *' and 'struct
constant' has not been defined yet.
return (unsigned HOST_WIDE_INT) a->value >> b;
^
gmake[1]: *** [cexp.o] Error 2
gmake[1]: Leaving directory `/root/mico/cpp'
gmake: *** [system] Error 1
[EMAIL PROTECTED] [/root/mico]
#
Thanks in advance
Tyler Perkins
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Mico Beginner - Help
Paul,
please make sure to start your server correctly on NIC interface. You will
ensure this by using -ORBIIOPAddr inet::
command-line option, where is remotely contactable host name
of your machine (server) and is your chosen port.
You will also need to use the same information on your client side. If you
are not sure where the problem is, please use telnet to reach the server
side:
telnet
type few (>20) characters and hit enter, you should see reply containing
`GIOP' and connection should close.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/commsup.html <---
---
On Mon, 30 Jan 2006, Caswell, Paul (SELEX Comms) (UK) wrote:
Hello All,
I'm running MICO on a W2K machine and and developing a simple control
interface for an application that runs remotely. I've played around
with the Mico POA examples and everything works fine on my local machine
if I initialise the server as follows:
-ORBIIOPAddr inet:localhost: or -ORBIIOPAddr inet:127.0.0.1:
The client initialises as follows:
// ORB initialisation
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb");
// get the remote conference combiner object
CORBA::Object_var obj = orb->bind("IDL:conferenceCombiner:1.0",
"inet:127.0.0.1:");
if (CORBA::is_nil(obj))
{
// no such object found
std::cout << "no such CORBA object" << std::endl;
return -1;
}
conferenceCombiner_var CCClient = conferenceCombiner::_narrow(obj);
etc
Anyway, whenever I use anything other than'localhost' or '127.0.0.1' the
client fails. It passes the orb->bind(...) call above but then fails on
the first call on that object with a CORBA::COMM_FAILURE exception. It
fails in this generated code:
CORBA::StaticRequest __req( this, "createConference" );
__req.add_in_arg( &_sa_conferenceID );
__req.add_in_arg( &_sa_DSCPValue );
__req.set_result( &__res );
__req.invoke();
mico_sii_throw( &__req,
0);
I know this is a bit of a 'shot in the dark' but I'm very new to Corba
and Mico. Any help would be really apprecaited.
Regards
Paul
Paul
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] [BUG] CosTrading tries to use --boa
Robert, MICO's trader is not ported to POA yet, which means it is disabled for 2.3.12 release by default. I hope some 3th party which is using it will either port it or fund port directly. Cheers, Karel On Mon, 30 Jan 2006, Robert Schwebel wrote: Hi Karel, Another bug... /home/rsc/svn/ptxdist-build-0.9-trunk/local/bin/idl --no-poa --boa --c++-skel -B../.. --any --name CosTrading ../../include/coss/CosTrading.idl error: --boa option is no longer supported (if you need BOA support, please use MICO release older than 2.3.12) Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Has anyone built 64bit veriosn of Mico?
On Mon, 6 Feb 2006, Jie Lin wrote: Hi! Guys If you have built 64bit mico successfully, please let us know. Hi, Not only built, but I'm using 64bit only all the time last year for our own MICO-based developments. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] MICO 2.3.12 : Multi-thread & CCM ?
On Mon, 30 Jan 2006, Erwan BECQUET wrote: Hi evrybody, I just tried to compile Mico 2.3.12 and saw a warning regards multithread & ccm ! I would like to know : 1) if MICO M/T & CCM is planned ? If yes, when ? First of all, you are welcome to do appropriate fixes yourself and I'm happy to review them and merge them for 2.3.13 release. On the other hand if you are not interested in this coding, you might ask Frank Pilhofer if he is interested in doing this work for you (or for the customer). If he is not, then we can offer our technical support services here and do this work ourself. 2) warning message says i can use MICO/MT with one thread for requests or single-thread version. What's the difference between two options ? Can I "background" some requests, processing them asyn- chronously using threads safely in M/T version ? The difference is that if you need multi-threaded build, then you don't need to build single-threaded solely for purposes of MicoCCM. It's an assumption that if you use sinle-threaded worker thread-pool you will get the same behavior, although it (the assumption) is only lightly tested. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Oneway Methods
On Mon, 6 Feb 2006, Alireza khalilipour wrote: Hi All, I have 2 Questions: 1. Does supported the oneway calling in mico? Yes, MICO does support oneway calls. 2. if yes, can I push a value in an event channel within oneway method? ( with due attention to that a oneway method can't has return value). It depends on what exactly do you mean: 1) use oneway to push, then no, since Events service does not define push as oneway operation. 2) call twoway push inside oneway invocation on the server side, then yes, this is possible, although as you noted error handling is completely up to you. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] CORBA Arrays of Strings
Hello,
I would recommend you to read some book about CORBA/C++. Arrays are a bit
tricky, so if you don't understand them and wouldn't like to purchase for
example Henning&Vinoski's Advanced CORBA programming in C++, then I would
recommend you to use sequences instead of arrays.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
On Wed, 1 Feb 2006, Caswell, Paul (SELEX Comms) (UK) wrote:
Hello All,
I'll admit I'm completely lost on this one so any help would be
appreciated. I want to return an array of strings from a call on my
corba object, the IDL looks like this:
interface
{
const long STRING_LIST_SIZE = 100;
// these typedef are used when getting lists
typedef string stringList[STRING_LIST_SIZE];
/* Get the list of the names of codecs supported by this application
*/
boolean getSupportedCodecs(out stringList codecNamesList);
.. etc
}
The generated code looks like this:
static const CORBA::Long STRING_LIST_SIZE;
typedef CORBA::String_var stringList[ 100 ];
typedef CORBA::String_var stringList_slice;
typedef ArrayVarVar<
CORBA::String_var,stringList_slice,stringList,100 > stringList_var;
typedef ArrayVarOut <
CORBA::String_var,stringList_slice,stringList,100 > stringList_out;
enum _dummy_stringList { _dummy_stringList_0 };
typedef ArrayVarForAny <
CORBA::String_var,stringList_slice,stringList,100,_dummy_stringList>
stringList_forany;
.. Etc
In my implementation file I have implemented the body of
getSupportedCodecs(...) to populate the array of strings. The question
is how do I call this from the client? What type should the list
parameter be?
if (CCClient->getSupportedCodecs(list))
{
// do interesting things...
}
I thought it would be a stringList_var BUT this won't compile
conferenceCombinerInterface::stringList_var list;
if (CCClient->getSupportedCodecs(list))
{
}
Regards,
Paul
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
RE: [mico-devel] Has anyone built 64bit veriosn of Mico?
Hello, please note that VC++ 2005 is not supported yet and in fact will neither be suppored in 2.3.12 release which is due out today. We're working hard to make support for VC++2005 available shortly in some of post 2.3.12 development snapshots. For now please stick with VC++2003. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Tue, 7 Feb 2006, Jie Lin wrote: Hi! karel Glad to hear that you are using 64bit mico. We plan to move to 64bits mico on windows with vc++ 2005 compiler. Currently, we are having problems ofcompiling 32 bits mico(2.3.12.CR2) with vc++2005 compiler. We plan to compile mico2.3.12 with stlport5.0.0 using vc++2005. But We end up we can't build any version of mico with vc++2005. Can you shine lights? Jerry Pls: we have built mico2.3.11 on solaris8 with gcc3.4 and mico2.3.7 with vc++6. -Original Message----- From: Karel Gardas [mailto:[EMAIL PROTECTED] Sent: Mon 2/6/2006 7:41 PM To: Jie Lin Cc: mico-devel@mico.org Subject: Re: [mico-devel] Has anyone built 64bit veriosn of Mico? On Mon, 6 Feb 2006, Jie Lin wrote: Hi! Guys If you have built 64bit mico successfully, please let us know. Hi, Not only built, but I'm using 64bit only all the time last year for our own MICO-based developments. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] [BUG] MICO Trader
Hello, yes, trader is disabled by default. In fact you don't need to use so complicated configure command-line, since a lot of what you switch on/off is already done by default. Anyway, to your issue. The problem is that CosLifecycle depends on trader, so please disable this service too. In fact I would recommend you to go with default setting and just add what you really need: ./configure --target="arm-softfloat-linux-gnu" --with-mico="/home/rsc/svn/ptxdist-build-0.9-trunk/local" --prefix=/home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu --enable-ccm --enable-relship --without-x I've also removed lifecycle and streams from the command-line above. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Mon, 30 Jan 2006, Robert Schwebel wrote: Hi, This looks to me like, although --disable-trader is set, Mico is trying to use it. Robert target: mico.prepare compiler check...ok cd /home/rsc/svn/ptxdist-build-0.9-trunk/build-target/mico-2.3.12RC3 && \ PATH=/home/rsc/svn/ptxdist-build-0.9-trunk/local/bin:/home/rsc/svn/ptxdist-build-0.9-trunk/local/usr/bin:$PATH AR=arm-softfloat -linux-gnu-ar AS=arm-softfloat-linux-gnu-as CXX=arm-softfloat-linux-gnu-g++ CC=arm-softfloat-linux-gnu-gcc CC_FOR_BUILD=gcc CPP_FOR_BUI LD=gcc LINK_FOR_BUILD=gcc LD=arm-softfloat-linux-gnu-ld NM=arm-softfloat-linux-gnu-nm OBJCOPY=arm-softfloat-linux-gnu-objcopy OBJDUMP=a rm-softfloat-linux-gnu-objdump RANLIB=arm-softfloat-linux-gnu-ranlib STRIP=arm-softfloat-linux-gnu-strip CPPFLAGS='-isystem /home/rsc/ svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/include -isystem /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-li nux-gnu/usr/include' LDFLAGS='-L/home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/lib -L/home/rsc/svn/ptxdist-build-0 .9-trunk/local/arm-softfloat-linux-gnu/usr/lib' CXXFLAGS='-isystem /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/ include -isystem /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/usr/include' SYSROOT=/home/rsc/svn/ptxdist-build-0 .9-trunk/local/arm-softfloat-linux-gnu PKG_CONFIG_PATH=/home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/lib/pkgconfi g:/home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/usr/lib/pkgconfig ac_cv_sizeof_long_long=8 ac_cv_sizeof_long_doub le=8 ac_cv_func_getpgrp_void=yes ac_cv_func_setpgrp_void=yes ac_cv_func_memcmp_clean=yes ac_cv_func_setvbuf_reversed=no ac_cv_func_getr limit=yes ac_cv_type_uintptr_t=yes ac_cv_func_dcgettext=yes gt_cv_func_gettext_libintl=yes ac_cv_sysv_ipc=yes DESTDIR=/home/rsc/svn/ptx dist-build-0.9-trunk/local/arm-softfloat-linux-gnu \ ./configure --target="arm-softfloat-linux-gnu" --with-mico="/home/rsc/svn/ptxdist-build-0.9-trunk/local" --prefix=/home/rsc/svn /ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu --enable-threads --enable-ccm --disable-coss --disable-csl2 --enable-csiv2 --ena ble-naming --enable-relship --enable-events --enable-stream --enable-property --disable-trader --enable-time --enable-life --disable-ex ternalize --disable-wireless --disable-wireless-home --disable-wireless-terminal --disable-wireless-access --disable-mini-stl --disable -repo --disable-minimum-corba --without-x [...] arm-softfloat-linux-gnu-g++ -I. -I../../include -O2 -Wall -isystem /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gn u/include -isystem /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/usr/include -D_REENTRANT -D_GNU_SOURCE -isyste m /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm-softfloat-linux-gnu/include -isystem /home/rsc/svn/ptxdist-build-0.9-trunk/local/arm- softfloat-linux-gnu/usr/include -c FactoryFinder_impl.cc -o FactoryFinder_impl.o FactoryFinder_impl.cc:27:34: coss/CosTradingRepos.h: No such file or directory -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] MICO 2.3.12
Folks, we are pleased to announce the release of MICO 2.3.12. The major features of this release are: - multi-threading is on by default on supported platforms (Unixes, Win32/VC++) - Wireless MICO Extensions project was merged in. See --enable-wireless configure option (work done by Jaakko Kangasharju) - CORBA reflection support (mars/04-08-12) was added (work done by Frank Pilhofer) - rewritten client-side concurrency models, new command-line options introduced are: -ORBClientThreaded, -ORBClientThreadedBlocking, -ORBClientReactive - The IDL compiler was enhanced to better support include paths searching/generation, see -B option (work done by Dirk O. Siebnich) - Poll-based dispatcher was added, see -ORBUsePoll command-line option (work done by Florian Wesch) - codesets IOR component handling placement improved, see -ORBCodeSetsInIIOPProfile and -ORBNoCodeSetsInMultiCompProfile command-line options - new platform support added for: Darwin/MacOSX/GCC (Dmitri Hrapof) and Cray Unicos/CC (Rob Ratcliff/FutureTek) - a lot improved support for SGI Irix/MipsPRO (Sander Cox, Zoltan Bordas), Tru64/CXX, HP-UX/ACC, and Solaris/CC platforms Removed or deprecated/disabled features are: - BOA is finally removed - old interceptors upcalls are now disabled by default. The feature itself is deprecated and scheduled for removal in next release - Trader and Stream services are disabled by default due their dependency on BOA - Relationship service is also disabled by default to save compilation time on this not so used service. Use --enable-relship to enable it This release also contains a load of bugfixes and small enhancements and we recommend it for upgrade. Most important bugfixes went in for: PI, GIOP, SSL/TLS transport, DII, DynAny and threading. They are provided or reported by either ObjectSecurity or by 3th party contributors: Sorin Mustaca, Jaakko Kangasharju, Dirk O. Siebnich, Fred Patrick, Sergey Matveychuk, Joerg Knobloch, Steffen Kiefer, Michio Tsunekawa, Frank Pilhofer, Dmitri Hrapof, Sander Cox, Zoltan Bordas, Vinod Kumar, Florian Wesch, Rob Ratcliff, Michail Bannij, Ruslan Shevchenko, Ron Wechselberger, Jose Luu, Heiko Jansen, Tom Ritter, Antony Ramahay. MICO 2.3.12 is available for download at http://www.mico.org For full list of changes, please read CHANGES files at: http://www.mico.org/CHANGES Thanks to all which makes this release possible. Please test it on your platform and report success or failure to mico-devel@mico.org mailing list or directly to me, if you are not subscribed in this list. Karel Karel Gardas, Principal Software Engineer, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS, UK Tel. +44 1223 420252, Fax. +44 870 762 6041 USA: Tel.+1-800-898-9148, Fax +1-360-933-9591 [EMAIL PROTECTED], www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Re: RE : RATP IT - Architectures distributed - Corba - Opinion and experience feedback ORB Mico
Hi, On Tue, 7 Feb 2006, BROSSARD David wrote: Answers to your questions: 1) we use MICO in version 2.3.11 please try to duplicate your issue with just today released 2.3.12 2) our Mico-based applications are running on Intel architecture platforms with 4 cpu each one and RedHat ES 3 (kernel 2.4) this is common configuration. 3) to compile MICO, we use 2.3.3 C++ compiler (gcc) I'm sure you mean 3.2.3 C++ compiler, also common, although a bit older one. 4) we note only that Mico develops in the memory: every 10 seconds the Micod process increases by 1 mega-bytes in the memory. This is most likely issue with user code, please review your code if you deallocate all the allocated storage. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Compilationproblems using VC++ 7.1
Hi,
On Tue, 7 Feb 2006, Rippich, Andrej wrote:
Hi all,
because i'm encountering internal compiler errors when trying to port a
project from mico 2.3.6/VC++ 6.0 to 2.3.12/VC++7.1, i've tryed to
compile the project using the combination 2.3.6. with VC++ 7.1.
I would really recommend you to stick to 2.3.12 and try hard to
solve/workaround MS bugs.
I have to use VC++ 7.1, because the code is part of a biggger project. A
Patch provided by Micorosoft to solve the internal compiler error
does'nt help. The internal compiler error does'nt occur, but i'm getting
the following error in the code generated by the idl compiler:
C2064: term does not evaluate to a function taking 3 arguments
The Error occurs in a method
bool POA_model::Session::dispatch (CORBA::StaticServerRequest_ptr __req)
Session is an Interface defined in one of the idls.
Please look at the following code snipset:
...
model::AbstractSession_var session;
model::ClientInfo client;
CORBA::String_var message;
...
#ifdef HAVE_EXCEPTIONS
try {
#endif
--> message( session.inout(), client, message.inout() );
#ifdef HAVE_EXCEPTIONS
} catch( ::model::NotLoggedInException_catch &_ex ) {
__req->set_exception( _ex->_clone() );
__req->write_results();
return true;
} catch( ::model::ObjectAccessException_catch &_ex ) {
__req->set_exception( _ex->_clone() );
__req->write_results();
return true;
} catch( ::model::Internal_catch &_ex ) {
__req->set_exception( _ex->_clone() );
__req->write_results();
return true;
}
#endif
__req->write_results();
return true;
The code looks valid to me, because "message" (the method is Part of my
idl Interface) is a abstract member function of POA_model::Session. When
i try to change the code in order to call the Method full qualified, i'm
getting a linker error nc_dll error LNK2019: unresolved external symbol
"public: virtual void __thiscall POA_model::Session::message(class
model::AbstractSession *,struct model::ClientInfo const &,char const *)"
([EMAIL PROTECTED]@POA_model@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED])
referenced in function $L190004
Any suggestions ?
Try to simplify your code to self-contained simple as possible test-case.
When this is done we can try to see what's possible to do with this issue.
-- I'm talking here about your 2.3.12/VC++ attempt where you get internal
compiler errors.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] event service
On Wed, 8 Feb 2006, Alireza khalilipour wrote: Hi All, I want to run event service example on the Linux that is in the /mico/demo/services/events . I want run client and server (consumer and supplier) in separate shells. But I dont know the appropriate command for running event service. I think the command is "eventd" with the parameters but I dont know what are those parameters. (the naming service is running in separate shell) please help me. What exactly do you need? I consider demo/services/events/runit* scripts clear so I'm curious what makes you problem to divide them to run servers/clients in separate shells. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Re: RE : RE : RATP IT - Architectures distributed - Corba - Opinion and experience feedback ORB Mico
David, it's here: http://www.mico.org/down.html see ``Complete sources for MICO...'' Cheers, Karel On Thu, 9 Feb 2006, BROSSARD David wrote: Dear Karel, Your remark is right, indeed we assure you that we use 3.2.3 C++ compiler. But before examining the code to review if it deallocate all the allocated storage, we prefer installing and testing the new version of Mico (2.3.12), but we do not find it. Can you indicate us the link to download it ? Thank you in advance, Cordially, David BROSSARD -Message d'origine----- De : Karel Gardas [mailto:[EMAIL PROTECTED] Envoyé : mardi 7 février 2006 15:50 À : BROSSARD David Cc : mico-devel@mico.org; ALEM Abderamane; SAUTRON Stephane Objet : Re: RE : RATP IT - Architectures distributed - Corba - Opinion and experience feedback ORB Mico Hi, On Tue, 7 Feb 2006, BROSSARD David wrote: Answers to your questions: 1) we use MICO in version 2.3.11 please try to duplicate your issue with just today released 2.3.12 2) our Mico-based applications are running on Intel architecture platforms with 4 cpu each one and RedHat ES 3 (kernel 2.4) this is common configuration. 3) to compile MICO, we use 2.3.3 C++ compiler (gcc) I'm sure you mean 3.2.3 C++ compiler, also common, although a bit older one. 4) we note only that Mico develops in the memory: every 10 seconds the Micod process increases by 1 mega-bytes in the memory. This is most likely issue with user code, please review your code if you deallocate all the allocated storage. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] ERR: can not find event channel factory
On Fri, 10 Feb 2006, Alireza khalilipour wrote: Hi all, I write a program that uses the event service. but when i execute it on linux ( with this command : ./client -ORBNamingAddr inet:localhost:12456)-client is my program name- the following error appear: "cannot find event channel factory". How does client.cc look like? note that the name service and event service are running in separate shells as follows: nsd -ORBIIOPAddr inet:localhost:12456 eventd -ORBNamingAddr inet:localhost:12456 but the command for compiling the client program was : mico-ld -o client client.o idlfile.o -lmicocoss2.3.11 -lmico2.3.11 Looks OK assuming you are using 2.3.11 release. I would recommend you to upgrate to 2.3.12. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Error: segmentation fault
On Sun, 12 Feb 2006, Alireza khalilipour wrote: Hi all, I want to "push" a string into an event channel. But I faced with this error: "segmentatiom fault". the code that I use to push,is: CORBA::Any *any; ^ this line is "a bit" problematic. Either allocate Any to the any variable or at least assign NULL to it. char *s1="HELLO"; *any<<=s1; Obviously, you access not allocated memory location here. Also please fix the line ``char *s1="HELLO";'', since string "HELLO" is constant string. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] MICO and shared libraries
Hello Clive, could you be so kind and post as short as possible example here? If I understand you well, there is no need to link object file with one concrete marshaler type to two libraries, or is it? IMHO if you link it only to one library your problem should disappear or am I wrong? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Thu, 23 Feb 2006, Clive Butler wrote: Hi all, I've run across what I think may be an issue with the way that MICO manages construction/destruction of the marshalling functions, specific to the scenario involving the building of shared libraries that link against MICO-generated code. For each IDL-described data structure, MICO generates a global pointer to its marshalling class, and a typecode information structure with file scope. The (global) constructor of the type code class allocates the global instance of the marshalling class and the (global) destructor destroys the marshalling class instance. I build two shared libraries, each of which uses such a common structure, then link a main program against both libraries. The problem is that the global constructors and destructors for the file scope objects are run twice since the objects occur twice (once per library). The destructors thus perform a double delete, resulting in undesired behavior during exit(). As far as I can tell, there's no way to guarantee that the file scope constructors/destructors will be called exactly once. The main effect of the problem can be evaded by having the destructor code set the global pointer to 0 after the delete. Any other ideas? This is on Linux (FC4 with gcc 4.0.2, binutils-2.15.94, etc.) but I don't think the problem is specific to this platform. Cheers, Clive ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] CORBA/UNKNOWN Exception when invoking EJB object
Denis,
please try to add `-ORBDebug All' command-line param for your MICO-based
client and see what this produce. And no, it's not known issue.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
On Tue, 21 Feb 2006, Denis McHugh wrote:
I have just downloaded mico and it looks very promising. I want to be able to
connect a C++ client to an EJB service in a J2EE engine, and I am porting a
client from using orbacus to mico. It goes well, until the client attempts to
invoke the EJB object.
Here is a synopsis of the code and how the C++ client is put together:
CODE:
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
const char* ejb_url = "corbaname:iiop:myJ2EEhost:53007#me.com/CFV3/MyBean";
CORBA::Object_var object = orb -> string_to_object (ejb_url);
EJBAppHome_var callbackHome = EJBAppHome::_narrow(object);
EJBApp_var callback = callbackHome -> create();
try{
callback->someEJBAppMethod();
}catch(const CORBA::Exception& ex){
cout << "EXCEPTION CAUGHT!" << endl;
ex._print( cout );
cout << endl;
return 0;
}
RUNTIME:
EXCEPTION CAUGHT!
IDL:omg.org/CORBA/UNKNOWN:1.0 (0, not-completed)
COMPILE + LINK:
// To produce C++ stubs:
idl *.idl
// To produce C++ object code:
g++ -c -g -I. -I../installation/include *.cpp
// To produce executable:
g++ -I. -I../mico/installation/include -g -fPIC -Wall -Wno-format-y2k -L.
-L../mico/installation/lib -o client *.o ./java/lang/*.o ./javax/ejb/*.o
./cfejbV3/iiop/*.o -lmico2.3.12 -lpthread -ldl
I am not running any mico services, in fact I want to be able to run the
client without having any mico runtime services running.
I am using the bare minimum compile and link flags. I have tried passing the
-ORBNoIIOPServer flag but with the same result.
Is this a known problem or am I missing something? Any help would be greatly
appreciated.
Thanks,
Colm.
_
Don?t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Mico Crash
Rusmin,
please forget 2.3.8 and give a try to 2.3.12 release. It is tested with
VC++ 2003 and should also work for you. If you have any issue with it,
please post description here.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
On Tue, 21 Feb 2006, Rusmin Susanto wrote:
Hi. I build Mico (V 2.3.8) using Visual C++ .NET 2003. I always get Mico
Crash if I do a certain thing. I suspect that it has something to do
with
Microsoft's bug. In the README-WIN32, I found this:
Sometimes a MICO application will crash inside mico.dll. As far as we
can tell this is
related to a bug in the Microsoft Linker when dealing with global
constructors. If this happens to you, try to link typecode.obj and
util.obj statically with your application (a copy of these object files
can be found in win32-bin\lib). This usually resolved our
problems... sigh...
Normally no need to link any additional files. The util.obj is only
needed when passing std::map objects between
application and a dll(necessary in idl.exe). The problem with
typecode.obj should be fixed too(knock on wood).
I think the above suggestion could be the solution.
My question is:
- What does this ("try to link typecode.obj and util.obj statically with
your application") mean?
Does it mean that in the additional dependency I should specify
typecode.obj and util.obj instead of mico*.lib?
Could someone give me more specific / clearer hints please?
Thanks
Rusmin
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] HTTP tunneling support
Gurminder, if I understand your email well, then the biggest motivation behind introducing SOAP to your application is firewall traversal. I personally prefer more simple solution to this problem as IIOP/CORBA firewall software is. Perhaps this is because I have good experience with our own ObjectWall deployments. :-) http://www.objectwall.com Please let me know off-list if you are interested in evaluation version. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Mon, 20 Feb 2006, Gurminder Singh wrote: Hi, I am developing an application (client/server) which has its server written in java and supports both IIOP and SOAP channel s for communication. I have introduced soap channel to overcome the problem faced by IIOP when the clients are on the other side of firewall. My requirement is to develop a client which can possibly switch between channels (IIOP/SOAP) dynamically. Another alternative is to provide HTTP tunneling. My approach to tackle the solution is to develop a library which can possibly tunnel iiop into HTTP. Does any one have worked in this area if yes then please guide. Thanks in advance. --Regards Guminder Singh Member (SDG) Core Technologies Group Quark Media House pvt Ltd. A- 45 industrial Area (Mohali) Phone: 91 -172-2299440 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> CONFIDENTIALITY NOTICE This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone xxx.xxx. or return e-mail message [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] running event service
Hello, please configure mico with some installation prefix, i.e. ./configure --prefix=/opt/mico-2.3.12 and then run: make make install and then: . /opt/mico-2.3.12/lib/mico-setup.sh and now your IDL should run fine... Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Thu, 9 Feb 2006, Wasif Gilani wrote: Hi I have just started working with mico...there is one problem...if i directly use like: mico/./idl/idl account.idl i get error which is sh: mico-cpp: command not found error: cannot execute mico-cpp I would like to know how can i fix it and use directly without going into Makefiles...as from Makefile it works fine as there are some includes in Makfile which fix this... wasif ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] segmentation fault while builing mico on HPUX11/native cc
Hello, for one of our customers we've enhanced MICO 2.3.12 to support HP-UX well. I've tested 2.3.12 release on: bash-2.04$ uname -a HP-UX td192 B.11.11 U 9000/800 1839940656 unlimited-user license with: bash-2.04$ aCC -V aCC: HP ANSI C++ B3910B A.03.67 and it runs quite well. (I don't consider using diff -u in testsuite as a critical bug) as you can see here: bash-2.04$ ls -la coss/property/* -rw-r--r-- 1 kgardasnis707 Nov 25 06:15 coss/property/CHANGES -rw-r--r-- 1 kgardasnis 2299 Nov 25 06:15 coss/property/Makefile -rw-r--r-- 1 kgardasnis 1792 Nov 25 06:15 coss/property/Makefile.win32 -rw-r--r-- 1 kgardasnis 218512 Feb 6 05:54 coss/property/PropertyService.cc -rw-r--r-- 1 kgardasnis 55094 Feb 6 05:54 coss/property/PropertyService.h -rw-r--r-- 1 kgardasnis 573504 Feb 6 05:55 coss/property/PropertyService.o -rw-r--r-- 1 kgardasnis 608424 Feb 6 05:55 coss/property/PropertyService.pic.o -rw-r--r-- 1 kgardasnis 40155 Nov 25 06:15 coss/property/PropertyService_impl.cc -rw-r--r-- 1 kgardasnis 207068 Feb 6 05:55 coss/property/PropertyService_impl.o -rw-r--r-- 1 kgardasnis 219908 Feb 6 05:55 coss/property/PropertyService_impl.pic.o -rw-r--r-- 1 kgardasnis 4995 Nov 25 06:15 coss/property/README -rw-r--r-- 1 kgardasnis 4916 Nov 25 06:15 coss/property/main.cc -rw-r--r-- 1 kgardasnis 163156 Feb 6 05:56 coss/property/main.o -rwxr-xr-x 1 kgardasnis 200704 Feb 6 05:56 coss/property/propertyd property service is compiled too. Please try to use more up-to-date compiler and let us know if it helps. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Wed, 15 Feb 2006, [EMAIL PROTECTED] wrote: Hi there, The build of mico (2.3.12) on HPUX11 - HP-UX lea B.11.00 U 9000/800 140901597 unlimited-user license, - aCC: HP ANSI C++ B3910B A.03.31 runs into a segmentation fault: SCHNIPPEL<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<< gmake[2]: Entering directory `/tmp_mnt/home/wag/MICO_HPUX11/mico/coss/property' /home/wag/MICO_HPUX11/mico/./idl/idl -B../.. --any --name PropertyService \ ../../include/coss/PropertyService.idl gmake[2]: *** [PropertyService.cc] Segmentation fault (core dumped) gmake[2]: Leaving directory `/tmp_mnt/home/wag/MICO_HPUX11/mico/coss/property' gmake[1]: *** [idlcompile] Error 1 gmake[1]: Leaving directory `/tmp_mnt/home/wag/MICO_HPUX11/mico/coss' gmake: *** [system] Error 1 ->$ gdb /home/wag/MICO_HPUX11/mico/./idl/idl gHP gdb 3.1.1 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 3.1.1 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. ..(no debugging symbols found)... (gdb) core-file ./coss/property/core Core was generated by `idl'. Program terminated with signal 11, Segmentation fault. 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)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... #0 0xc01894fc in free+0x12c () from /usr/lib/libc.2 (gdb) bt #0 0xc01894fc in free+0x12c () from /usr/lib/libc.2 #1 0xc3cf48c4 in operator delete []+0x30 () from /usr/lib/libCsup_v2.2 #2 0xc657a958 in CORBA::string_free+0x18 () from /home/wag/MICO_HPUX11/mico/./libs/libmico2.3.12.sl #3 0xc657a478 in CORBA::String_var::operator=+0x38 () from /home/wag/MICO_HPUX11/mico/./libs/libmico2.3.12.sl #4 0x1ca32c in __as__Q2_3std6vectorXTQ2_5CORBA10String_varTQ2_3std9allocatorXTQ2_5CORBA 10String_var__FRCQ2_3std6vectorXTQ2_5CORBA10String_varTQ2_3std9allocator XTQ2_5CORBA10String_var__+0x578 () #5 0xc53bdbd0 in members__12EnumDef_implFRC18StringSequenceTmplXTQ2_5CORBA10String_var_+0 x268 () from /home/wag/MICO_HPUX11/mico/./libs/libmicoir2.3.12.sl #6 0xc67bc474 in members__Q2_5CORBA16EnumDef_stub_clpFRC18StringSequenceTm
Re: [mico-devel] CORBA/UNKNOWN Exception when invoking EJB object
Hello, what GIOP/IIOP are you using on MICO side? Perhaps you might try 1.2 forced by -ORBGIOPVersion 1.2 -ORBIIOPVersion 1.2 command-line parameters. Yes, JBoss developers used MICO to invoke EJBs operations from C++. Cheers, Karel PS: If you are not using MICO 2.3.12, also please make sure you test it -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Wed, 1 Mar 2006, Denis McHugh wrote: Thanks Karel, doing that provided a lot of information. It turns out the problem is in the J2EE server; when it (the IIOP dispatcher service) is unmarshalling a String parameter, it hits a java.lang.OutOfMemory exception. With an alternative orb, the J2EE server goes through the exact same unmarshalling steps, but doesn't hit any exceptions, and the invocation works fine. What could account for this difference ? And, has an EJB been successfully invoked by a C++ client via mico ? Many thanks, Denis. Denis, please try to add `-ORBDebug All' command-line param for your MICO-based client and see what this produce. And no, it's not known issue. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- _ Don?t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] CORBA/UNKNOWN Exception when invoking EJB object
Hello, this is probably not feature but requirement. i.e. if your server is using GIOP 1.0, MICO needs to "downgrade" and use also 1.0. Try to iordump your server (ejb's) reference to get more information about what GIOP version it uses. Yes, I'm able to use exactly your parameters below to force client talking with GIOP 1.2, but of course in case my server also talks with 1.2 Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Wed, 8 Mar 2006, Denis McHugh wrote: Thanks Karel, I am using mico 2.3.12, and it defaults to GIOP/IIOP version 1.0. I tried to specify 1.2 as you advised, but I am not sure how to force the client to use GIOP version 1.2. I run the client like this: client -ORBGIOPVersion 1.2 -ORBIIOPVersion 1.2 -ORBDebug All and in the debug output I see the following: IIOP: [...] IIOP version 1.2 GIOP: [...] using GIOP version 1.0 I have attempted re-ordering the arguments, so that -ORBGIOPVersion is first, last, etc but each time the GIOP version is 1.0. Is this a known issue ? Thanks again, Denis. Hello, what GIOP/IIOP are you using on MICO side? Perhaps you might try 1.2 forced by -ORBGIOPVersion 1.2 -ORBIIOPVersion 1.2 command-line parameters. Yes, JBoss developers used MICO to invoke EJBs operations from C++. Cheers, Karel PS: If you are not using MICO 2.3.12, also please make sure you test it -- _ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] NamingContext_var appears to hang on resolve()
Hello,
I've not seen such problem, but your email does not contain all the needed
information. For example you don't mention if the process hangs forever or
you've seen it running again. Also in such cases you need to describe your
platform in more details and also your concurrency models settings. The
best option is if you provide simple as possible example which duplicates
your issue.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
On Fri, 10 Mar 2006, Swinnerton, James (UK) wrote:
Has anybody come across this problem? I have multiple process running on
a single platform. Each process also has anumber of threads running.
Each one is registered via the naming service and therefore conatctable
by any other thread. However at some point one process will hang for a
significant period while trying to resolve the NamingContext. The
command hanging is "mObj = mNc->resolve (mName);". See below:
CORBA::Object_var* mpNsObj;
CosNaming::NamingContext_var mNc;
string mHostLoc = "corbaloc::";
CORBA::Object_var mObj;
mpNsObj = new CORBA::Object_var;
(*mpNsObj) = Orb->resolve_initial_references ("NameService");
try
{
mNc = CosNaming::NamingContext::_narrow (*mpNsObj);
}
catch (CORBA::SystemException_catch& ex1 )
{
. //some failure
}
if (CORBA::is_nil (mNc))
{
exit (1);
}
CosNaming::Name mName;
mName.length (1);
mName[0].id = CORBA::string_dup (aName.c_str() );
mName[0].kind = CORBA::string_dup (aKind.c_str() );
try
{
mObj = mNc->resolve (mName);
}
catch (CORBA::SystemException_catch &_ex )
{
}
catch (CosNaming::NamingContext::NotFound &exc)
{
}
catch (CosNaming::NamingContext::CannotProceed &exc)
{
}
catch (CosNaming::NamingContext::InvalidName &exc)
{
}
Any ideas appreciated.
Cheers,
James Swinnerton
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Dump (and load) idl classes
On Thu, 30 Mar 2006, Giuseppe Burgarella wrote: Hi Nikolay, I ported it in my HP-UX machine... I'm looking for the right command to produce the patch. Do you know what I should type to create the patch on HP-UX? (Yes, I could copy and produce a patch in my Linux). As soon as I'll be able to produce the patch, I'll send it (Question: May I attach a file to the newsgroup mail?) Giuseppe Giuseppe, sure attach it for review. In fact I'm still curious what exactly your patch does. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] NAT ?
Hello Jahir, I don't know what others are using, but we're using our own IIOP proxy know as ObjectWall. http://www.objectwall.com/ Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Sun, 2 Apr 2006, jahirhussain jiyasudeen wrote: Hello, would like to know how can we make client to access the server using NAT(Network address translation) IPaddress. Is Anybody has any experiece using mico on NAT environment.The client that receives the remote object from the server makes the subsequent request using the server ipaddress . I would like to change is into NAT address . How can i do it ? regards JahirHussain -- ___ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10 ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Dump (and load) idl classes
Hello Giuseppe, could you be so kind and send me your patches in either unified (-u diff option) or context (-c diff option) format? This way they are also applicable to sources where some changes were done. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Thu, 30 Mar 2006, Giuseppe Burgarella wrote: Ok, I think this is a proper format (see the attachment). Please, keep in mind that this version is just to solve my problems. If you want a good code, complete, to cover all the possible cases, I can do it in some evening but you should way for it. Moreover, if I can use some other way to obtain the same service, please, tell me. Remember: to enable the patch, you shall define the macro "DEBUG_MICO_CLASSES" in compilation time. You'll obtain the new version of the idl precompiler. Best Regards (and let me know) Giuseppe (See attached file: Debug_Mico_Class.beta.tar.gz) PS: my starting baseline was mico-2.3.11. PPS: the file names are very simple: include_mico_sequence.h.diffs are the diffs about the [micodir]/include/mico/sequence.h idl_codegen-c++-common.cc.diffs are the diffs about the [micodir]/idl/codegen-c++-common.cc and so on ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] MICO books?
Hi Joost, yes, it is, we just need to update MICO website to include it into books. Cheers, Karel On Mon, 10 Apr 2006, Joost Kraaijeveld wrote: Hi, Is the book mentioned at http://www.mico.org/docu.html about the inner working of MICO the same book as mentioned on Arno Puder's homepage: "Distributed Systems Architecture: A Middleware Approach" Arno Puder, Kay Römer, and Frank Pilhofer Morgan Kaufman ISBN: 1-55860-648-3 TIA Joost ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] mico 2.3.12 compiling error
Hello, please don't use BOA-based examples, but rather have a look at POA and its examples in demo/poa/* directories. FYI: BOA was completely removed between 2.3.11 and 2.3.12 releases. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Mon, 10 Apr 2006, rosette nguessi wrote: hello, when i compile the mico application (account_impl) which is in doc of mico; some error provide : error C2504: 'Account_skel' : base class undefined. but when i type: mico-cpp -I account_impl.cc account_impl.o , i have got this crashes: unknow include . thanks for some help - Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta. ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] mico 2.3.12 : no such file or directory
type `make' to compile demo (or `gmake' on Solaris and *BSDs). FYI: mico-cpp is just MICO's preprocessor which is not intended to be invoked directly from command-line. It's invoked automatically from IDL compiler. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Thu, 13 Apr 2006, rosette nguessi wrote: hello karel, i test what you say ie the example in doc mico which is example\poa\account-1. but when i type : mico-cpp server.cc -o server.o for compilation, i get error like this: in file include from server.cc: account.h:8:no include path in which to find corba.h account.h:9:no include path in which to find mico/throw.h server.cc:14:no include path in which to find fstream.h i don't know why, however i indicate the include file,executable file and library fil in options of visual c++ 7.1 thanks for your help. - Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services pr?f?r?s : v?rifiez vos nouveaux mails, lancez vos recherches et suivez l'actualit? en temps r?el. Cliquez ici. ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] static library
If you don't need static libs, feel free to disable them from the build (--disable-static) Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Thu, 13 Apr 2006, rosette nguessi wrote: hello, is it necessary to build a static version of mico libraries? what is the function in the application that we build? thanks - Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services pr?f?r?s : v?rifiez vos nouveaux mails, lancez vos recherches et suivez l'actualit? en temps r?el. Cliquez ici. ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Mico, GTK, and callbacks
Hello,
first of all: which MICO version in which configuration do you use? Also
what's your platform and C++ compiler versions?
From your ``server->checkClient(this)'' I have a feeling you are using
BOA-based server/callback and would also be interested to know if you use
multi-threaded MICO.
On Wed, 5 Apr 2006, Mark Richardson wrote:
I've made the simple mico/gtk demo in mico/demo/dispatcher/gtkmico and it works
fine. So I added onto the IDL to come up with this..
module HelloModule {
interface HelloClient {
void clientHello(in string stringIn);
};
interface HelloServer {
void hello(in string stringIn);
void checkClient(in HelloClient clientIn);
};
};
I got this part to work as well (client calls server->checkClient(this) and server then
calls clientIn->clientHello("back at ya")).
So then I changed the server to be a non-gui server and created an imr to
activate it. So stand alone server can be started by just starting the client,
or using an imr activate HelloServer. However, the client bombs on the
following call...
CORBA::Object_var serverObj=orb->bind("IDL:HelloModule/HelloServer:1.0");
If I use the -ORBDebugLevel 5 -ORBDebug all when starting the client, I get
the following..
IIOPProxy::add_invoke: .
Out Data ...
ORB::wait for 0x80f5478
Memory fault
There are 2 way to make it work (neither of these work for my application).
1. Change all of the interface functions to oneway
Why do that? Rather fix your demo starting script IMHO.
2. perform an iordump on the server ior and get the address (most
specifically the port), then call Client -ORBBindAddr with the address
Do you use correct -ORBBindAddr while starting your client? This should be
the adder of your micod, not of your to be started server...
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Warnings with mico-2.3.12
On Wed, 5 Apr 2006, Raimund Mettendorf DE-HILDEN wrote: Hi Sorin Mustaca, I have the following warnings after compile with Microsoft Visual Studio 7.1.3088 c:\mico-2.3.12\mico\include\mico\dii.h(114) : warning C4267: 'return' : conversion from 'size_t' to 'CORBA::ULong', possible loss of data c:\mico-2.3.12\mico\include\mico\dii.h(156) : warning C4267: 'return' : conversion from 'size_t' to 'CORBA::ULong', possible loss of data c:\mico-2.3.12\mico\include\mico\dii.h(193) : warning C4267: 'return' : conversion from 'size_t' to 'CORBA::ULong', possible loss of data Can you help? Basically the question is: 1) what's the size of `CORBA::ULong' on your platform? IMHO it is 4 bytes. 2) what's the size of `size_t' on your platform? IMHO it should also be 4 bytes, anyway please check by simple test app and let us know. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Warnings with mico-2.3.12
On Fri, 14 Apr 2006, Giuseppe Burgarella wrote:
Hi,
I had a look at my std's lib code and the mico definitions:
- the std::size_t type is always defined as "typedef unsigned long size_t"
(obviously, if no other definition was already done)
- the mico's CORBA::ULong is defined (based on the compiling environment)
as "unsigned long" (if it is 4 bytes) or as "unsigned int" (if it is 4
bytes).
Yes, since CORBA ULong type is defined as 4 bytes long unsigned.
So, in a machine where the "unsigned long" is NOT 4 bytes number , we'll
obtain:
- std::size_t is an unsigned long (that can be a 64 bits number)
- CORBA::ULong is an unsigned int (that is a 32 bits number)
True! The problem is that Raimund seems to use Windows and I automatically
expected he is using 32bit windows together with 32bit development
environment. It seems I've been mistaken, since otherwise he should not
received those warnings.
I think that this is the reason of that warning message: when the
vector::size_t is returned as a CORBA::ULong, it is casted from 64 bits to
32 bits.
Moreover, I think that the warning is not be so important because both the
numbers are "unsigned" and so you'll obtain an error only in case of a
vector with more than 2^32 values (not so usual).
True! And in addition we're not allowed to change the type from ULong to
something bigger, since the problematic count operations are defined by
the IDL to C++ mapping. See 03-06-03 (c++ 1.1) and ``1.29.2 NVList C++
Class'' chapter:
// C++
class NVList
{
public:
ULong count() const;
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] CORBA proxy crashes on broken connection
Hello Enrico, thanks for reporting this issue! I've been able to reproduce it on the latest development sources. Anyway, it's only reproducible while using single-threaded MICO. Perhaps the most easier workaround for your is to try multi-threaded build for your MICO based application (at least proxy). Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Thu, 13 Apr 2006, Enrico Marcenaro wrote: Hi All, this is my simple example that crashes when client close connection. This is the scenario: 3. 1. 2. client -- MICO(single thread)-> proxy -MICO(single thread)> server <- 5. < 4. 1. client call a method on proxy. 2. proxy reply the request to the server. 3. during server manage proxy request, client goes down. 4. server reply to the proxy. 5. proxy response (crash). so if the client call the proxy, that have to get the response from the server, and then go down proxy crashes on the response after the server has replied. [...] ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] feeding IDL files to IFR: child process lost (is SIGCHLD ignored or trapped?)
Hello, which combat version do you use? And what's the output of the MICO IDL compiler when invoked with `--config' param? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Tue, 25 Apr 2006, William Taylor wrote: I am running under RedHat Enterprise Linux WS release 4 (Nahant Update 3), with gcc 3.4.5, trying to run idl2tcl: PATH /home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/mico/2.3.12/mico/lib/../bin:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/combat-0.7.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin:/home/wtaylor/bin:/home/wtaylor/PlanWorksProject/PlanWorks/java/lib/apache-ant/bin:/home/wtaylor/bin LD_LIBRARY_PATH /home/wtaylor/L2Skunk/mba/cpp/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/mico/2.3.12/mico/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/combat-0.7.3/lib:/usr/X11R6/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/tclTk8.3/lib:/usr/X11R6/lib:/usr/lib:/usr/local/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/tclTk8.3/lib/Tktable2.6 Error in startup script: error while feeding IDL files to IFR: error waiting for process to exit: child process lost (is SIGCHLD ignored or trapped?) child process exited abnormally while executing "exec $TCL_MICO_LIB/../bin/idl2tcl --impl $CORBA_DIR/LivingstoneCorba.idl" This was successful previously under RedHat 8, gcc2.95.3, mico 2.3.11, & combat 0.7.3 Thanks for any suggestions, ==> William -- William Taylor > Intelligent Systems Division, Code TI NASA Ames Research Center - voice:(650)604-3364, fax:(650)604-3594 Moffett Field, CA 94035-1000 [EMAIL PROTECTED]http://ic.arc.nasa.gov/people/taylor/ ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Support of IPv6
On Fri, 28 Apr 2006, Hanspeter Halle wrote: Hi all, I've built a MICO based client application which uses services of a server implemented by another company using another CORBA framework. The client runs on a Solaris system and is connected to the server via LAN. The server developers do now plan to migrate the network to IPv6. Does anybody have experiences with that? Yes, IPv6 is nice for various of its features. Have a look at http://www.6bone.net/ and try to get connected with http://www.hexago.com/index.php?pgID=20 or any other IPv6 gateway. I've had a short look in the MICO sources and it seems that IPv6 is not directly supported by MICO. Is it possible to connect a CORBA IPv4 client with a IPv6 server? Perhaps with the help of translation software or routing tricks? Uff, IMHO much better is to add IPv6 support directly to MICO. We've written very rough prototype for it and got demo/poa/hello-1 working over IPv6. The problem is that this project is now in limbo because of missing funding. If you are interested in its continuation, please contact me off list. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] feeding IDL files to IFR: child process lost (is SIGCHLD ignored or trapped?)
William, at the first I would recommend disabling threading with --disable-threads configure option and recompiling your MICO and application (combat). That's because IIRC Combat is not thread-safe. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Wed, 26 Apr 2006, William Taylor wrote: Original Message Subject: Re: [mico-devel] feeding IDL files to IFR: child process lost (is SIGCHLD ignored or trapped?) Date: Tue, 25 Apr 2006 16:48:21 -0700 From: William Taylor <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: Computational Sciences Div - Code TI To: Karel Gardas <[EMAIL PROTECTED]> CC: William Taylor <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Karel - I am using combat 0.7.3. ngorongoro.wtaylor 36> cd L2Skunk/l2-tools/stanley-jmpl/support/mico/2.3.12/mico/bin ngorongoro.wtaylor 37> ls idl* iordump* mico-ar* mico-config* micod*mico-shc++* mkdepend* imr* ird* mico-c++* mico-cpp* mico-ld* mico-shld* ngorongoro.wtaylor 38> ./idl --config MICO version...: 2.3.12(MT) supported CORBA version: 2.3 CCM support: no exceptions.: CORBA compliant modules are mapped to..: namespaces STL is.: system supplied Security support...: TLS/SSL, CSIv2 loadable modules...: yes multi-threading: yes (Posix Draft 10 PThreads) ngorongoro.wtaylor 39> ==> William Karel Gardas wrote: Hello, which combat version do you use? And what's the output of the MICO IDL compiler when invoked with `--config' param? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Tue, 25 Apr 2006, William Taylor wrote: I am running under RedHat Enterprise Linux WS release 4 (Nahant Update 3), with gcc 3.4.5, trying to run idl2tcl: PATH /home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/mico/2.3.12/mico/lib/../bin:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/combat-0.7.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin:/home/wtaylor/bin:/home/wtaylor/PlanWorksProject/PlanWorks/java/lib/apache-ant/bin:/home/wtaylor/bin LD_LIBRARY_PATH /home/wtaylor/L2Skunk/mba/cpp/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/mico/2.3.12/mico/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/combat-0.7.3/lib:/usr/X11R6/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/tclTk8.3/lib:/usr/X11R6/lib:/usr/lib:/usr/local/lib:/home/wtaylor/L2Skunk/l2-tools/stanley-jmpl/support/tclTk8.3/lib/Tktable2.6 Error in startup script: error while feeding IDL files to IFR: error waiting for process to exit: child process lost (is SIGCHLD ignored or trapped?) child process exited abnormally while executing "exec $TCL_MICO_LIB/../bin/idl2tcl --impl $CORBA_DIR/LivingstoneCorba.idl" This was successful previously under RedHat 8, gcc2.95.3, mico 2.3.11, & combat 0.7.3 Thanks for any suggestions, ==> William -- William Taylor > Intelligent Systems Division, Code TI NASA Ames Research Center - voice:(650)604-3364, fax:(650)604-3594 Moffett Field, CA 94035-1000 [EMAIL PROTECTED]http://ic.arc.nasa.gov/people/taylor/ ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- William Taylor > Intelligent Systems Division, Code TI NASA Ames Research Center - voice:(650)604-3364, fax:(650)604-3594 Moffett Field, CA 94035-1000 [EMAIL PROTECTED]http://ic.arc.nasa.gov/people/taylor/ -- William Taylor > Intelligent Systems Division, Code TI NASA Ames Research Center - voice:(650)604-3364, fax:(650)604-3594 Moffett Field, CA 94035-1000 [EMAIL PROTECTED]http://ic.arc.nasa.gov/people/taylor/ ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] mico/cygwin
Hello, on Cygwin or generally on Windows you need to link created library against all the required libraries. So please fix problematic makefile manually and continue. If you have some idea how to fix it in general or even patch for it, please do not hesitate to post it here. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Fri, 5 May 2006, bruno patin wrote: Dear all, I try to compile mico (2.3.12) on cygwin (1.5.19 with everything installed). I search on the net for mails indicating the pbs encountered but what I saw was only tackling threadingpbs. My pb is I think an easy one. I have libssl installed (/usr/lib) but the make command gives this output: --- for i in admin include; do make -C $i adm || exit 1; done make[1]: Entering directory `/home/bruno/mico/admin' make[1]: Rien `a faire pour << adm >>. make[1]: Leaving directory `/home/bruno/mico/admin' make[1]: Entering directory `/home/bruno/mico/include' make[1]: Rien `a faire pour << adm >>. make[1]: Leaving directory `/home/bruno/mico/include' for i in orb ir idl auxdir coss ccm; do make -C $i lib || exit 1; done make[1]: Entering directory `/home/bruno/mico/orb' make[1]: Rien `a faire pour << lib >>. make[1]: Leaving directory `/home/bruno/mico/orb' make[1]: Entering directory `/home/bruno/mico/ir' rm -f libmicoir2.3.12.dll /home/bruno/mico/./admin/mico-shld -o libmicoir2.3.12 ir_skel.pic.o ir_impl.pic.o -L../libs -lmico2.3.12 ../orb/libmico2.3.12.dll c++ -mthreads -shared '-L../libs' -o libmicoir2.3.12.dll 'ir_skel.pic.o' 'ir_impl.pic.o' '-lmico2.3.12' '../orb/libmico2.3.12.dll' ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0xd09): r?f?rence ind?finie vers ? _X509_STORE_CTX_get_error ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0xd14): r?f?rence ind?finie vers ? _X509_STORE_CTX_get_error_depth ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0xd5f): r?f?rence ind?finie vers ? _X509_verify_cert_error_string ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0xfd3): r?f?rence ind?finie vers ? _SSL_shutdown ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0xfe5): r?f?rence ind?finie vers ? _SSL_shutdown ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x1188): r?f?rence ind?finie vers ? _SSL_get_shutdown ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x279a): r?f?rence ind?finie vers ? _CRYPTO_num_locks ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x280a): r?f?rence ind?finie vers ? _CRYPTO_num_locks ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2842): r?f?rence ind?finie vers ? _CRYPTO_num_locks ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x285a): r?f?rence ind?finie vers ? _CRYPTO_set_locking_callback ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2866): r?f?rence ind?finie vers ? _CRYPTO_set_id_callback ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a35): r?f?rence ind?finie vers ? _SSL_library_init ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a3a): r?f?rence ind?finie vers ? _SSLv23_method ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a42): r?f?rence ind?finie vers ? _SSL_CTX_new ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a5d): r?f?rence ind?finie vers ? _SSL_CTX_set_cipher_list ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a81): r?f?rence ind?finie vers ? _SSL_CTX_set_verify ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a8c): r?f?rence ind?finie vers ? _SSL_load_client_CA_file ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2a9d): r?f?rence ind?finie vers ? _SSL_CTX_set_client_CA_list ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2aba): r?f?rence ind?finie vers ? _SSL_CTX_use_certificate_file ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2ae6): r?f?rence ind?finie vers ? _SSL_CTX_use_PrivateKey_file ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2b02): r?f?rence ind?finie vers ? _SSL_CTX_check_private_key ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2b16): r?f?rence ind?finie vers ? _SSL_load_error_strings ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2b31): r?f?rence ind?finie vers ? _SSL_CTX_load_verify_locations ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x2e80): r?f?rence ind?finie vers ? _SSL_CTX_set_default_verify_paths ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x31dc): r?f?rence ind?finie vers ? _OBJ_txt2nid ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x3239): r?f?rence ind?finie vers ? _X509_NAME_get_text_by_NID ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x3293): r?f?rence ind?finie vers ? _X509_NAME_oneline ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x352a): r?f?rence ind?finie vers ? _X509_get_subject_name ? ../libs/libmico2.3.12.a(ssl.o):ssl.cc:(.text+0x370f): r?
Re: [mico-devel] ird, code sets patches
Hello Nikolay, thanks for those 4 patches. I've reviewed them and merged into the mico development source tree. See our (MICO) darcs repository on mico.org: http://www.mico.org/down.html http://mico.org/mico-darcs-repository/ Thanks! Karel On Thu, 11 May 2006, Nikolay Logvinov wrote: Hello, Karel! I'd like to suggest several small patches: 1) ir/main.cc.patch * adds option --dontsavedb to ird * adds signal USR1 to save db 2) orb/codeset.cc.patch orb/uni_strtypes.h.patch orb/uni_fromuni.cc.patch orb/uni_touni.cc.patch * fix small bug for code set KOI8-R * add code set IBM-866 (CCSID 00866); PC Data Cyrillic 2 All of the best, Nikolay Logvinov. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] pb : account-3 with imr
Hello, if you are using Windows please have a look into demo/poa/account-3/account Unix starting script. Everything what you need should be there. You can also read imr(1) man page for more information. Cheers, Karel On Thu, 11 May 2006, rosette nguessi wrote: hello, i got error with account-3 which is in demo\poa; the pb is imr, i don't understand. please can you tell me how can i do to execute it. however the others account are be executed succeffuly. thanks - Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Re: Problem with Demarshalling of Abstract Interface
How does generated IDL code look? IMHO this might be a bug in MICO
demarshalling, but also big chance is that it is just user code mistake.
Without as simple as possible test case it's hard to judge.
Cheers,
Karel
On Tue, 16 May 2006, Gurminder Singh wrote:
Hi,
I am having the Java RMI server and c++ client. I am able to pass value
types successfully. But facing problem when I try to pass the Java
Serializable object (which reverse map to Valuetype in IDL) containing
empty java interface (which is reversed mapped to Abstract Interface in
IDL). The demarshal of the Abstractbase class in CORBA is not able to
handle the demarshalling of the Abstract interface which is initialize
with valuetype at runtime.
The java serializable object is
public class dummyComplexType implements Serializable{
private long complexID;
private Value complexVal;
public dummyComplexType() {
super();
// TODO Auto-generated constructor stub
}
public long getComplexID() {
return complexID;
}
public void setComplexID(long complexID) {
this.complexID = complexID;
}
public Value getComplexVal() {
return complexVal;
}
public void setComplexVal(Value complexVal) {
this.complexVal = complexVal;
}
}
The Value above is an empty interface declared as
public interface Value extends Serializable {
//Empty interface
}
At runtime the Value is initialized with java serializeable object which
is derived from the Value interface.
Note:
When I pass the Value as return type of operation then it is properly
demarshaled.
On Debuging the mico I found that when Value is passed as return type of
some operations it is demarshal as valuetype but when I pass the
dummyComplexType which contains the Value then AbstractBase demarshel
class treat it as object ref. I don't know what is reason of treating it
as object ref when actually it initialize with value type at runtime. Is
it a bug in MICO in demarshalling?
Please help and guide me
Tons of thanks in advance
--Regards
Guminder Singh
Member (SDG)
Core Technologies Group
Quark Media House pvt Ltd.
A- 45 industrial Area (Mohali)
Phone: 91 -172-2299440
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
CONFIDENTIALITY NOTICE
This e-mail transmission and any documents, files, or previous e-mail
messages appended or attached to it, may contain information that is
confidential or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the intended
recipient, you are hereby notified that you must not read this
transmission and that any disclosure, copying, printing, distribution,
or use of the information contained or attached to this transmission is
STRICTLY PROHIBITED. If you have received this transmission in error,
please immediately notify the sender by telephone xxx.xxx. or return
e-mail message [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> and
delete the original transmission, its attachments, and any copies
without reading or saving in any manner. Thank you.
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] if not gcc bug
On Wed, 24 May 2006, Nikolay Logvinov wrote: Hello, Karel! Look at the following patch: --- orig/orb/codeset.cc +++ mod/orb/codeset.cc @@ -719,7 +720,7 @@ char _f[flen+1]; #else CORBA::String_var _f; -if (_from->codepoint_size() != 1) +//if (_from->codepoint_size() != 1) _f = CORBA::string_alloc (flen); #endif I suppose that the special case below for the simple codesets must be follow, but nothing. So, I commented out condition operator. Hi Nikolay, yes, the code as it is now looks quite buggy. What do you see when you use IBM's C++ on AIX? Does the code crash as I assume it should? What do you see when you run demo/codesets? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Mico on Red Hat Enterprise
Hello Dugan, RHEL4 is one of our testing target and we have not seen any issue like you describe yet. I'm talking here about simple callbacks. BTW: Do you use C++ compilers distributed with RHEL and FC? Or do you install your own version/builds? BTW2: For debugging you need to use -ORBDebug command-line option. See include/mico/util.h Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Wed, 14 Jun 2006, Dugan, Jeffery wrote: Hello Developers Configuration and Versions: Both C++ (Mico) and Java (JacORB) code are compiled against the same IDL. Mico Version: 2.3.11 JacORB Version: 2.2.2 (June 1, 2005) GIOP and IIOP versions are 1.2, and this information is defined in a .micorc file RedHat Fedora Core 4 (2.6.11-1) RedHat Enterprise 4 Update 3 (2.6.9-34) Interface: A C++ application looks-up and gets a CORBA object reference to a Java application. The C++ application uses the CORBA object reference to the Java application to pass a CORBA object reference of itself to the Java application. The Java application receives and stores the C++ CORBA object reference. Later, the Java application uses the stored C++ CORBA object reference to notify the C++ application of a change. Problem: On RedHat Enterprise 4 Update 3 (2.6.9-34), as soon as the Java application uses the stored C++ CORBA object reference to notify the C++ application of a change, the C++ application dies with a segmentation fault. Using gdb reveals that the C++ application is dying somewhere in the Mico skeleton/stub code: dispatch() which is called by invoke() which is called by doinvoke() which is called by perform_invoke() which is called by local_invoke() which is called by invoke_async() which is called by callback() etc... On RedHat Fedora Core 4 (2.6.11-1), the C++ application receives the notification of a change from the Java application and continues running without any problems. Notes: On RedHat Enterprise 4 Update 3 (2.6.9-34), where the CORBA interface doesn't work, we have tried turning up the debug on Mico with -ORBDebugLevel 5, -ORBDebugLevel 50, and -ORBDebugLevel 5000 but we don't see any debug output anywhere. Is there any debug? If so, where does it go? On RedHat Enterprise 4 Update 3 (2.6.9-34), where the CORBA interface doesn't work, we ran iordump on an IOR and confirmed the GIOP and IIOP versions to be 1.2. On RedHat Fedora Core 4 (2.6.11-1), where the CORBA interface works, we ran iordump on an IOR, but it died with a segmentation fault. Thanks, Jeff Dugan -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Maybe This is a MICO 2.3.12 Bug
Hello, this is an interesting issue. How does your server sources look like? Also what hardware platform and GCC compiler version do you use? In such cases it's always the best to provide as simple as possible test-case. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Fri, 16 Jun 2006, ?? wrote: OS; linux debian compiler type ; gcc [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1120103344 (LWP 25522)] 0x406b9642 in std::__default_alloc_template::allocate () from /usr/lib/libstdc++.so.5 (gdb) backtrace #0 0x406b9642 in std::__default_alloc_template::allocate () from /usr/lib/libstdc++.so.5 #1 0x40319596 in MICO::GIOPRequest::get_in_args () from /usr/local/lib/libmico2.3.12.so #2 0x4035188e in CORBA::StaticServerRequest::read_args () from /usr/local/lib/libmico2.3.12.so #3 0x080552e2 in POA_dbApi::dispatch () [...] output: [3508982951 - 1099353008] poa_impl.cc:1018: assertion failed ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] build mico on powerpc-ibm-aix5.1.0.0 error message
Hello, I would recommend to use some other more recent GCC version on your system. What version do you use btw? You can also use 2.3.12 release instead of RC3... Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Mon, 29 May 2006, [EMAIL PROTECTED] wrote: ?? hello?? i tried to build mico 2.3.12 RC3 on powerpc-ibm-aix5.1.0.0 and got the following error message gmake[1]: Entering directory `/vasd_gate/zxsmg/corba/mico/orb' g++ -I../include -O2 -Wall -D_REENTRANT -DPIC -fexceptions -c orb.cc -o orb.pic.o In file included from /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../include/g++-3/algorithm:34, from orb.cc:74: /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../include/g++-3/stl_algo.h:449: declaration of `operator MICO_LongDouble' as non-function orb.cc: In function `CORBA::ORB *CORBA::ORB_init (int &, char **, const char *)': orb.cc:4047: warning: control reaches end of non-void function `CORBA::ORB_init (int &, char **, const char *)' gmake[1]: *** [orb.pic.o] Error 1 gmake[1]: Leaving directory `/vasd_gate/zxsmg/corba/mico/orb' gmake: *** [system] Error 1 /vasd_gate/zxsmg/corba/mico> excute the "configure" got message : /vasd_gate/zxsmg/corba/mico>configure loading cache ./config.cache [...] checking creation of shared lib... ok checking if binary linked against shlib works... ok checking for exceptions in shared libraries... failed, exceptions in shared libs disabled [...]___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] --vc-sequence-reference-bug-workaround
Hello, --vc-sequence-reference-bug-workaround was added to the 2.3.12 release just to workaround some issues in the VC++ 2003 compiler, since this compiler refuses to compile some well formed C++ code in files generated by the MICO IDL compiler. So if you see run-time issue, this is certainly not related to --vc-sequence-reference-bug-workaround, although might be related to low quality of VC++. Anyway, we're always interested to know more details, preferably as simple as possible test case is the best way to debug this issue. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Wed, 28 Jun 2006, J. Scott Evans wrote: Hello, I was looking through the archives to find some history on the "VC++ sequence reference bug" that is referenced in the release notes for version 2.3.12 but didn't see any discussion of the bug. Would someone please provide some background on this bug? I'm running into a problem involving a sequence of structs that contain sequences. Using Red Hat Enterprise (2.4.21-40.ELsmp) my server works fine but with Microsoft Visual C++ .NET 2003 (version 7.1.3088) the server fails unpredictably (with differing degrees of severity) after the sequence of structs is returned to the client. If I try returning a sequence of structs containing only basic types (including string) everything works fine. Am I seeing the VC++ sequence reference bug or something else altogether? I can post some example code that reproduces the error if that would help. Thanks, Scott ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] [SECURITY FIX 001]: MICO 2.3.12 _non_existent call vulnerability
Folks, we have been notified about possible DoS attack which involves calling _non_existent operation on the application server side with corrupted target object ID. We have successfully duplicated this issue and prepared a fix. The fix has been tested for regressions and it is regression free. If you are using MICO application on the public network, we strongly recommend you to apply it. It is against the MICO 2.3.12 release. See http://mico.org/down.html or get it directly from http://mico.org/errata/mico-2.3.12-secfix1.diff Cheers, Karel Karel Gardas, Principal Software Engineer, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS, UK Tel. +44 1223 420252, Fax. +44 870 762 6041 USA: Tel.+1-800-898-9148, Fax +1-360-933-9591 [EMAIL PROTECTED], www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Best source of up-to-date mico documentation?
Hello, new MICO book is already out and using "Distributed Systems Architecture" title. Please check your local book store or preferred e-shop. If it does not fulfill your needs, you can also order MICO/CORBA training provided by ObjectSecurity. In this case please contact me off-list. Cheers, Karel On Mon, 10 Jul 2006, Irvine, Chuck R [LTD] wrote: I've just downloaded, built, and installed Mico and am ready to start digging in. Looking at the included doc file, doc.ps, it seems to be out of date. I looked through the email archive and saw mention of forth coming documentation published by Morgan Kaufmann. Whatever became of that? In any case, what would folks recommend as the best source of documentation for mico specific functionality? Thanks Chuck ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] RE: Mico-devel Digest, Vol 35, Issue 3
Hi Raimund, On Wed, 12 Jul 2006, Raimund Mettendorf DE-HILDEN wrote: Hi YewMing, yes, I did it in the same way. But even demos are not up-to-date. Some, e.g., still use the boa approach, which is not supported by mico-2.3.12 any more. please let me know any demo which is still using BOA. It should certainly be removed. Is someone able to provide an update of the "README-WIN32" section "How to compile mico as a static library with VC++"? Isn't MICO compiled for both DLL and LIB by default? Please check your mico/win32-bin directory to see which files are there. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- Kind regards, Raimund -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Dienstag, 11. Juli 2006 21:00 To: mico-devel@mico.org Subject: Mico-devel Digest, Vol 35, Issue 3 Send Mico-devel mailing list submissions to mico-devel@mico.org To subscribe or unsubscribe via the World Wide Web, visit http://www.mico.org/mailman/listinfo/mico-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Mico-devel digest..." Today's Topics: 1. RE: Best source of up-to-date mico documentation? (Chen YewMing-CYC033) 2. Re: Best source of up-to-date mico documentation? (Karel Gardas) -- Message: 1 Date: Tue, 11 Jul 2006 11:18:06 +0800 From: "Chen YewMing-CYC033" <[EMAIL PROTECTED]> Subject: RE: [mico-devel] Best source of up-to-date mico documentation? To: Cc: "Irvine, Chuck R \[LTD\]" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi Chuck, I also realized that the docs are not really helpful. For me, I used the included demo sample codes. Try digging around the demo directory. Regards, YewMing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Irvine, Chuck R [LTD] Sent: Tuesday, July 11, 2006 2:44 AM To: mico-devel@mico.org Subject: [mico-devel] Best source of up-to-date mico documentation? I've just downloaded, built, and installed Mico and am ready to start digging in. Looking at the included doc file, doc.ps, it seems to be out of date. I looked through the email archive and saw mention of forth coming documentation published by Morgan Kaufmann. Whatever became of that? In any case, what would folks recommend as the best source of documentation for mico specific functionality? Thanks Chuck ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Message: 2 Date: Tue, 11 Jul 2006 12:00:46 +0200 (CEST) From: Karel Gardas <[EMAIL PROTECTED]> Subject: Re: [mico-devel] Best source of up-to-date mico documentation? To: "Irvine, Chuck R [LTD]" <[EMAIL PROTECTED]> Cc: mico-devel@mico.org Message-ID: <[EMAIL PROTECTED]> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hello, new MICO book is already out and using "Distributed Systems Architecture" title. Please check your local book store or preferred e-shop. If it does not fulfill your needs, you can also order MICO/CORBA training provided by ObjectSecurity. In this case please contact me off-list. Cheers, Karel On Mon, 10 Jul 2006, Irvine, Chuck R [LTD] wrote: I've just downloaded, built, and installed Mico and am ready to start digging in. Looking at the included doc file, doc.ps, it seems to be out of date. I looked through the email archive and saw mention of forth coming documentation published by Morgan Kaufmann. Whatever became of that? In any case, what would folks recommend as the best source of documentation for mico specific functionality? Thanks Chuck ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- -- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel End of Mico-devel Digest, Vol 35, Issue 3 **
RE: [mico-devel] Connecting to an Orbix name service
Hello,
MICO certainly should not core dump. If it does, I'm interested to know
more details about this issue. On which platform do you run your MICO?
Which compiler have you used to compile it? Could you be so kind and get
some backtrace from the crash?
Thanks,
Karel
On Fri, 14 Jul 2006, Irvine, Chuck R [LTD] wrote:
After turning on mico debug output, I discovered the problem. I was
using a raw ip address rather than a host name to talk to the name
service. I was using the ip address because the hostname isn't visible
to my workstation. After inserting an appropriate entry into my
ect/hosts file, things are working now.
However, I would think that mico shouldn't core dump on this kind of
error. Thoughts?
Thanks,
Chuck
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Irvine, Chuck R [LTD]
Sent: Friday, July 14, 2006 9:49 AM
To: mico-devel@mico.org
Subject: [mico-devel] Connecting to an Orbix name service
I'm new to Corba (and Mico) and could sure use a little help
I'm writing a Corba client using Mico 2.3.12 which will talk to an Orbix
6.x server. First, can anyone verify that this should work?
The first thing I need to do is connect to the Orbix naming service and
I'm getting a segfault. I'm probably not doing something right. My call
to "orb->resolve_initial_references ("NameService")" returns without
error, but when I call "CosNaming::NamingContext::_narrow (nsobj)" on
the name service object, I get a segfault. I call my code thus:
./get-orbix-name-service -ORBInitRef
NameService=corbaloc::10.77.83.35:3075/NameService
My sample code is given below. Any help would be hugely appreciated.
Thanks,
Chuck
--get-orbix-name-service
#include
#include
using namespace std;
int main (int argc, char *argv[])
{
// ORB initialization
CORBA::ORB_var orb = CORBA::ORB_init (argc, argv, "mico-local-orb" );
CORBA::Object_var nsobj =
orb->resolve_initial_references ("NameService");
if (CORBA::is_nil(nsobj)) {
cerr << "oops, name service is nil" << endl;
exit(1);
}
CosNaming::NamingContext_var nc =
CosNaming::NamingContext::_narrow (nsobj);
if (CORBA::is_nil (nc)) {
cerr << "oops, I cannot access the Naming Service!" << endl;
exit (1);
}
cout << "acquired naming service" << endl;
return 0;
}
-
___
Mico-devel mailing list
Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
RE: [mico-devel] Connecting to an Orbix name service
On Fri, 14 Jul 2006, Irvine, Chuck R [LTD] wrote: Core file attached. Versions OS: Windows XP Pro Cygwin (uname): CYGWIN_NT-5.1 Gcc: gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Oh, cygwin! How has you configured your MICO? Anyway, it would be good to enable debugging by --enable-debug, recompile, retest and obtain proper stacktrace by running the application inside gdb: gdb --args client.exe run bt and sent it here. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Mico 2.3.12 / Orbix 6.x Interoperability
Yes, MICO should interoperate well with Orbix. The problem you see is probably caused by some platform specific (cygwin) issue. As I said, please provide us with crash backtrace and we'll hopefully be able to tell you more. Also MICO is CORBA 2.3-3.0 compliant depending on which part of it you take into account. From interoperability point of view it supports IIOP/GIOP 1.0-1.2 and in fact I would be really surprised to see any interooperability issues with other compliant ORBs. Cheers, Karel On Fri, 14 Jul 2006, Irvine, Chuck R [LTD] wrote: Would someone please tell me whether MICO 2.3.12 should be interoperable with Orbix 6.x? Also, what is the level of Corba compliance of MICO 2.3.12? Thanks, Chuck ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Short bug report
Hello,
I'm not able to duplicate your issue with post 2.3.12 development tree:
silence:/tmp$ cat f2.idl
interface foo {
sequence bar();
};
silence:/tmp$ idl f2.idl
f2.idl:2: scoped name 'int' not defined
silence:/tmp$ idl --config
MICO version...: 2.3.12(MT)
supported CORBA version: 2.3
CCM support: no
exceptions.: CORBA compliant
modules are mapped to..: namespaces
STL is.: system supplied
Security support...: TLS/SSL, CSIv2
loadable modules...: yes
multi-threading: yes (Posix Draft 10 PThreads)
silence:/tmp$
I'm sure 2.3.12 should also work fine, so please give it a try instead of
2.3.11.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
On Fri, 14 Jul 2006, Donald Dade wrote:
Hello list,
With 2.3.11, it seems that the idl compiler doesn't like code of the form:
interface foo {
sequence bar();
};
I understand that the above is not correct idl (there should be a typedef
for sequence), but I often forget, and what I got was not an idl error
but a failed assertion:
TCKind: 19
idl: codegen-c++-util.cc:1226: void
CodeGenCPPUtil::emit_type_for_result(CORBA::IDLType*): Assertion `0' failed.
Just thought you might want to know, if you haven't seen this already.
Don
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] IMR hangs after stopping server
Hello Scott, do you have any simple demo/test demonstrating this behaviour? IMHO this sounds like a bug somewhere in micod and would like to duplicate it here. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- On Mon, 17 Jul 2006, J. Scott Evans wrote: Hello, I'm able to successfully create and activate servers with the imr but when I attempt to stop a server the imr simply hangs (after the server is successfully stopped). While the process is hung any attempts to use the imr in a separate process (e.g. to list servers) also hang. If I kill the hung process the imr hangs on any further requests so I have to kill micod and restart it as well was reconfigure the imr. Is this a bug? I'm using MICO 2.3.12 and Red Hat Enterprise Linux Version 4. Thanks, Scott ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] orb->shutdown( X ) hang up
Laurent,
could you be so kind and attach gdb into the hanging process and obtain
a backtrace? i.e.
$ gdb attach
bt
I'm curious since I've never seen shutdown hanging.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
On Tue, 18 Jul 2006, Laurent Marzullo wrote:
Hello,
I've write a little server which could be summary like this:
void
ONED::CosTransactionsApp::_sighandler( int )
{
SmartLocker( _request_shutdown )->value( true );
}
main()
{
signal( SIGINT , _sighandler );
signal( SIGTERM , _sighandler );
_orb = CORBA::ORB_init( _argc , _argv , "mico-local-orb" );
CORBA::Object_var obj = _orb->resolve_initial_references( "RootPOA" );
PortableServer::POA_var rootPOA = PortableServer::POA::_narrow( obj );
PortableServer::POAManager_var mgr = rootPOA->the_POAManager();
CORBA::PolicyList pl;
pl.length(2);
pl[0] = rootPOA->create_lifespan_policy( PortableServer::PERSISTENT );
pl[1] = rootPOA->create_id_assignment_policy( PortableServer::USER_ID );
PortableServer::POA_var factoryPOA = rootPOA->create_POA(
"TransactionService" , mgr , pl );
PortableServer::POA_var controlPOA = rootPOA->create_POA( "ControlPOA" , mgr
, pl );
TransactionFactoryImpl* servant =
new ONED::OTS::TransactionFactoryImpl( controlPOA , _orb );
PortableServer::ObjectId_varoid =
PortableServer::string_to_ObjectId( "TransactionService" );
factoryPOA->activate_object_with_id( oid , servant );
mgr->activate();
boolquit = false;
do {
if ( _orb->work_pending() )
_orb->perform_work();
quit = SmartLocker(_request_shutdown)->value();
} while ( ! quit );
std::cerr << "=> Shutdown ...";
_orb->shutdown( TRUE );
std::cerr << "[ok]\n";
return 0;
}
It seems that _orb->shutdown( ) hang up for ever end never return. I've tried
TRUE and FALSE as parameters, but "[ok]" is never printed while "=> Shutdown
..." is printed.
Any idea ?
+----+
+ Laurent Marzullo
+
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] IORInterceptor and TransactionService Policy
On Wed, 26 Jul 2006, Laurent Marzullo wrote: Hello all, I've write a TransactionCurrent implementation. I'm now trying to propagate this current context to server according to policy set in the IOR of the target object. I've read in the spec that, if, in a server, we try to create an object reference with both: OTSPolicy = FORBIDS or ADAPTS and InvocationPolicy = EITHER or UNSHARED an exception should be raised (exception = InvalidPolicy) (see TransactionService 1.4 -- 2.24) There is no such chapter in this spec. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] dynamic_cast issue on VS 2005 (java Server and c++ client(mico based)
On Wed, 26 Jul 2006, Gurminder Singh wrote: It is very strange that if i compile the client on VC7/Visual Studios 2002 then the same code works using the mico build 2.3.12 compiled on vc7 and Also on Gcc 401 version the same piece of code is working on mac osx using mico 2.3.12 build on mac 10.4.2 (Tiger).The client works perfectly In all these cases above no change has been made in the Java Server. The main client code is written in the PreferenceClient.cpp file. Please help out to solve the problem i am unable to understand whether it is an issue of the mico on vc8 or what ? When something is definitely working on some other platform and also on the same platform with using different compiler, I wouldn't consider it to be a problem and instead of it I would look elsewhere. For example VC8 is not supported officially yet, perhaps you've done some mistakes during hacking your MICO tree to support it? Also do you really trust this .0 MS compiler? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Source of Transaction service
Hello, sure, we are! The only legal requirement for inclusion in MICO tree is that the library part will be licensed under the terms of LGPL. Servers might be GPL. Cheers, Karel On Thu, 27 Jul 2006, Laurent Marzullo wrote: Hello, Would you be interested in the source of Transaction service once it will be finished (at least usable :-) regards ++ + Laurent Marzullo + ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Patch: ObjectId in poa_impl.cc
Hi Arne, thanks for you patch. I've merged it to the latest source tree. It is interesting that you hit this issue while using VC8. Have you also tried to run your test with any other supported compiler? I think that ObjectId ctors does not check for NULL pointers since they silently assumes sane ObjectId parameters. It might be interesting to see the test case which observed this issue. Thanks, Karel On Mon, 7 Aug 2006, Arne Pajunen wrote: Hi, attached is a patch for orb/poa_impl.cc (against 2.3.12, issue looks to be there in RC3 too) The problem is in MICOPOA::ObjectId::ObjectId's constructor. It doesn't initialize the idlength member, which results in a crash in some cases compiled under VC8 as a release version. (debug initializes to 0 so problem doesn't appear in debug version). f.eg. at the end of MICOPOA::POA_impl::invoke() is this (line 3319 in my poa_impl.cc): 1 POAObjectReference por2(poa, obj); 2 assert (por2.is_legal()); 3 InvocationRecord_var ir = new InvocationRecord (id, &por2, req, pr); where #1 initializes (or more like doesnt) por2's member oid with its default constructor, and #3 uses ObjectId's copy constructor on that. and the copy constructor, MICOPOA::ObjectId::ObjectId (const ObjectId & id, bool copy) blindly uses memcpy on the null pointer if idlength is non-zero (uninitialized in this case). This results in crashes, at least when compiled with Visual Studio 2005. Someone might also want to look at the copy constructor, it doesn't check the pointer members, i wonder if thats intentional or for performance. The patch simply makes the constructor initialize the idlength to 0. -- Arne Pajunen Software Engineer OpenTTCN Oy, Test and Test Control Components for Test System Vendors Web: http://www.openttcn.com -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] ClientRequestIntercetor and _narrow
On Thu, 27 Jul 2006, Laurent Marzullo wrote:
Hello,
I'm still trying to propagate my TransactionCurrent object.
So, now, I'm on 'send_request' of my client interceptor.
in case where there's no OTSPolicy defined for my target object
(here my code)
-
CosTransactions::OTSPolicy_var ots = CosTransactions::OTSPolicy::_nil();
try
{
CORBA::Policy_var p =
rqst_info->target()->_get_policy(
CosTransactions::OTS_POLICY_TYPE );
ots = CosTransactions::OTSPolicy::_narrow( p );
}
catch ( CORBA::BAD_PARAM& )
{
std::cerr << " -> No OTS_POLICY_TYPE find for object\n";
/*
CosTransactions::TransactionalObject_var to =
CosTransactions::TransactionalObject::_narrow( rqst_info->target() );
if ( !CORBA::is_nil( to ) )
{
std::cerr << " -> Setting OTS_POLICY_VALUE to ADAPTS \n";
CORBA::Any policyValue;
policyValue <<= CosTransactions::ADAPTS;
CORBA::Policy_var p = _orb_var->create_policy(
CosTransactions::OTS_POLICY_TYPE , policyValue );
ots = CosTransactions::OTSPolicy::_narrow( p );
}
*/
}
-
I would like to test if the target object inherite from 'TransactionalObject'
to be compliant with OTS 1.1 object (I know that is not a mandatory stuf but I
would like to do it).
So, I've wrotte the above code (in comment). But this code seem to loop because
of the _narrow that call the server and then the ClientRequestInterceptor.
I just want to know the better way to avoid this loop ?
1) idl --do-not-query-server-for-narrow
2) forget about 'TransactionalObject'
3) any other ?
3 is right! Please see how you can use PICurrent to deal with call loop.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---
___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] uncaught MICO exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0, not-completed)
On Thu, 20 Jul 2006, [EMAIL PROTECTED] wrote:
??
Hello, I am developing a distributed application using CORBA.
My client application in aix 5.2.0.0 works properly when the server
application is up . The server application run on windows.
If the server is down, then run the client app and get the following:
"
uncaught MICO exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0,
not-completed)
IOT/Abort trap(coredump)
"
In my prougramm the functions is :
int
lookup()
{
// ORB initialization
CORBA::ORB_var orb = CORBA::ORB_init(num, opt);
// Acquire a reference to the Naming Service
CORBA::Object_var nsobj =
orb->resolve_initial_references("NameService");
CosNaming::NamingContext_var nc =
CosNaming::NamingContext::_narrow(nsobj);
if(CORBA::is_nil(nc))
{
cerr << "oops, I cannot access the Naming Service!" << endl;
return(-1);
}
// Construct Naming Service name
CosNaming::Name name;
name.length(1);
name[0].id = CORBA::string_dup("upSendMsg");// "upSendMsg" is the
name of Naming Service
name[0].kind = CORBA::string_dup("");
// try to find that node in the Naming Service tree
CORBA::Object_var obj;
#ifdef HAVE_EXCEPTIONS
try
{
obj = nc->resolve(name);
}
catch(CosNaming::NamingContext::NotFound &exc)
{
cout << "NotFound exception." << endl;
return(-1);
}
catch(CosNaming::NamingContext::CannotProceed &exc)
{
cout << "CannotProceed exception." << endl;
return(-1);
}
catch (CosNaming::NamingContext::InvalidName &exc)
{
cout << "InvalidName exception." << endl;
return(-1);
}
catch (CosNaming::NamingContext::AlreadyBound &exc)
{
cout << "AlreadyBound exception." << endl;
return(-1);
}
catch (CosNaming::NamingContext::NotEmpty &exc)
{
cout << "NotEmpty exception." << endl;
return(-1);
}
catch (...)
{
cerr << "Cannot find EventChannel !" << endl;
cout << "Cannot find EventChannel !" << endl;
return(-1);
}
#else
obj = nc->resolve(name);
wcout<<"here is "<
The problem is that you have not guarded by try/catch block all possible
remote calls done by your code snipped above. Please note that _narrow
also causes remote invocation.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
---
Need experienced, fast, reliable technical MICO support?
---> http://www.objectsecurity.com/mico_commsup_referral.html <---
---___
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Patch for iop.cc active_ref() assert side-effects
Hello, thanks for your patch! I've checked it and merged into development source tree. Cheers, Karel On Wed, 16 Aug 2006, Arne Pajunen wrote: Hello, I noticed that iop.cc has a few asserts that cause the side effect of activerefs refcounting to behave differently between release and debug versions, since mico defines assert as #define assert(exp) when NDEBUG is defined. I have no guarantees that the refcounting is correct after this, it would almost have to be wrong in either debug or release version since their behaviour differed. Attached is a patch that changes the asserts to first store the value in a var and then assert that. The patch is -p1 in mico directory (against 2.3.12, issue is there in latest too). It seems somebody has been trying to debug the refcounting mechanisms at some point, so maybe this will help some. I also noted that this issue was reported on the mailing list in 2004, but not included in the codebase for some reason. Original report here: http://www.mico.org/pipermail/mico-devel/2004-June/008765.html regards, Arne Pajunen -- Arne Pajunen Software Engineer OpenTTCN Oy, Test and Test Control Components for Test System Vendors Web: http://www.openttcn.com Email: [EMAIL PROTECTED] -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
Re: [mico-devel] Crash while assigning ObjectID's
On Wed, 16 Aug 2006, [EMAIL PROTECTED] wrote: Hi, I have some problems with a some code generating crashes on Windows but not on Linux. Hi, please send the backtrace of your observed crash, since otherwise we might just guess what has been going wrong. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com --- Need experienced, fast, reliable technical MICO support? ---> http://www.objectsecurity.com/mico_commsup_referral.html <--- --- ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
