cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Proposal -- removing irrelevent services from WSDL
Date Tue, 11 Nov 2008 18:24:02 GMT

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.


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

View raw message