This content has been marked as final. Show 36 replies
You don't need to do all that, just set the three system properties for the keystore, KS password, and truststore, and maybe the enabled protocols if you care that much. It should all then happen automatically. I'm curious to see what this HttpClient package actually does with HTTPS URLs. It clearly has a handler registered for the HTTPS protocol so it should do the right thing, i.e. create an SSL socket. But the fact that it doesn't return a javax.net.ssl.HttpsURLConnection is a worry. It might be ancient code that extends com.sun.net.ssl.internal.HttpsURLConnection or whatever it was 10 years ago - might be worth looking into that. Whatever it does it needs updating badly.
It went through without casting as well, Thanks !
I was checking the following steps and an other issue came up here.
The XML Stream of input data to the HTTPS system is being sent via XMLSerializer's asDOMSerializer().serialize(document)
If property java.protocol.handler.pkgs is not cleared, this is getting just stuck and when the System.clearProperty is used before
the above serialize method, it is proceeding without any issue. Not sure whether this XMLSerializer has something to do with this property further.
Trying to check for this now.
Also it seems the myhttpurlconn.getInputStream() is also getting stuck it seems and ends up with 'Connection Timeout' when this property
java.protocol.handler.pkgs is not cleared, when this property cleared before activating the I/O streams, it is working fine.
So, the issue is again the same that if any JServ calls resets this property on fly when our app is trying, app may fail then.
Edited by: 817816 on May 26, 2011 5:28 AM
Okie, this seems actually failing at the initial steps, getting the SSL context and initializing the URL.
as a whole, the conclusion of trails is that unless this System property is cleared, the connectivity does not work, thus there is no assurance that it works always. Better it seems to have jar behavior to be posted to the vendor (JServ creators).
I think we have the root cause identified, Thanks for all your valuable help EJP !!!
Please post it here for the benefit of future readers.
Sure EJP, it is same that we already found.
Issue is that the HTTPS Solution based on (standard JSSE package javax.net.ssl) doesn't properly work on Oracle iAS JServ web server. Often throws the HttpURLConnection initialization issue.
Root cause is that the JServ (for its portal apps) declares its JVM property java.protocol.handler.pkgs with the value HTTPClient (using its property files).This is provided by http_client.jar that is added in its classpath.The standard JSSE needs this system property to be null to have the SSL Channel established (via HTTPS) and this wouldn't happen since this system property is being reset to HTTPClient by JServ repeatedly.
Temperory fix I noticed is to comment this http_client.jar from the JServ properties file to stop loading this jar file, assuming JServ should be fine as http providers will still be satisfied by standard java packages. Since then, we found no issues with the server behavior and the HTTPS application also works well. Also this system property java.protocol.handler.pkgs being set to null in the HTTPS servlet as usual.
It goes deeper than that. The fundamental reason here is that this HttpClient package claims to support HTTPS, by virtue of having a sub-package HttpClient.https, and doesn't.