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