|Summary:||The duplicate ORB related classe for Jacorb 3.7 and IBM thinclient-220.127.116.11, whcih casue the our EJB accessing failed.|
|Component:||ORB||Assignee:||Mailinglist to track bugs <jacorb-bugs>|
Description weifeng.f.huangfu 2016-06-16 22:25:05 CEST
Hi Exptet, Recently, we upgrade jacorb to 3.7 from 3.1, some issue we met. The prevouis EJB accessing failed with error: "Exception=com.ibm.websphere.ssl.SSLException: CWPKI0315E: SSL configuration properties are null." We supposed jacorb overwrite some system configuration of EJB SSL accssing which IBM lib needs, but it is difficult for us to identfy it. We tried to make ibm releated libs loadling first, everything is fine, but if jacorb libs are loading firstly, this issue happens, this issue doesn't exist in jacorb 3.1 which we have used for long time. Please give us some suggestion how to avoid this issue. Thanks a lot.
Comment 1 weifeng.f.huangfu 2016-06-21 00:44:07 CEST
The exception: Caused by: org.omg.CORBA.COMM_FAILURE: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET Exception=com.ibm.websphere.ssl.SSLException: CWPKI0315E: SSL configuration properties are null. Could be a problem parsing the SSL client configuration. vmcid: 0x49421000 minor code: 112 completed: No at com.ibm.ws.security.orbssl.WSSSLClientSocketFactoryImpl.createSSLSocket(WSSSLClientSocketFactoryImpl.java:247) at com.ibm.ws.orbimpl.transport.WSSSLTransportConnection.createSocket(WSSSLTransportConnection.java:236) at com.ibm.CORBA.transport.TransportConnectionBase.connect(TransportConnectionBase.java:344) at com.ibm.ws.orbimpl.transport.WSTransport$1.run(WSTransport.java:503) at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118) at com.ibm.ws.orbimpl.transport.WSTransport.getConnection(WSTransport.java:500) at com.ibm.CORBA.transport.TransportBase.getConnection(TransportBase.java:180) at com.ibm.rmi.iiop.TransportManager.get(TransportManager.java:97) at com.ibm.rmi.iiop.GIOPImpl.getConnection(GIOPImpl.java:134) at com.ibm.rmi.iiop.GIOPImpl.locate(GIOPImpl.java:228) at com.ibm.rmi.corba.ClientDelegate.locate(ClientDelegate.java:1731) at com.ibm.rmi.corba.ClientDelegate._createRequest(ClientDelegate.java:1756) at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1047) at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1129) ... 27 more
Comment 2 Nick Cross 2016-07-05 01:48:25 CEST
Are you able to test different versions of JacORB to narrow down the problem for me? Is there a particular reason (apart from having JacORB's stubs first) that you are putting JacORB first in the classpath? Have you reported the issue to IBM to ask why their libraries need to be first in the classpath?
Comment 3 weifeng.f.huangfu 2016-07-05 02:03:26 CEST
hi, Are you able to test different versions of JacORB to narrow down the problem for me? ----- I am trying to do such testing recently, I will give feedback soon. Is there a particular reason (apart from having JacORB's stubs first) that you are putting JacORB first in the classpath? ----- As I mentioned, we cannot control it loading order for classing loading. it depends ServiceMix. Have you reported the issue to IBM to ask why their libraries need to be first in the classpath? ----- No, I haven't reported it to IBM, because I have no enough information for IBM.