I am not sure if we can use the request object. The request (org.apache.geronimo.webservices.WebServiceContainer.Request) object gives you the address for the remote host which is the address for the proxy server, however no information on the port. Another way could have been to utilize the header "request.getHeader("X-Forwarded-Host")" but this is not a standard header AFAIK. So this option can also to be ruled out. So I think modifying the schema is the best way ahead.
Thanks David and Jarek. I am investigating on the comment made by David and seems to have found some headers which are being appended by HTTP server. I will investigate further in this direction to find out if the request object can be used to attain this.
AshishOn Tue, Feb 8, 2011 at 1:06 AM, David Jencks <email@example.com> wrote:
Changing the schema like this shouldn't be a problem if its necessary. I'd like to understand better why its necessary. Perhaps there's another way.
I thought that the way this was coded was that the host and port from the incoming request were stuffed into the wsdl being returned. Doesn't the proxy server tell us what the original request was in some way such as a request attribute? Could we look for that information and use it if available and use the request itself if not?
On Feb 7, 2011, at 10:39 AM, Jarek Gawor wrote:
> Modifying the schema (without changing the namespace) is fine as long
> as you make the new element(s) optional. That at least is what we have
> done in the past.
> On Fri, Jan 28, 2011 at 10:00 AM, Ashish Jain <firstname.lastname@example.org> wrote:
>> When geronimo is front ended with a proxy say Apache HTTP server and a web
>> service is invoked via this proxy. The auto
>> generated wsdl will have the soap:address as
>> http://<g_host>:<g_port>/service_name. Instead it should be
>> <proxy:port>/service_name. The method which takes care of all this is
>> . The baseUri attribute in the class has to be modified so that appropriate
>> soap:address can be written in the wsdl file.
>> So as to get this property into geronimo one of the way would be to be able
>> to specify in geronimo deployment descriptor.
>> Adding a new attribute may require schema change.
>> Is this acceptable? Are there any other alternative ways through which this
>> can be achieved?