972 2013-12-10 11:24:21 +0000 Method _repository_id() not found when invoked from C++ (TAO) 2014-01-03 16:06:43 +0000 1 1 1 Unclassified JacORB ORB 3.3 PC Linux RESOLVED FIXED P5 critical --- 1 joseph.h.schwarz jacorb-bugs jacorb oldest_to_newest 3090 0 joseph.h.schwarz 2013-12-10 11:24:21 +0000 The org.omg.Object._repository_id() method, when invoked by a Java client on a Java object in another JVM (on a single PC) works correctly. However, when invoked from from a C++ process via TAO, it fails with: 2013-12-09T15:45:29.009 WARNING [jacorb@monColTestCont] rid: 11 opname: _repository_id starts with request processing 2013-12-09T15:45:29.009 WARNING [jacorb@monColTestCont] rid: 11 opname: _repository_id invokeOperation on servant (stream based) 2013-12-09T15:45:29.010 INFO [jacorb@monColTestCont] rid: 11 opname: _repository_id invocation: system exception was thrown. org.omg.CORBA.BAD_OPERATION: _repository_id not found at alma.ACS.ROdoublePOA._invoke(<MyImpl>) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:362) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:684) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:846) From the implementation provided by the Jacorb Delegate class (where the method is called "repository_id()," it appears that only a local invocation is foreseen. (We see the same implementation in Jacorb 3.4-beta.) Since our system makes liberal use of interacting C++, Java and Python objects, interoperability of this kind is essential for us. We have been using Jacorb 2.2.4 with TAO successfully for many years, but we needed the functionality of the newer org.omg APIs (already in TAO and now in Jacorb 3.x as well) in order to be able to take advantage of functionality such as _repository_id(); the above problem is a major hitch in our upgrade. 3101 1 jacorb 2014-01-03 16:06:43 +0000 Fixed in SHA 1916cf70fa9e5377110ededa13c262b7d7586279