overriding or setting web service endpoint at runtime for code generated with wsimport
Asked Answered
C

2

52

Using code that was generated with wsimport, can the service endpoint be overridden without having to regenerate the code?

I have written a simple java webservice, following are the steps:

  1. I compile the java class and generate a war file
  2. Deploy the war file to my app server (tomcat)
  3. Access the WSDL via the URL e.g. localhost:8080/service/helloservice?wsdl
  4. use the URL with wsimport.bat to generate client classes for example: wsimport http://localhost:8080/service/helloservice?Wsdl
  5. I use those classes in my client app to call the service

The problem is that is the service is deployed on an app server running on port other than 8080, the communication between client and service never happens. I am trying to know what is the best way to create stubs that does not have server and port hardcoded in the stub used by the client.

Colchicum answered 25/8, 2010 at 18:29 Comment(1)
Related question: #3568356Hero
H
85

Your client can set the end-point in the service "port" at runtime via the BindingProvider interface.

Consider the JAX-WS client in this JAX-WS tutorial. Another way to write this code would be:

HelloService service = new HelloService();
Hello port = service.getHelloPort();
BindingProvider bindingProvider = (BindingProvider) port;
bindingProvider.getRequestContext().put(
      BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
      "http://foo:8086/HelloWhatever");
String response = port.sayHello(name);

Caveat: I haven't downloaded the tutorial code and tested this code against it.

Hero answered 25/8, 2010 at 18:59 Comment(5)
I am looking at this. Apparently with code generated with recent versions of JAX-WS wsimport, the WSDL must be accessible at the address specified to wsimport at the time new HelloService() is executed (long before the binding provider even has a chance for kicking in). Is the only way to fix this, to have a local copy of the WSDL which can be parsed so the constructor is successful?Algoid
@ThorbjørnRavnAndersen If memory serves you can set the WSDL location to anything you want at generation time - see the -wsdllocation argument for the wsimport tool. But I would generally provide it explicitly in an unmanaged client - example.Hero
In my case, it throws exception when creating the service object. How can i solve this?Schnitzler
@ThorbjørnRavnAndersen. Recent versions of wsimport has -clientjar flag. See weblogs.java.net/blog/ramapulavarthi/archive/2010/09/03/….Actinotherapy
@Schnitzler That isn't enough information - create a new question with the details.Hero
U
2

I faced the same issue, and it was terrible coz once the code is moved to production it always looked for the hardcoded WSDL location i.e. Windows C:........etc

I have gone thru various post and pages to find the answer however all was failing then found myself a way by looking at the Service Class generated by JAX-WS imports.

I had to override the JAX-WS WSDL location implementation in my calling class like this.

URL baseUrl;
URL wsdlURL = null;
baseUrl = <your Services>.class.getResource(".");
try {
    wsdlURL = new URL(baseUrl, "http://<your path>?wsdl");
    } catch (MalformedURLException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
}

<your Services> yourServices = new <your Services(wsdlURL,new QName("your namespace", "<your service name>"));
System.out.println(Services.getWSDLDocumentLocation());
YourInterface YourInterfacePort =  yourServices.getServicePort();
BindingProvider bindingProvider = (BindingProvider)YourInterfacePort;
bindingProvider.getRequestContext().put(
          BindingProvider.ENDPOINT_ADDRESS_PROPERTY,      url);

YourInterfacePort.methods();

Unqualified answered 25/6, 2014 at 6:16 Comment(1)
is there any way to get namespace and service name which is required is service constructor(innew QName("","")) programmatically? we only have url of .wsdl file. why service don't read service name and namespace from .wdsl file itself ? thanks in advanceBleeder

© 2022 - 2024 — McMap. All rights reserved.