Develop Reference

WSDL URL is accessible from browser but not from java program

I have a web service running on a remote server and I wrote a client program to consume its services. The client program uses client stubs that were generated from a .wsdl file using the wsimport command. I am accessing the server via a proxy and in my program I tell the JVM to communicate via the proxy by setting the system properties "proxySet", "proxyPort" and "proxyHost", to true, and the corresponding port and address of the proxy respectively; which works fine. In addition, I'm also connecting via SSL, and the server certificate is signed by some other CAs, and in my case I needed to import the certificate to the trustore cacerts; which also works well. However I am not able to access the web service with the URL I specify in my program, though it can be accessed with a browser. below is the stack trace of my program:
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.
java.io.IOException: Server returned HTTP response code: 500 for URL: https://webservicesimp.companyName.com/ReportingService
java.io.FileNotFoundException: https://webservicesimp.companyName.com/ReportingService?wsdl
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)
at javax.xml.ws.Service.<init>(Unknown Source)
at com.conpanyName.xml.companyName.enterprise.report.v1.enterprisereportingservice_1.ReportingService.<init>(ReportingService.java:50)
at WebServices.<init>(WebServices.java:33)
at ERSWebServiceRunner.main(ERSWebServiceRunner.java:37)
Any help is appreciated... Thanks

"Connection reset" when using SOAP

I have a REST service and some clients get a "Connection reset" error. But SOAP is stateless, so why doesn't it just simply reconnect and resend the request? It actually sends multiple messages in my use case, but the very first fails, and that is just to get some config data from the server. Is this something I need to configure? Should the client programmatically try to resend the message? Some users tried multiple times with the same result.
It never happened in the last years but now I get some reports of this problem.
The client uses in implementation of javax.xml.ws.Service, not just a raw socket. But even though I use JAX I get the low level error. It is wrapped by a WebServiceException, but that doesn't really help me fixing this problem.
The clients all use Java 8. It's either Update 66 or Update 74.
I am not able to reproduce the problem myself, I only have log files from users.
Here's the complete stack trace:
javax.xml.ws.WebServiceException: java.net.SocketException: Connection reset
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
at com.sun.proxy.$Proxy31.getLimits(Unknown Source)
at xxxxxxxxxxxxx.SOAPServerAdapter.connect(Unknown Source)
at xxxxxxxxxxxxxxxxxxxx(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
... 18 more

It turned out it was about IPv4 and IPv6. I don't have enough knowledge to give a perfect answer but I can post here what they told me. Maybe this helps other devs/users who have the same problem.
So some clients have unexpected connection resets and it's not about server load as it usually is.
If the ISP of the client tries to get away from IPv4 they will give each user a unique IPv6 address (note that the ISP might do this gradually). They do not really have an IPv4 address per client any more, other than the IPv4 used locally, since most still use something like 192.168.0.0/24 for their LAN.
Instead of classic IPv4 they use some transaction mechanism (e.g. Dual-Stack Lite). Those clients to not have direct access to the IPv4 internet. So if your server only supports IPv4 then they might experience similar problems you get when they use a proxy. They encapsulate IPv4 packets within IPv6 packets for some parts of the communication. From Wikipedia: "The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet."
I don't really know what's going wrong here. Maybe the NAT runs out of addresses / ports or something like that. Or the process takes too long you the connection is reset by some node that is involved in the communication.
So there are two things to do:
Inform the ISP about those problems. They probably will help you trace the exact problem and help their clients so they can use your service. For that you need to know the ISP of the users that have the "connection reset" problem. Send them to https://www.whoismyisp.org/ or similar site.
Upgrade to IPv6 as soon as possible. Your server can use both versions of the protocol at the same time.

Check the load on your server. Looks like server is closing connections because of load - exception on web-service call

Unable to call Web Services after upgrading JRE to 8u65

I have a web service hosted on IIS on windows machine. Everything went fine until I upgraded Java to JRE 8u65.
Now it is throwing the below exception on invoking the web service.
Exception in thread "main" java.net.SocketException: Unexpected end of
file from server at
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at
sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown
Source) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown
Source)
Note : Previously I was using JRE 8u60. Any help in this regard is really helpful.
Thanks in advance!

The stacktrace you have shown us comes from a Java client for your web service. What is saying is that the server has closed the network connection before sending an HTTP response.
There is no evidence in this stacktrace to say why the web service did that. The evidence is probably in the service logs.

applet with swing mysql and a config file works in eclipse but fails in browser

