[jboss-user] [JBossWS] - Re: replacement of REPLACE_WITH_ACTUAL_URL when using annota

[will.tatam]

PeterJ: 

If you re-read my first post, you will see that i already explained that some of our jboss servers are directly accessible and some are not.

This means that for the servers that are directly accessible, using the ${jboss.bind.address} is a reasonable guess when trying to construct the full url for the soap address.

For example

http://123.123.123.123:8080/myapp/mySoapService

or if @WebContext(transportGuarantee="CONFIDENTIAL") then jboss will guess

https://123.123.123.123:8443/myapp/mySoapService

Now, as I have already stated this is not applicable for all servers. If a jboss server is behind a firewall then the bind address might not be publicly accessible.

This leaves a bit of an issue, if you leave true then you would end up with an address like

https://192.168.1.123:8443/myapp/mySoapService

which is unless unless your clients have a VPN in place, in which case the firewall is redundant as you would be side-stepping the firewall by using the VPN tunnel to get behind it !!

The old way was use false. If this by itself then just breaks your service as your wsdl now just contains the litteral value REPLACE_WITH_ACTUAL_URL. To get round this, we had modified our build system so when building copies of our app that were destined for use on our servers that are not directly accessible, we used to replace the REPLACE_WITH_ACTUAL_URL with the correct address as compilation time. We are happy to continue with this model, but are unable to as we have yet to find a way to effect the construction of the soap address within the wsdl that is created at runtime

What client code is being used to consume a given web service is irrelevant as when consuming a soap webservice you need wsdl that defines a url for it to actually perform a given action, which if it it contains a private ip, as per RFC1918 is not going to be much use to you unless you are also inside the same address space. Also the fact that our "firewall" is infact a SSL off-loader is again irrelevant to the construction of the URL

I have found very little in the way of documentation for the virtualHosts option, but this is in effect what we want to define as it is the host part of the url we wish to override (we already use the context to set the filepath aspect of the url)

Can anyone spread any further light on virtualHosts and confirm (or deny) if JBoss AS 4.2.3 supports it's usage ?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188240#4188240

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188240