cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Schroedl (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-1459) ClassCastException occurs on HTTPS web service call made by app deployed to BEA WebLogic 9.2
Date Sat, 08 Nov 2008 02:28:44 GMT

    [ https://issues.apache.org/jira/browse/CXF-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645945#action_12645945
] 

Tom Schroedl commented on CXF-1459:
-----------------------------------

I haven't encountered any other issues. However, on my next project, the same issue came up.
This time it was in a Java 6 application. The app was using CXF for making web service connections
to external services that required client PKI authentication, and the app was also using Tibco
Java client libraries for JMS over SSL. I discovered the root of the problem was the Tibco
libs were setting the following Java system property:

java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol

This was ultimately causing my CXF web service client to throw a class cast exception when
it attempted 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.

I was not able to get past the Tibco library setting this property no matter what I did, so
I decided to modify the CXF source, which worked. The workaround involved checking the type
of the https url connection. It only handles the com.sun.net.ssl case, but could easily be
enhanced to check for and handle the WebLogic (weblogic.net.http) case.

Sorry if this was a lot, hopefully will be of help to someone.

> ClassCastException occurs on HTTPS web service call made by app deployed to BEA WebLogic
9.2
> --------------------------------------------------------------------------------------------
>
>                 Key: CXF-1459
>                 URL: https://issues.apache.org/jira/browse/CXF-1459
>             Project: CXF
>          Issue Type: Improvement
>    Affects Versions: 2.0.4
>            Reporter: Tom Schroedl
>
> HTTPS web service call fails from webapp deployed in ear file to BEA 9.2 with following
error:
> java.lang.ClassCastException: weblogic.net.http.SOAPHttpsURLConnection
>    at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:120)
> My weblogic-application.xml contains:
> <prefer-application-packages>
>    <package-name>javax.jws.*</package-name>
> </prefer-application-packages>
> The secure web service call works in Tomcat 5.5.

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


Mime
View raw message