cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Namespaces in WSDL types
Date Thu, 05 Feb 2009 01:28:35 GMT
Um, I sort of don't believe it. Can you post any sort of a test case?

On Wed, Feb 4, 2009 at 7:04 PM, Cesko, Andrejs (IDEAS) <> wrote:

> Good day everyone,
> We are currently working on integrating our own databinding solution on
> cxf. Our databinding solution generates a bunch of XML schemas that we
> are using in <types> section of WSDL file. Each of the schema has a
> unique namespace, but also they can refer to each other. Our problem is
> that these namespaces are stripped down from the schemas during the WSDL
> generation. We would like to know why and where these namespaces are
> being stripped and if it is possible to prevent this?
> Also, here are more details about the problem:
> The schemas we generate have additional namespaces (i.e. <xsd:schema
> xmlns:namespace1=http://namespace/1 <http://namespace/1>  ...>), we use
> these namespaces in our <complexType> sections, for instance we will use
> it like this <xsd:element name="element1"
> type="namespace1:typeofelement"/>. After adding all the schemas to the
> serviceInfo via serviceInfo.addSchema(schema), we can see in our wsdl
> file that all these additional namespaces are stripped down. So in the
> <types> section of WSDL file we will have the schema with our
> <xsd:element name="element1" type="namespace1:typeofelement"/>, but the
> namespace1 won`t be declared anywhere
> (xmlns:namespace1=http://namespace/1 <http://namespace/1>  disappears
> from schema). It looks like CxF is perfectly fine with this, while we
> consider this an invalid WSDL file.
> On a side note, CxF creates customized prefixes for the namespaces (i.e.
> "tns", "ns0", "ns1"), but these prefixes are not declared in the WSDL
> file itself. Is it a proper and expected behaviour?
> --------------------------------------------------------------------------
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.

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