You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Ron Gavlin (JIRA)" <ji...@apache.org> on 2009/02/18 06:23:01 UTC
[jira] Created: (CXF-2048) ClassCastException occurs on HTTPS web
service call made when Tibco EMS SSL Java client library is on classpath
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
Priority: Critical
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2048) ClassCastException occurs on HTTPS web
service call made when Tibco EMS SSL Java client library is on classpath
Posted by "Sean O'Callaghan (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CXF-2048) ClassCastException occurs on HTTPS web
service call made when Tibco EMS SSL Java client library is on classpath
Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ron Gavlin updated CXF-2048:
----------------------------
Description:
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.
was:
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.
> 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
> 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.
[jira] Resolved: (CXF-2048) ClassCastException occurs on HTTPS web
service call made when Tibco EMS SSL Java client library is on classpath
Posted by "Sean O'Callaghan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean O'Callaghan resolved CXF-2048.
-----------------------------------
Resolution: Fixed
Fixed on 2.2, 2.1.x, 2.0.x branches
> 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.
[jira] Updated: (CXF-2048) ClassCastException occurs on HTTPS web
service call made when Tibco EMS SSL Java client library is on classpath
Posted by "Ron Gavlin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ron Gavlin updated CXF-2048:
----------------------------
Attachment: cxf-2048.patch
Patch adds support for deprecated class com.sun.net.ssl.HttpsURLConnection.
> 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
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.