Null Pointer while using HttpURLConnection

I think the problem is with the SSL handshake that is supposed to happen. Since you are sending an HTTP request and sending it to an SSL site; the internal processing might be broken. As you see the exception is thrown in the close() method; indicating that Java is already closing the connection when it gets the exception.

Can you try with the HTTP non-SSL URL (http://wwwcie.ups.com/ups.app/xml/ShipConfirm) instead of SSL site in your program and then  check?

Thanks for comment,
The URL we are using is - https://wwwcie.ups.com/ups.app/xml/ShipConfirm

Further during our research we also used security providers and SSLSocketFactory to perform connection. With this implementation we are atlest able to connect to URL and able to send data. But when we try to get response from URL (socket as used here in code attached) we are getting "Socket is closed" exception.

Also we checked socket status, we are getting ""socket.isConnected()" TRUE but on next line where we checked "socket.isClosed()" and are getting TRUE.

the code section of exceptin is
                  System.out.println("Socket status.. " + socket.isConnected());
                  BufferedReader in = null;
                  if(!socket.isClosed()) {
                        in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
                  } else {
                        System.out.println("Socket is closed..");
                  }

System.out.println("Creating Connection..");
			String urlString = "https://wwwcie.ups.com/ups.app/xml/ShipConfirm";
			URL url = new URL(urlString);
			
			System.out.println("Adding provider ..");
			Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

			SSLSocketFactory factory = (SSLSocketFactory)SSLSocketFactory.getDefault();
			SSLSocket socket = (SSLSocket)factory.createSocket(url.getHost(), 443);

			//java.net.URL url = new java.net.URL("https://wwwcie.ups.com/ups.app/xml/ShipConfirm");

			/*HttpURLConnection connection = (HttpURLConnection) url.openConnection();
			connection.setDoOutput(true);
			connection.setAllowUserInteraction(true);
			System.out.println("Client established connection with " + url.toString());
			//out.println("https Connection :- " + connection);

			String accessxml = stringbuffer.toString();
			out.println(accessxml);
			OutputStreamWriter out1 = new OutputStreamWriter(connection.getOutputStream());

		    System.out.println(" OutputStreamWriter out1 : " + out1);

			out1.write(accessxml);
			out1.close();

			System.out.println(" Data sent to the UPS. ");
			BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream()));
			
			String responseString="";
			String UPSResponse = "";

			while ((responseString = in.readLine()) != null) 
			{
				UPSResponse += responseString;
			}
			
			System.out.println("Response From UPS Server : " + UPSResponse);
			System.out.println("");*/

			System.out.println("Sending XML ..");
			String accessxml = stringbuffer.toString();
			PrintWriter out1 = new PrintWriter(new OutputStreamWriter(socket.getOutputStream()));
			out1.println("GET " + urlString + " HTTP/1.1");
			out1.println(accessxml);
			out1.println();
			out1.flush();

			System.out.println("Reading response ..");
			System.out.println("Reading response ..1");
			System.out.println("Socket status.. " + socket.isConnected());
			BufferedReader in = null;
			if(!socket.isClosed()) {
				in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
			} else {
				System.out.println("Socket is closed..");
			}
			

			String line;
			System.out.println("Reading data ..");
			while ((line = in.readLine()) != null) {
			  System.out.println(line);
			}

			out1.close();
			in.close();

			
		}catch (Exception e) {
			System.out.println("Error sending data to server");
			e.printStackTrace();
			System.out.println("Exception is : " + e);
		}

Select allOpen in new window

Hmm..interestiing..when I used the same code you provided I am able to get back data from the SSL connection.

Can you just try this example class and let me know if it fails? If it does, it might be some network issue that you are encountering.
SSLSocketTest.java

Thanks anilallewar,

The basic task we are trying to achieve is,
We have one HTTPS URL to which we have to send a request XML string and get XML as response in turn. We are able to achieve this using standalone classes, but if we use same code under WebLogic then we are facing exceptions.

Currently, we are facing connection issue (while getting OutputStream) only when we deploy the code on WebLogic. In fact the code works perfect and gives proper result if executed stand alone or deployed on Pramati server. It seems to be WebLogic 7 configuration issue here.

We even tried different different approaches to get code working on WebLogic but no success. The latest option what we tried is,
1. we downloaded ssl certificate for the link,
2. configured it on the same JDK 1.4.0_03 on which WebLogic runs,
3. modified code to load certificate dynamically (we used "SSLContext sslContext = SSLContext.getInstance("SSL");" to load the context.

This context loading executed successfully if we run code as standalone class, using main method. But if we create JSP for this code and run under WebLogic7 then it generates below exception,

java.security.NoSuchAlgorithmException: Algorithm SSL not available
        at javax.net.ssl.SunJSSE_b.a(DashoA6275)
        at javax.net.ssl.SSLContext.getInstance(DashoA6275)
        at jsp_servlet.__httpstestnew._jspService(__httpstestnew.java:261)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:445)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
        at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)

