The WSDL, that is a required deployment artifact for an endpoint, has a soap:address element which points to the location of the endpoint. JBoss supports rewriting of that SOAP address.
When a server answers to different virtual addresses, the location of the endpoint (soap:address) declared in the wsdl and obtained from the contextServlet could be either the address setted on the wsdl at deploy time or the address setted in properties of the file jbossws.beans/META-INF/jboss-beans.xml (webServiceHost, webServicePort, alwaysModifySOAPAddress).

Both addresses are staticaly mapped (in the wsdl or on the server configuration file) and this is the problem in our environment (but would be a problem also on more trivial environment with one multiheaded machine). Note that this issue concerns the wsdl generation phase only; of course webservice calls work perfectly with all virtual addresses. In fact the problem is present also on the ContextServlet (is the servlet called when you ask for the list of deployed services), but it's a minor trouble.

Our patch adds a configuration parameter in jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml named rewriteSOAPAddressWithCalledHost (true/false). If this parameter is set to true soap:address is rewrited using the host and port used by the client to get the wsdl, and also the ContextServlet does the same. Of course it solves the problem because soap:address and url in ContextServlet depend on the Virtual host used while asking them.
Without this patch, the only solution for us was to provide our customers with personalized static wsdl having soap:address modified to match the correct virtual address. Of course it was time wasting and made change management very very hard.

For a complete description of the problem in a real word environment refer to my blog: http://www.javalinux.it/blogs/index.php?title=multiple_virtual_host_and_soap_address_p&more=1&c=1&tb=1&pb=1