cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Clegg <>
Subject Re: Proposal -- removing irrelevent services from WSDL
Date Fri, 07 Nov 2008 10:33:41 GMT

I have seen (broken) clients that assume a 1-wsdl-1-service relationship and
get confused with more than one. eg the public services registry at does this, although the developers have acknowledged
this as a bug.

More importantly though, it's something that I have to explain in my user
docs in order for it to make sense. If a wsdl is published for a given
service, they don't expect to see other services defined in there. They
don't expect to see multiple identical wsdls in different locations and with
different names. This makes it seem like a wrinkle.

I could publish a static master wsdl elsewhere, or individual ones, but that
would require separate upkeep, and wouldn't benefit from CXF's address
rewriting if the service moved.

Agreed that it should be optional though.


Sergey Beryozkin-3 wrote:
> Hi
>> Okay, thanks.
>> No particular opinion about the WSDL pruning proposal then?
> IMHO it makes sense. If the endpoint exposes only one of many services
> described in a wsdl there seems to be no need in keeping the 
> rest of them in a published wsdl. That said it might be a bit expensive to
> ensure the 'unused' services are stripped.
> Is there any other reason in yourself being proposing it, other thna in a
> published wsdl be verbose ? Say, a client code has issues 
> figuring out which service definition to use or something like that ?
> One possible complication here is that one service might return references
> to transient services also defined in this wsdl. Say, 
> Bank return WSA refs to Account services. There might be no direct link
> between these 2 services at a wsdl level so if a Bank 
> endpoint is published and its published wsdl instance won't contain a
> definition for Account then it might cause some issues at a 
> point when Account reference is used at a client side ? I'm not sure if it
> actually will, but it's something which may need to be 
> looked at...
> Cheers, Sergey
>> Andrew.
>> Andi Abes wrote:
>>> The soapAction is the logical name of the operation - so CXF is very
>>> correct in not touching it.
>>> A good practice is not to use hostnames for it, but rather URI's that
>>> represent the logical purpose of the operation.
>>> The soap:address is obviously used to connect to the service, hence it
>>> must be updated.
>>>> -----Original Message-----
>>>> From: Andrew Clegg []
>>>> Sent: Thursday, November 06, 2008 6:56 AM
>>>> To:
>>>> Subject: Proposal -- removing irrelevent services from WSDL
>>>> 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.
>>>> --
>>>> View this message in context:
>>>> irrelevent-services-from-WSDL-tp20359717p20359717.html
>>>> Sent from the cxf-dev mailing list archive at
>> -- 
>> View this message in context:
>> Sent from the cxf-dev mailing list archive at

View this message in context:
Sent from the cxf-dev mailing list archive at

View raw message