unknown host: http=127.0.0.1

Well my daily battle with webservices continues unabated. I can see why people would leave IT for a less stressful job, like a human crash test dummy. Today I've been battling with a wonderful error message Uncompilable source code - Erroneous sym type, but more on that later.

Deciding that the only course of action was to remove the web service definition itself and recreate it, I did. Except that I didn't, or rather NetBeans didn't. All I got was this curious error message unknown host: http=127.0.0.1 and nothing got created. So let me get this right. My computer doesn't know where itself is? Hmmm, something not right there. Quick search of the Internet brings up only 6 results, when was the last time you had that? First result is HP Laserjet and Cups, which I am sure was interesting to someone but wasn't helping me. Next one looked more promising. Straight from the Netbeans website a ... ah ... an abandoned question, really helpful. Last one was Ruby on Rails, again not so useful.

Finally I figured out that Fiddler was causing the issue. It was interrupting the request to the web service for the WSDL file and nothing was getting returned except the especially helpful error message. Shutdown Fiddler and instant webservice! So sometimes those really useful programs can be a little less than useful!

Name xxx is not bound in this context - Part II

In the first part of this blog I covered the cause of this error message. But what if you want to use different web services in development and in production? It's not that difficult but Java does manage to hide it quite well. A little digging on Google and a lot of testing and re-testing and I did manage to get it to work.

One of the constructors used when creating a new web service declaration accepts two parameters; a URL and a QName. By passing the URL and Endpoint that we would like to use, we can redirect our web service call away from the original service URL located in the WSDL file and towards the new end point. So your code ends up looking like this:

private WSTixs service;

    

URL serviceEndPoint = new URL("http://mywebservice.com");

QName serviceQName = new QName("http://tempuri.org", "EndPoint");

webservices.EndPoint service = new webservices.EndPoint(serviceEndPoint, serviceQName);

Now in another of those traps for young players, and you will spend a lot of time on Google trying to solve this one. You MUST remove the @WebServiceRef if you have one. Otherwise your Servlet is going to come crashing down again with the 'Name xxx is not bound in this context' and no amount of debugging code is going to save you. Either comment the line out, or delete it altogether.

Hopefully someone is going to save some time with this because I spent a lot of it trying to solve it!

LCD

Name xxx is not bound in this context

So you've just finished developing your Java app, and it all runs fine on your development machine. The client is itching to get their hands on it so you deploy to their Tomcat server. Everything is fine right? Err NO! The app comes crashing down in a heap with a log file to rival War and Peace! Big oops moment and the client is starting to page through the classifieds looking for a developer who actually knows what they are doing. It's not a comfortable moment in your otherwise shining career.

No problems you decide, I'll just install Glassfish and everything will be fine, that's the app server I'm using so how can it possibly not work. A bit of slight of hand and Glassfish is up and running, your WAR file is deployed and away we go ... or perhaps not. Same error, same servlet, same bemused look on the clients face.

Apologies ensue, virtual machines deployed with a full development environment, router reconfigured to own development machine, lots of red faces (yours) and more bemused looks. So what(TF) went wrong you ask?

Well the answer is actually simple, at least it was in my case. The issue that I had was all because I had used a local WSDL file to define my web service. Netbeans kindly compiles the physical path to the file into the application, but when the app was deployed the path was completely different. When I changed the reference to run from a URL the app started working ... just like magic.

So here's a trap for young (and not so young) players. Regardless of how attractive the option is, don't use the physical WSDL file in your app. Always point it to the URL :-)

LCD