Title: Message
Thanks for the suggestion, Thunder. Unfortunately, making a deployment-specific web.xml is precisely what we cannot do. We need to be able to deploy the identical WAR on our dev, QA, and production server stacks and have it behave properly based upon the server configuration.
 
We are also limited in the service client, which is Flash MX ActionScript. We give it the URL of the WSDL file, and it uses that to determine the URL of the service. We can serve up different versions of a static (not autogenerated) WSDL file, but this is the same issue; we would have to maintain different versions of the deployables depending upon where it is deployed.
 
If the WSDD parser could do scripting substitutions for system props, that would easily solve this issue. Any other ideas?
 
Many thanks,
 
-Mike
-----Original Message-----
From: Parley, Thunder Jon [mailto:[EMAIL PROTECTED]
Sent: Monday, April 12, 2004 12:44 PM
To: [EMAIL PROTECTED]; Mike Panzitta
Subject: RE: How can I specify the service host/port in autogenerated WSDL?

Hi Mike,
 
Here's a suggestion:
- Put your endpoint as a context-param in the web.xml of your WAR.
- In your service invocation, get the value from the context and make your call to the correct endpoint.
- If you are using generated binding stubs, then you will have something like (assuming JSP, servlet is almost the same)
    String myEndPoint = application.getInitParameter("my.endpoint"); // whatever your parameter name is
    ServiceLocator loc = new ServcieLocator();
    ServiceStub stubby = loc.getService( new java.net.URL(myEndPoint) );
- Same idea for dynamic invocation.
 
Then you only maintain different versions of you web.xml, configured correctly depending on the deployment environment, at build time, you make the correct one called web.xml for your build.
 
HTH,
 
Thunder
-----Original Message-----
From: Mike Panzitta [mailto:[EMAIL PROTECTED]
Sent: Monday, April 12, 2004 12:09 PM
To: [EMAIL PROTECTED]
Subject: How can I specify the service host/port in autogenerated WSDL?

Hi all,
 
I am deploying some Axis-based web services using the integrated approach, with all files combined into a WAR file to be deployed into Tomcat (which happens to be running within JBoss 3.2.3). Access to the web services is through an Apache httpd fronting server (for numerous reasons), and the development process is such that we have several server stacks for development, QA, and production (each with a JBoss/Tomcat/Axis server and Apache front server). In addition, it is likely that we will be using NATting firewalls in front of the server stacks.
 
I am unable to figure out how to have the <wsdlsoap:address location="xxx" /> element in the autogenerated WSDL use the host and port of the corresponding fronting server. I discovered the <endpointURL /> element in the WSDD, but as far as I can tell, this specifies a static value, and the host/port can't be specified from within the packaged WAR file; it needs to be specified somewhere in the server configuration (e.g. system property, Tomcat or JBoss configuration, etc.). I'm looking for some kind of solution that would let me use something like <endpointURL>${httpd.host.and.port}/axis/services/myService</endpointURL> in the WSDD (where "httpd.host.and.port" is a system or other externally specified property). Alternatively, is there an option to force the host/port of the <wsdlsoap:address location="xxx" /> element to take its value from the Host: HTTP request header?
 
The bottom line is that if the autogenerated WSDL is obtained from http://myhost.mydomain:9999/axis/services/myService?wsdl , then the host and port in the WSDL's <wsdlsoap:address location="xxx" /> element should use myhost.mydomain:9999 for the host and port portion. This can be automagically determined, or it can be specified in the server configuration, but it can't be defined from within the packaged WAR file.
 
I have to believe that others have encountered this issue before me. Any assistance or pointers would be greatly appreciated. BTW, we are using Axis 1.1, but if a solution exists in 1.2, we can certainly go that route.
 
Thanks in advance,
 
-Mike
 
---
Dr. Michael J. Panzitta
VP, Technology
PeopleMatter, Inc.
Voice: +1 (425) 482-4444
Mobile: +1 (206) 979-7769
www.peoplematter.com
 

Reply via email to