[ 
https://issues.apache.org/jira/browse/CXF-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-2048:
-------------------------------------

    Assignee: Sean O'Callaghan

> ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL 
> Java client library is on classpath
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: CXF-2048
>                 URL: https://issues.apache.org/jira/browse/CXF-2048
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.0.10
>         Environment: JDK 6 with Tibco EMS 4 SSL library on classpath
>            Reporter: Ron Gavlin
>            Assignee: Sean O'Callaghan
>            Priority: Critical
>         Attachments: cxf-2048.patch
>
>
> My app is using CXF to make web service connections to external services that 
> require client PKI authentication. The app also uses Tibco Java client 
> libraries for JMS over SSL. The Tibco libs set the following Java system 
> property:
> java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
> This causes my CXF web service client to throw a class cast exception when it 
> attempts to make a secure connection. Let me explain why this occurs..
> The java.protocol.handler.pkgs system property is a list of package name 
> prefixes used by Java to resolve protocol names into actual handler class 
> names. As of v1.4, JSSE has been integrated into the J2SDK. Thus, the classes 
> formerly in com.sun.net.ssl have been promoted to the javax.net.ssl package 
> and are now a part of the standard JSSE API.
> For compatibility purposes the com.sun.net.ssl classes and interfaces still 
> exist, but have been deprecated. Applications written using them can run in 
> the J2SDK v1.4 and later without being recompiled. **Thus, setting the system 
> property causes Java to use the deprecated implementation.**
> The problem with CXF comes in because it assumes the newer handler package 
> structure when it attempts to decorate the underlying connection with your 
> TLSClientParameters.
> A workaround should be implemented to support common, divergent subtype https 
> implementations including com.sun.net.ssl.HttpsURLConnection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to