Skip to main content

java.protocol.handler.pkgs Strikes Back

Posted by garysweaver on August 6, 2008 at 1:17 PM PDT

In last last couple of months working with a custom portlet that uses Apache CXF (2.1.1) in uPortal, I was getting a wierd issue:

javax.xml.ws.soap.SOAPFaultException: com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl
...
Caused by: java.lang.ClassCastException: com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl
        at org.apache.cxf.transport.https.HttpsURLConnectionFactory.createConnection(HttpsURLConnectionFactory.java:129)
        at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:480)
        at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
        at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
        at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
        ... 36 more

This occurred with Apache CXF v2.1.1 where it was doing:

        HttpsURLConnection connection =
            (HttpsURLConnection) (proxy != null
                                   ? url.openConnection(proxy)
                                   : url.openConnection());

It turns out that in uPortal, there is a configuration file "uPortal/WEB-INF/classes/properties/portal.properties" that contained the following:

  # Protocol handler for https connections.  Set by default to the one provided with
  # Sun's JSSE - change to use your local JSSE implementation
  #
  org.jasig.portal.utils.ResourceLoader.HttpsHandler=com.sun.net.ssl.internal.www.protocol

This in turn is used by the following code in a static block in org.jasig.portal.utils.ResourceLoader:

  static {
    f = DocumentBuilderFactory.newInstance();
    f.setNamespaceAware(true);
    try{
      String handler = PropertiesManager.getProperty("org.jasig.portal.utils.ResourceLoader.HttpsHandler");
      if ((System.getProperty("java.protocol.handler.pkgs") != null) &&
        !(System.getProperty("java.protocol.handler.pkgs").equals(""))){
        handler = handler+"|"+System.getProperty("java.protocol.handler.pkgs");
      }
      System.setProperty("java.protocol.handler.pkgs",handler);
    }
    catch(Exception e){
      log.error("Unable to set HTTPS Protocol handler", e);
    }
  }

As you can see it puts what I think is the old wrong package (at least for Java 1.4+) "com.sun.net.ssl.internal.www.protocol" at the first of the list of handlers. Doing this is not only unnecessary but can cause problems in Java 1.4+ from what I've read and have now experienced.

While you can try removing the System property "java.protocol.handler.pkgs" in your code, that is a bad idea for obvious reasons (you're affecting the whole JVM, you don't know when that property will be read necessarily, etc.) and it isn't guaranteed to work. The best thing to do is to find the offending code or config and axe it so that it doesn't set old sun protocol handlers in newer code.

So in short, the right way to fix this was to change uPortal/WEB-INF/classes/properties/portal.properties to have:

org.jasig.portal.utils.ResourceLoader.HttpsHandler=

and then restart.

Unfortunately it looks like this property is being set also in the latest uPortal distribution (v3.1) also. If uPortal v3 (and latest version of v2 for that matter) aren't meant to support Java versions under v1.3, should the default properties list the property value of this as (blank) by default? I emailed the uPortal guys, so I guess we'll find out.

Related Topics >>