5
votes

I have a web service generated by wsgen through maven. When I deploy the service to Glassfish it places the server URL into the WSDL. Our Glassfish server is fronted by an Apache proxy server.

What this all means is when someone accesses our WSDL and looks at the service endpoint and the soap address location they see is

http://app server url/service...

instead of

http://proxy server url/service...

I guess I need some clarification on a few items...

  1. Is this endpoint address important? Will clients still be able to function if the endpoint address does not match the URL of the proxy server they will be calling to invoke the service. This basically asks the questions "is WSDL to web service as interface is to object".

    UPDATE: In response to this first question it does appear that "WSDL to web service as interface is to object". The endpoint address specified in the WSDL is not important. In fact, it is relatively trivial to invoke a web service operation on a different endpoint than the one specified in the WSDL as described here.

    // Create service and proxy from the generated Service class.
    HelloService service = new HelloService();
    HelloPort proxy = service.getHelloPort();
    
    // Override the endpoint address
    ((BindingProvider)proxy).getRequestContext().put(
            BindingProvider.ENDPOINT_ADDRESS_PROPERTY, 
            "http://new/endpointaddress");
    proxy.sayHello("Hello World!");
    
  2. The WSDL is generated automatically when we deploy to Glassfish. Is there an easy way to override this generated endpoint address in Glassfish through an app server setting. If so, I can create a setting to automatically place the proxy server URL into the generated WSDL.

If 1 is indeed important and we can't override it in any way with 2, then it basically means we'll need to do separate builds for development and production. This does not "feel right" as it seems to me the only thing we should need to do to deploy to another server is drop an existing (and tested) war from one environment onto the new server.

2

2 Answers

5
votes

It turns out there is a Server Name parameter on the HTTP Listener where the service is deployed. You can specify this value from the Glassfish administration console and Glassfish will use this name rather than the host name in the request URL.

Unfortunately, this parameter will not allow you to override the port or protocol (http to https) if your app server and proxy server do not use the same ones (ours don't).

What I did instead was write a simple servlet filter for my service to handle this for me.

4
votes

I discovered what I consider to be a very simple way to deal with the issue: use mod_substitute in Apache. Since those of us with this problem are already using Apache, and it's built in and simple, I liked this approach best.

I put a block similar to the below in one of my Apache conf files and found joy:

<Location />
   AddOutputFilterByType SUBSTITUTE text/xml
   Substitute "s|http://internal:8080/xxx|https://external/xxx|ni"
</Location>