Configure webservice URL for client from properties file with Netbeans 7 and Axis2

Question

I'm new to webservice development. I'm using Netbeans 7.0 with the Axis2 plugin and Tomcat 7.

I created one project for the server components where I define the web methods, and then created another project for the client components. The client was created in Netbeans by selecting New -> Webservice Client.

When you select New -> Webservice Client in Netbeans, it asks you right then for a WSDL URL. So of course I gave it the WSDL URL from my local Tomcat installation. But what about when I distribute this as a real application? The users aren't going to point their clients at http://localhost:8080/axis2/services/?wsdl. I mean, when running the client from the IDE, it all works fine, but when I distribute this (it's a labor management application by the way where you clock in / out at one or more clients and time cards are written to a central DB), each client needs to be able to point at the webservice URL of whatever production server it's supposed to connect to.

I'd like to store the webservice URL in a properties file, but don't really know what all to do programmatically at the client to make the call to the URL that's loaded from the properties file.

In my client's dist folder, if I open the JAR that netbeans created with WinZip, I see a file name jax-ws-catalog.xml that has the URL in it (which is pointed at localhost). I assume this is where the URL that's used at runtime comes from.

So what's the correct way to go about this? I've searched around, but the things I've found looking on google searches tend to show webservice calls being made in a completely different way than the auto-generated code that Netbeans puts together, and I'd like some info specific to how Netbeans creates a webservice client so that I don't end up making changes just to have the IDE overwrite them.

Thanks! Sorry for the long explanation.

-Jim

Civil

Answer 1

This has been answered before: How to change webservice url endpoint?

NetBeans uses plain JAX-WS to generate client code, so the answer above should work for you. You just need to add some code to get the endpoint URL from a properties file.

Pennebaker

So, in my client app when I add a web method (i.e. under Web Service References node, I select the httpSOAP12endpoint and all my web methods are listed; I select one and drag it over to the client source file), I get something like below... private static String testConnection() { simplylaborclient.SimplyLaborServer service = new simplylaborclient.SimplyLaborServer(); simplylaborclient.SimplyLaborServerPortType port = service.getSimplyLaborServerHttpSoap12Endpoint(); return port.testConnection(); } – Civil

Sorry my comment got cut off. So a simple testConnection method looks like this on the client side... private static String testConnection() { simplylaborclient.SimplyLaborServer service = new simplylaborclient.SimplyLaborServer(); simplylaborclient.SimplyLaborServerPortType port = service.getSimplyLaborServerHttpSoap12Endpoint(); return port.testConnection(); } – Civil

And this works fine when running with my local server. So I create a BindingProvider and set it equal to my port object, then do something like this with enpointUrl loaded from a properties file? - bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointURL); Do I then execute bp.testConnection() for example? – Civil

God it sucks you don't get to reply very well with comments; no line breaks, so I can't show example code without answering my own question. I suppose I should have edited my original question instead of using comments. Sorry guys I'm new at this. – Civil

It's OK, I'm new at this too. This is actually my first answer. Your 3rd comment is correct, you need to cast your "port" object to BindingProvider using: BindingProvider bp = (BindingProvider)port;, then change the URL using bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointURL); and replace "endpointURL" with the String you loaded from your properties file. – Pennebaker

Answer 2

I actually figured this out in a different way, and it's probably kind of specific to the way Netbeans does things. The answer Shott85 provided is a good one also, but I think this is more specific to the way Netbeans' auto-generates code.

So I have a project where all the web methods reside named SimplyLaborServer, and a project that has the webservice client named SimplyLaborClient.

In Netbeans, under the SimplyLaborClient project in the "Generated Sources (jax-ws)" node, they have a SimplyLaborServer.java file that has a class which extends Service. It has a private URL that is hard coded to my local server's URL as follows...

url = new URL("http://localhost:8080/axis2/services/SimplyLaborServer?wsdl");

And in the default constructor, it uses this URL. But it also provides a constructor as follows where I can specify the URL...

public SimplyLaborServer(URL wsdlLocation) {
    super(wsdlLocation, SIMPLYLABORSERVER_QNAME);
}

So when I have an auto-generated method that looks like this in my client...

private static String testConnection() {
    simplylaborclient.SimplyLaborServer service = new simplylaborclient.SimplyLaborServer();
    simplylaborclient.SimplyLaborServerPortType port = service.getSimplyLaborServerHttpSoap12Endpoint();
    return port.testConnection();
}

I can simply load a Properties object that has the endpoint URL and change the one line to something like below, where props is a Properties object that has endpointUrl defined with the correct URL.

simplylaborclient.SimplyLaborServer service = new simplylaborclient.SimplyLaborServer(new URL(props.getProperty("endpointUrl")));

My only concern is that these methods are kind of auto-generated when you drag and drop them from the "Web service references" node. I don't want them to be overwritten if I make additional changes server-side.

So I'm still open to feedback if this is the correct thing to do here or not.

Thanks

Civil

I prefer this answer to the others; there is less impact on the code! To answer your last comment, I have put all of this in my WebService implementation layer, so even if I rebuild the Web Service Client itself, that piece of code will not be affected. (This implementation is actually located in a completly different project.) – Decile

"When you select New -> Webservice Client in Netbeans, it asks you right then for a WSDL URL. So of course I gave it the WSDL URL from my local Tomcat installation." -> If you want your generated client to point to the correct URL, then point to that correct URL when generating the client; the URL must be accessible when generating the client though. - With that said, I agree with @JFTxJ: use a different implementation layer/class for instantiating the client object. – Arapaho

Answer 3

You are using local (http://localhost:8080/axis2/services) WSDL for just creating the required classes of the web service.

After your developments completed you can host your web service application anywhere in the web or within the local network.

After you complete the developments of web service you can locally deploy it and use the service to create the clients required classes. When you creating the client you just has to create a URL object and pass your web service URL (hosted one) as below.

PropertyResourceBundle resoureceBundle = (PropertyResourceBundle) PropertyResourceBundle.getBundle(‘Property file name and path’);
URL serviceURL = resoureceBundle. getString("Hosted_URL_Name");
ServiceClass service = new ServiceClass(serviceURL);
ServicePort servicePort = new ServicePort(service);
servicePort.getItems();

Netbeans IDE will create many classes when you created the web service client automatically.

In above sample code ServiceClass is the web service main class which is you create initially by using the local URL. Name and constructor parameters will be vary as your web service but you have to pass the web service URL (newly hosted URL) as a string.

Then with the service class you can create a port object and accessing all the available web methods you need.

Lemire