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.