Override Glassfish Generated WSDL Servizio Endpoint Indirizzo

Question

Ho un servizio Web generato da wsgen attraverso Maven. Quando schiero il servizio per GlassFish pone l'URL del server nel WSDL. Il nostro server Glassfish è preceduta da un server proxy Apache.

Che cosa significa tutto questo è quando qualcuno accede al nostro WSDL e guarda l'endpoint del servizio e la posizione indirizzo sapone che vedono è

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

anziché

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

Credo che ho bisogno di qualche chiarimento su alcuni oggetti ...

1. E 'importante questo indirizzo endpoint? Saranno i clienti ancora essere in grado di funzionare se l'indirizzo endpoint non corrisponde l'URL del server proxy saranno chiamando per invocare il servizio. Questo chiede in sostanza le domande " è WSDL per il servizio Web come interfaccia è di opporsi ".

     

   UPDATE: In risposta a questa prima domanda in quanto sembra che " WSDL per il servizio Web come interfaccia è di opporsi ". L'indirizzo dell'endpoint specificato nel WSDL non è importante. Infatti, è relativamente banale per richiamare un'operazione servizio web su un endpoint diverso da quello indicato nel WSDL come descritto qui .

   // 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. Il WSDL viene generato automaticamente quando abbiamo distribuire a Glassfish. C'è un modo semplice per ignorare questo indirizzo dell'endpoint generata in Glassfish attraverso un ambiente application server. Se è così, posso creare un ambiente per posizionare automaticamente l'URL del server proxy nel WSDL generato.

Se uno è davvero importante e non possiamo ignorare che in alcun modo con 2, allora vuol dire in pratica abbiamo bisogno di fare costruisce separato per lo sviluppo e la produzione. Questo non "mi sembra giusto", come mi sembra l'unica cosa che dovremmo bisogno di fare per la distribuzione su un altro server è cadere una guerra esistente (e testato) da un ambiente sul nuovo server.

Answer 1

Sembra che v'è un parametro Server Name sul HTTP Listener in cui il servizio viene distribuito. È possibile specificare questo valore dalla console di amministrazione Glassfish e Glassfish utilizzerà questo nome piuttosto che il nome host nell'URL richiesta.

Purtroppo, questo parametro non consente di sovrascrivere la porta o il protocollo (http a https) se il server applicazione e server proxy non usano gli stessi (la nostra non lo fanno).

Quello che ho fatto invece ero scrivere un semplice filtro servlet per il mio servizio per gestire questo per me.

Answer 2

ho scoperto quello che io ritengo essere un modo molto semplice per affrontare il problema: utilizzare mod_substitute in Apache. Dal momento che quelli di noi con questo problema sono già utilizzando Apache, ed è costruito in e semplice, mi è piaciuto questo approccio migliore.

ho messo un blocco simile a seguito di uno dei miei file conf Apache e trovato la gioia:

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