This is something I'm kind of "on the fence" about. There are definitely use cases where having the other services/ports in the wsdl so this behavior definitely would need to be optional.
The usecases that I have in mind: 1) Clustering/Failover - the clustering/failover stuff kind of relies on this. If the other nodes in the cluster are defined in the wsdl, if something should occur to this node, the clients would automatically fail over to one of the other ports. Thus, they need to be there for that to work. 2) Other transports - If the service is exposed via multiple transports/bindings, the client could be created via the HTTP wsdl, but then select one of the other transports/bindings. For example, the wsdl may have both an HTTP transport and a JMS transport. The client may want to select the JMS port to take advantage of the async API's and stuff for scalability. Anyway, it's a good idea, but it would definitely need to be optional. Dan On Thursday 06 November 2008 6:56:01 am Andrew Clegg wrote: > Hey folks, > > I have a WSDL-first project which contains several service definitions, > each with a separate binding to a separate port type. > > When I go to the 'services' page for the WAR in Tomcat, I get a bunch of > links like: > > http://myserver:8080/MyWar/services/ServiceOne?wsdl > > http://myserver:8080/MyWar/services/ServiceTwo?wsdl > > etc. > > Exactly the same WSDL, but published to different URLs. > > What would be really neat is if CXF could trim out the unused services, > bindings and port type definitions when it publishes the WSDL. > > I know it already does some editing as the soap:address location attributes > are correct. Would the maintainers be interested in a patch to do this if I > volunteered? I *think* Axis2 does this, if I remember correctly, so there > might be some usable code in there. > > Interestingly, I just noticed the soap:operation soapAction attributes are > not updated the same way as soap:address is. They still have the localhost > test URLs which I hardcoded into my WSDL. Is this intentional, or a bug, or > a sign I've misconfigured something? (Does anything even use this?) > > Andrew. -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
