Just found another hurdle around as I suspected with System.setProperty.
Some other app on same server are in need of HTTPClient package, so that servlet code is re-establishing java.protocol.handler.pkgs property.
Is there anyway that we can make this declaration to the scope of my servlet itself ?
Or, inside the code, is there any specific location like before getting SSLContext.getInstance("SSL") if we do this, that will be helpful to us ?
Or is there anyway we can set it at the higher level (servlet container) to restrict other resets?
has thrown some light on servlets using System.setProperty. I guess I may have to figure out a way where all get on same page.
Is there anyway to set this property instead to effect only my servlet scope!
HTTPClient class is from the JServ library product/iAS/lib/http_client.jar.
This is a part of standard oracle JServ library and across all default oracle portal applications, this has been set in their properties files,
so we may not expect to reset this and even we do this, there is no assurance that app will run all times.
This is because when the portal is accessed, the property java.protocol.handler.pkgs will be reset and our logic will fail.
How to resolve this !
yes, the code approach is as given initially in the post, and the whole problem there onwards...HTTPSURLConnection is expected and HTTPClient is the result.
If the JServ portal is not involved and this servlet is tested, it works well until the property is being overwritten by JServ portal configurations.
Looking for help for any alternative approaches.
The exception is java.lang.ClassCastException and this is because we are expecting to cast the return of HTTPClient.HttpURLConnection
into javax.net.HttpsURLConnection. Via this HttpsURLConnection object, we get the DataOutputStream with (getOutputStream() method)
to post the data and use the getInputStream() to have the DataInputStream to read the response.
I am just trying to dig around to find out any other way all around (a different approach) to have get this done.
You're missing the point. You don't need that cast unless you are calling a method of javax.net.ssl.HttpsURLConnection that isn't in java.net.HttpURLConnection, or for that matter UTLConnection. What happens if you cast it to URLConnection?
Background work before obtaining the input and output streams to get and post the data to this HTTPS connection are to.
initialize the SSLContext (SSLContext.getInstance("SSL")) and call init method with keystore and truststores created using KeyManagerFactory and X509TrustManager. then, we set the default socket factory for HttpsURLConnection (using method setDefaultSSLSocketFactory) and also the default hostname verified (using method setDefaultHostnameVerifier).
This initializes proper default environment for HTTPS connectivity and from there later, code posts the data and reads back the response.
I will try to check whether this write & read still works without casting (rest of ground work remains as is) i.e. via httpconnection object and let you know soon.