We are really stucked at this level since 4 days and desperately looking for solution.
httpsTestNewJSP.txt

What JRE is your weblogic using; my assumption is Weblogic uses its own JRE that doesn't like the SSL stuff you are using.

To change defualt JDK for a WebLogic domain

Find and open the startWeblogic.sh (or startWeblogic.cmd in windows) file that is in the root of the
domain:

Change the value of the variable: JAVA_HOME to your JDK path.

Generaly WebLogic 7 is shipped with jdk1.3, but in actyality, we are using JDK 1.4 with WebLogic7 as this is the configuration of our production.

We are able to resolve all the issue and receive desired reply but using JDK1.3 with WebLogic7, when we use JDK1.4 with WebLogic7 we are facing "java.io.IOException: Write Channel Closed, possible SSL handshaking or trust failure" exception.

To get is working we tried following steps bu still no success,
1. got the certificate for HTTPS URL we are trying to hit.
2. configured the the certificate to WebLogic "cacert" under path "bea\weblogic700\server\lib"

After implementing these steps, we are able to perform URL communication successfully using WebLogic with JDK1.3, but when we tried using WebLogic with JDK1.4 we faced following exception.

java.io.IOException: Write Channel Closed, possible SSL handshaking or trust fai
lure
        at com.certicom.tls.record.WriteHandler.write(Unknown Source)
        at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertSent(Unknow
n Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMes
sage(Unknown Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMes
sages(Unknown Source)
        at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
        at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
        at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknow
n Source)
        at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Un
known Source)
        at com.certicom.tls.record.WriteHandler.write(Unknown Source)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69
)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
        at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
        at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.j
ava:97)
        at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.
java:284)
        at jsp_servlet.__httpstested._jspService(__httpstested.java:231)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run
(ServletStubImpl.java:1058)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:401)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:445)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:306)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:5445)
        at weblogic.security.service.SecurityServiceManager.runAs(SecurityServic
eManager.java:780)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
rvletContext.java:3105)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
pl.java:2588)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
Exception is : java.io.IOException: Write Channel Closed, possible SSL handshaki
ng or trust failure
Error sending data to server
java.io.IOException: Write Channel Closed, possible SSL handshaking or trust fai
lure
        at com.certicom.tls.record.WriteHandler.write(Unknown Source)
        at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertSent(Unknow
n Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMes
sage(Unknown Source)
        at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMes
sages(Unknown Source)
        at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
        at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
        at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknow
n Source)
        at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Un
known Source)
        at com.certicom.tls.record.WriteHandler.write(Unknown Source)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69
)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
        at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
        at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.j
ava:97)
        at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.
java:284)
        at jsp_servlet.__httpstested._jspService(__httpstested.java:231)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run
(ServletStubImpl.java:1058)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:401)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:306)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:5445)
        at weblogic.security.service.SecurityServiceManager.runAs(SecurityServic
eManager.java:780)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSe
rvletContext.java:3105)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestIm
pl.java:2588)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
Exception is : java.io.IOException: Write Channel Closed, possible SSL handshaki
ng or trust failure

The SSL library that weblogic uses(com.certicom.) will NOT be compatible with 1.4 and that is what is causing the issue. This is not a problem with the cert.

Weren't you previously using JDK 1.4 classes to make SSL connection? If you were getting the same exception then probably there is NO way to tell weblogic to use the standard library; you would have to either go with JDK 1.3 or use a newer version of weblogic.

No, we havent used JDK1.4 with WebLogic7 earlier for SSL connection. We have migrated WebLogic7 from JDK1.3 environment to JDK1.4 as a part of earlier requirement of security API integration.

And now we have another requirement where we have to use same combination of WebLogic7 and JDK1.4 to only (as they are on production also), we cannot escape this combination now. Also coming back to JDK1.3 is not possivle, and upgradation of WebLogic is also not feasible as it will require upgradation of whole UAT, Staging and Production environments.

Aren't there any feasible way out to workaround this, like to use Sun JSSE or any other configurations at JDK1.4 or WebLogic7 level?

Like I told you earlier(Comment #28679675), the standard Sun JSSE and Weblogic implementation  were getting mixed up leading to all the weird errors. Since you removed the Sun JSSE libraries, only weblogic libraries were used and you were able to connect correctly.

You could have done the same by removing Weblogic libraries but we are wary of the side-effects.

I generally have this grudge against most App server vendors as to why they provide their own implementation of some Java specification when a standard version is availble :(