You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2010/08/31 17:39:59 UTC
EPR Metadata and wsdlLocation attribute
Hi,
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'
xmlns:wsdli='http://www.w3.org/ns/wsdl-instance'>...</Metadata>
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>
http://localhost:8080/hello?wsdl'
where "http://helloservice" is the target namespace of the referenced WSDL
instance.
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
"SHOULD".
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
[1] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#wsdlLocation-aii
unsubscribe [SEC=UNCLASSIFIED]
Posted by Andrew Rowe <an...@abs.gov.au>.
unsubscribe
------------------------------------------------------------------------------------------------
NatStats 2010 Conference, 15-17 September 2010, Sydney. For more information visit www.nss.gov.au/natstats2010
Re: EPR Metadata and wsdlLocation attribute
Posted by Sergey Beryozkin <sb...@gmail.com>.
I've update the jaxws frontend so that Metadata/@wsdlLocation attribute
contains a pair of values (targetNS plus the actual location) by default. If
needed this can be 'reverted' by setting an
"org.apache.cxf.wsa.metadata.wsdlLocationOnly" contextual property on a
given endpoint.
As a side note, I moved the NO-OP LocatorServiceImpl from testutils closer
to the actual Locator test and used this impl to test the changes rather
than introducing some more implementations....
cheers, Sergey
On Tue, Aug 31, 2010 at 4:39 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi,
>
> 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'
> xmlns:wsdli='http://www.w3.org/ns/wsdl-instance'>...</Metadata>
>
> 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>
> http://localhost:8080/hello?wsdl'
>
> where "http://helloservice" is the target namespace of the referenced WSDL
> instance.
>
> 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
> "SHOULD".
>
>
> 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
>
> [1] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#wsdlLocation-aii
>
Re: EPR Metadata and wsdlLocation attribute
Posted by Sergey Beryozkin <sb...@gmail.com>.
I've update the jaxws frontend so that Metadata/@wsdlLocation attribute
contains a pair of values (targetNS plus the actual location) by default. If
needed this can be 'reverted' by setting an
"org.apache.cxf.wsa.metadata.wsdlLocationOnly" contextual property on a
given endpoint.
As a side note, I moved the NO-OP LocatorServiceImpl from testutils closer
to the actual Locator test and used this impl to test the changes rather
than introducing some more implementations....
cheers, Sergey
On Tue, Aug 31, 2010 at 4:39 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi,
>
> 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'
> xmlns:wsdli='http://www.w3.org/ns/wsdl-instance'>...</Metadata>
>
> 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>
> http://localhost:8080/hello?wsdl'
>
> where "http://helloservice" is the target namespace of the referenced WSDL
> instance.
>
> 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
> "SHOULD".
>
>
> 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
>
> [1] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#wsdlLocation-aii
>