cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cesko, Andrejs \(IDEAS\)" <Andrejs.Ce...@morganstanley.com>
Subject Namespaces in WSDL types
Date Thu, 05 Feb 2009 00:04:56 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message