Override Glassfish generado Servicio WSDL Dirección del punto final

Question

Tengo un servicio web generado por wsgen a través de maven. Cuando despliego el servicio a Glassfish, coloca la URL del servidor en el WSDL. Nuestro servidor Glassfish está liderado por un servidor proxy Apache.

Lo que esto significa es cuando alguien accede a nuestra WSDL y mira al extremo de servicio y la ubicación de la dirección de jabón que ven es

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

en lugar de

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

supongo que necesito una aclaración en algunos artículos ...

1. ¿Es importante esta dirección de punto final? ¿Los clientes todavía podrán funcionar si la dirección del punto final no coincide con la URL del servidor proxy al que llamarán para invocar el servicio? Esto básicamente hace que las preguntas "es WSDL al servicio web como la interfaz es para el objeto".

   ACTUALIZACIÓN : En respuesta a esta primera pregunta sí parece que "WSDL para el servicio web como interfaz es de oponerse". La dirección del punto final especificada en el WSDL no es importante. De hecho, es relativamente trivial invocar una operación de servicio web en un punto final diferente al especificado en 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. El WSDL se genera automáticamente cuando hacemos uso de Glassfish. ¿Existe alguna manera fácil de anular esta dirección de punto final generada en Glassfish a través de una configuración de servidor de aplicaciones. Si es así, puedo crear una configuración para colocar automáticamente la URL del servidor proxy en el WSDL generado.

Si 1 es realmente importante y no podemos anularlo en cualquier forma con 2, a continuación, que básicamente significa que tendremos que hacer construye separada para el desarrollo y la producción. Esto no se "siente bien", ya que me parece que lo único que deberíamos hacer para implementar en otro servidor es descartar una guerra existente (y probada) de un entorno en el nuevo servidor.

Answer 1

Resulta que hay un parámetro Server Name en el HTTP Listener donde se implementa el servicio. Puede especificar este valor desde la consola de administración de Glassfish y Glassfish utilizará este nombre en lugar del nombre de host en la URL de solicitud.

Desafortunadamente, este parámetro no le permitirá anular el puerto o protocolo (http a https) si su servidor de aplicaciones y servidor proxy no usa los mismos (los nuestros no).

Lo que hice en su lugar fue write a simple servlet filter para que mi servicio manejara esto por mí.

Answer 2

Descubrí lo que considero que es una forma muy simple de tratar el problema: use mod_substitute en Apache. Dado que aquellos de nosotros con este problema ya estamos usando Apache, y está integrado y es simple, me gustó este enfoque de la mejor manera.

pongo un bloque similar a la de abajo en una de mis archivos de configuración del Apache y encontré la alegría:

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