Hi it's probably because i'm a noob, but i'm trying to get this working for days now so hope that someone can help me....
The idea:
For a java training i need to make a Java applet that reads and writes data from a (localhost) MySQL database. The settings from this database have to come out of a config.ini file.
The application runs fine as an applet and a java application in Eclipse.
It also runs fine as an executable jar file.
I can't get it running as an applet though...:(.
The first error that i got was about reading the config.ini file. I expect that this happens because of the security limitations (io). It is something that needs to be solved but not my main concern for now.
In order to see if the rest works i skip my loadIni class. Then i got a: driver not found exception.
I solved this by loading the mySQL jar as an archive in my applet ().
But now i'm lost...
When i start the applet in the browser i get the following error in the console:
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.instantiateApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:327)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at Kreta.DBConnection.<init>(DBConnection.java:39)
at Kreta.AfhaalMenus.<init>(AfhaalMenus.java:21)
at Kreta.test2.<init>(test2.java:39)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter$1.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission"
"file.encoding" "read")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at com.mysql.jdbc.StringUtils.<clinit>(StringUtils.java:70)
... 31 more
I really hope that somebody can send me in the right direction.

Applets are not allowed to do a number of things, including file I/O and various networking tasks; as your applet is trying to do one. You may need to sign you applet.
Check this reference
http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem

The answer is signing all jars.
how to do this was still a quest but the following post made it really easy:
how do i sign a java applet

An applet should not have direct access to the DB. This is for the security of the DB. Instead it should be forced to go through a web service that (limits what the user can do &) itself interacts with the DB.
An applet communicating with a DB (or a web service) on the same host that served it can be sand-boxed.
If that 'reading properties' error is part of the DB connection code you do not control, that is a good case for hiding the DB access behind the web service. Otherwise there are ways of reading a properties file (from the originating server) that do not invoke an AccessControlException.
Having said all that, it is getting to the stage where unsigned code is likely to be blocked before it is ever loaded, so perhaps the first thing you should do is digitally sign the applet and all required libraries.
Why code an applet? If it is due to spec. by teacher, please refer them to Why CS teachers should stop teaching Java applets. This will be easier to do with a standard desktop app. launched using Java Web Start. The security environment will be the same, but a free-floating app. is:
A better experience for the end user.
A lot easier to code and maintain than an applet embedded in a web page.

Testing JCTerm, java applet terminal emulator, works in Eclipse, but not in browsers

Testing an unmodified version of JCTerm (terminal emulator, can be used as an applet; I would like to use the applet functionality), everything seems to be working fine in Eclipse's AppletViewer, but testing the resulting jar file in an web page, all options display a message box with a flashing yellow warning symbol and do nothing. Some options display a "Establish the connection before this setting" error.
The option I'm interested in using is 'Open SHELL Session...' from the File menu. When trying 'Open SHELL Session...' option, the Java Console for the applet displays this stuff, which seems directly related. I don't have a clue as to what it means though.
network: Connecting http://xxx.xx.xx.xxx/crossdomain.xml with proxy=DIRECT
network: Connecting http://xxx.xx.xx.xxx:80/ with proxy=DIRECT
java.security.PrivilegedActionException: java.net.ConnectException: Connection refused: connect
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source)
at sun.plugin2.applet.Applet2SecurityManager.checkConnect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at com.jcraft.jsch.Util$1.run(Util.java:354)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at com.sun.deploy.net.CrossDomainXML$2.run(Unknown Source)
... 10 more
An example of this program working correctly can be found here, http://wiredx.net/jcterm/

I'm the author of jcterm.
The jar files at http://wiredx.net/jcterm/ have been digitally signed.
So, if you copy and intstall those files into your web server, it will work.

This looks like a security problem.
By default, an unsigned Java applet can only connect to the host if was loaded from. Additionally, if the host you want to connect to allows this with it's crossdomain.xml file, you can also connect to other hosts.
Judging from the stack trace, you want to connect to a host which does not have an HTTP server, and thus can't provide a crossdomain.xml file. For this reason, you get this exception here.
There are these ways out of this:
Put the applet on the same web server which you want to connect to with SSH later. (Every applet can connect to its own host.)
Let the SSH server have a minimal web server with a crossdomain.xml. (The crossdomain.xml must allow content from the applet's server to access this server.)
Sign the applet (and let the user trust it). (Signed and trusted applets are allowed to do everything.)
The official WiredX sample applet you linked uses the last method, this is why it works even when connecting to your server.