cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject EPR Metadata and wsdlLocation attribute
Date Tue, 31 Aug 2010 15:39:59 GMT

I've had an interesting chat with Richard Opalka today regarding the way CXF
builds the Metadata part of the (WSA) EPR. Particularly, at the moment, CXF
does something like this :

<Metadata wsdli:wsdlLocation='http://localhost:8080/hello?wsdl'

Richard pointed me to the relevant section of the WSDL 2.0 spec which also
mentions WSDL 1.1. According to that section, @wsdlLocation is expected to
contain pairs similarly to the way an xsi:schemaLocation attribute does, ex,

wsdli:wsdlLocation='http://helloservice <http://localhost:8080/hello?wsdl>

where "http://helloservice" is the target namespace of the referenced WSDL

I'm not understanding where this requirement to have the pairs come from
originally (i.e, a given service endpoint is described by a single WSDL doc
(which may import few others) as opposed to a xml instance validation
depending on a number of schemas being available) and at least on the
surface the first value is redundant, but it needs to be fixed anyway
because there's a "MUST" bit in [1]. I would not even worry if it were

My question is : can it be that CXF omits the target namespace (such as
http://helloservice) for a reason ? Example, can we have legacy consumers
parsing a wsdlLocation attribute manually and assuming its value is a
location only as opposed to a pair of targetNs/location ? I don't recall now
but I vaguely remember I was doing some manual parsing of the returned EPRs
awhile back...

Do any users out there have the applications depending on this attribute ?

I'm just wondering how to fix it. I guess the contextual property can be
introduced if there's a concern that fixing it can lead to
backward-compatibility issues...

cheers, Sergey


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message