Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 1033 - The duplicate ORB related classe for Jacorb 3.7 and IBM thinclient-8.5.5.7, whcih casue the our EJB accessing failed.
Summary: The duplicate ORB related classe for Jacorb 3.7 and IBM thinclient-8.5.5.7, w...
Status: NEW
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 3.7
Hardware: HP Linux
: P5 critical
Assignee: Mailinglist to track bugs
URL:
Depends on:
Blocks:
 
Reported: 2016-06-16 22:25 UTC by weifeng.f.huangfu
Modified: 2016-07-05 02:03 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description weifeng.f.huangfu 2016-06-16 22:25:05 UTC 
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 UTC 
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 UTC 
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 UTC 
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.