Bruce,
I took the WSDL file, commented out the imports, pasted the schemas
inline, and validated the WSDL. I found one error:
There is no schema component of the name [ds:Signature] defined
in the WSDL either via imported or embedded schema.
I don't understand why this error comes up, because as far as I can
tell, the DSig namespace is properly imported, and certainly the
Signature element is properly defined in the DSig namespace. I know
that quite a few folks have experienced problems when trying to use
the DSig namespace, so my guess is that many tools have trouble with
the "#" in the namespace URI.
My tool also raised two warnings:
You have nested sequences (which should be okay)
You have a maxOccurs attribute on an xsd:sequence declaration
(something to avoid)
Something else I noticed: The request and reply schemas do not specify
elementFormDefault="qualified". This isn't an error, but it often
causes interoperability errors.
But I reiterate my earlier comment. I strongly discourage you from
defining headers in the WSDL. The WSDL represents the information that
the application should be responsible for. Typically headers are added
to the message and processed by the middleware, not by the
application. Therefore the requirement for headers should be specified
separately -- preferably using WS-Policy, even though it isn't final
yet.
I also *strongly* recommend that you not define your own header
formats, but rather that you conform to standard SOAP extensions -- in
your case WS-Addressing and WS-Security. (You've used standard element
definitions from WS-Addressing and XML Signature, but you haven't
followed the standard header formats for using these elements.)
Axis2 can automatically manage WS-Addressing and WS-Security headers
for you, and they will do so in an interoperable way. But you mustn't
define the headers in the WSDL -- you must configure them in the
config file.
Anne
On 1/17/07, R Bruce Hoffman <[EMAIL PROTECTED]> wrote:
First, let me sincerely thank you for your rapid response.
I had originally questioned the other developers on that repeated import
of the namespace and been told it was ok. I probably have to be more
forceful when my gut says it's wrong... but, as you can probably tell, I
am new to this WSDL stuff.. previous services I have deployed were from
POJOs and not defined by or through WSDL, and I am no xml expert either.
At least I have ammo to go back to them and have their manager apply the
"2 by 4" process... ;-)
Next here are the other two xsd's that I had left off.
again, thanks.
On Wed, 2007-01-17 at 08:50 -0500, Anne Thomas Manes wrote:
> Bruce,
>
> Giving the WSDL a quick look, I noticed that it is not valid. I don't
> know if this is what's causing your problem, but it's a good place to
> start.
>
> In your WSDL <types> section, you attempt to import the same namespace
> twice. This is not allowed. If the namespace is defined in multiple
> schemas, and your goal is to import both schemas, then you must define
> a schema with the same target namespace and <xs:include> the schemas
> into the namespace. e.g.:
>
> <xs:schema targetNamespace="urn:/fih/c-efm/purchase-order/1.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema";
> elementFormDefault="qualified">
> <xs:include
>
schemaLocation="1.0/receive-purchase-order-request.xsd"/>
> <xs:include
> schemaLocation="1.0/receive-purchase-order-reply.xsd"/>
> </xs:schema>
>
> Another error that I found: you must not specify the parameterOrder
> attribute in the <wsdl:operation> definition when using document
> style. (It is only used with RPC style.)
>
> As a general practice, it's a bad idea to define headers in your WSDL,
> especially if you are using standard headers. (The XMLBeans error
> indicates that you are using WS-Addressing and DSIG.) You should
> define your header requirements using WS-Policy and configuration
> files.
>
> Also, in regards to schema you did provide
> (targetNamespace="urn:/fih/purchase-order"), some best practices
> advice:
>
> - Avoid using anonymous types. Rather than defining structures as
> elements, define them as named types, and then define elements as
> those types. e.g.:
>
> Do this:
>
> <xs:complexType name="baselineItemDataLoop">
> <xs:sequence>
> <xs:element ref="BaselineItemDataSegment"
minOccurs="0"/>
> <xs:element ref="ReferenceIdentificationSegment"
minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
> <xs:element name="BaselineItemDataLoop" type="baselineItemDataLoop"/>
>
> Rather than this:
>
> <xs:element name="BaselineItemDataLoop">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="BaselineItemDataSegment"
minOccurs="0"/>
> <xs:element ref="ReferenceIdentificationSegment"
minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> And I recommend being cautious about defining each element as a global
> element. The only elements that really should be defined as global
> elements are those elements that will be the root of a document. i.e,
> rather than defining "BaselineItemDataSegment" as a gloal element and
> referencing it from the type definition, define the element within the
> type definition and reference its type, e.g.:
>
>
> We also need to see the "unr:/fih/c-efm/purchase-order/1.0" schema files.
> (You sent us the "http://www.fih.org/XML/WD0"; namespace schema, instead.)
>
> <xs:complexType name="baselineItemDataLoop">
> <xs:sequence>
> <xs:element name="BaselineItemDataSegment"
> type="baselineItemDataSegment
> minOccurs="0"/>
> <xs:element name="ReferenceIdentificationSegment"
> type="referenceIdentificationSegment"
> minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
>
> Anne
>
> On 1/17/07, R Bruce Hoffman <[EMAIL PROTECTED]> wrote:
> > Sure... sorry.
> >
> > Also, when using xmlbeans binding, I get the following error:
> >
> > Using AXIS2_HOME: /usr/local/axis2
> > Using JAVA_HOME: /usr/lib/jvm/java-1.5.0-sun
> > Retrieving schema at '../../../../fih/1.0/fih-header.xsd', relative to
> >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > Retrieving schema at
> >
'http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd',
relative to 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > Retrieving schema at
> > 'http://schemas.xmlsoap.org/ws/2004/08/addressing/', relative to
> > 'file:/home/hoffmanb/ax/wsdl/fih/1.0/fih-header.xsd'.
> > Retrieving schema at '1.0/receive-purchase-order-request.xsd', relative
> > to
> >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > Retrieving schema at 'LimitedPurchaseOrder.xsd', relative to
> >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/1.0/receive-purchase-order-request.xsd'.
> > Retrieving schema at '1.0/receive-purchase-order-reply.xsd', relative to
> >
'file:/home/hoffmanb/ax/wsdl/fih/c-efm/purchase-order/receive-purchase-order/'.
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [urn:/fih/1.0] and systemId
> > [/fih/1.0/fih-header.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > and systemId [/1.0/receive-purchase-order-request.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [urn:/fih/c-efm/purchase-order/1.0]
> > and systemId [/1.0/receive-purchase-order-reply.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId
> > [http://www.w3.org/2000/09/xmldsig#] and systemId
> >
[/http:/www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId
> > [http://schemas.xmlsoap.org/ws/2004/08/addressing] and systemId
> > [/http:/schemas.xmlsoap.org/ws/2004/08/addressing]
> > Jan 16, 2007 1:39:58 PM org.apache.axis2.xmlbeans.CodeGenerationUtility
> > $Axis2EntityResolver resolveEntity
> > INFO: Resolving schema with publicId [http://www.fih.org/XML/WD0] and
> > systemId [/1.0/LimitedPurchaseOrder.xsd]
> > Exception in thread "main"
> > org.apache.axis2.wsdl.codegen.CodeGenerationException:
> > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > at
> >
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
> > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32)
> > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21)
> > Caused by: java.lang.RuntimeException:
> > java.lang.reflect.InvocationTargetException
> > at
> >
org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:92)
> > at
> >
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177)
> > ... 2 more
> > Caused by: java.lang.reflect.InvocationTargetException
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> >
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at
> >
org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(XMLBeansExtension.java:82)
> > ... 3 more
> > Caused by: java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
> > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > value for type of processContents attribute in xs:wildcard
> > at
> >
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:242)
> > ... 8 more
> > Caused by: org.apache.xmlbeans.XmlException:
> > http://schemas.xmlsoap.org/ws/2004/08/addressing/:61:1: error:
> > cvc-enumeration-valid: string value 'none' is not a valid enumeration
> > value for type of processContents attribute in xs:wildcard
> > at
> >
org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(SchemaTypeSystemCompiler.java:225)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> >
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at
> > org.apache.xmlbeans.XmlBeans.compileXmlBeans(XmlBeans.java:667)
> > at
> >
org.apache.axis2.xmlbeans.CodeGenerationUtility.processSchemas(CodeGenerationUtility.java:160)
> > ... 8 more
> >
> >
> >
> >
> > On Wed, 2007-01-17 at 10:41 +0530, Amila Suriarachchi wrote:
> > > Can you attach your fih-header.xsd file?
> > >
> > > On 1/16/07, R Bruce Hoffman <[EMAIL PROTECTED]> wrote:
> > > I just can't seem to get Axis2 1.1.1 wsdl2java.sh to properly
> > > create
> > > skeleton code and Axiom or XmlBeans artifacts correctly for,
> > > what seems
> > > to be, relatively simple wsdl and xsd's.
> > >
> > > Below is the xsd and wsdl information. I have used FC4, FC5,
> > > Ubuntu and Debian Sarge. I have tried 1.1, a snapshot before
> > > 1.1.1 and 1.1.1 releases. Sun java 1.5.0_09 and 10.
> > >
> > > I am being told that the wsdl and xsd information is valid (by
> > > the
> > > original developers). Both NetBeans 5.5 and Eclipse (under
> > > WDSCi) seem
> > > to agree that they are at least valid.
> > >
> > > When I run wsdl2java with ADB binding, the message parts all
> > > end up in
> > > the default package with empty package statements
> > > ("package ;"). The
> > > ExtensionMapper.java ends up in an (invalid) null package.
> > > (It's named
> > > "null" and on the output src path.)
> > >
> > > All of the types, after the first array type, are listed with
> > > "This was
> > > an array!" in the comments, but have no array declarations in
> > > their
> > > _type_nn classes... the [] markers are not produced after the
> > > first
> > > repeating element.
> > >
> > > I have looked at trying to clean up this code to make it
> > > usable, but I
> > > would think that Axis2 should be producing code that, at the
> > > very least,
> > > would compile through the ant build if the wsdl2java succeeds,
> > > which it
> > > does complete in this case. If not, it should probably give me
> > > an error
> > > in the generation of the ADB code.
> > >
> > > Maybe its something simple or I'm just a dope, or both, but I
> > > am lost.
> > >
> > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Amila Suriarachchi,
> > > WSO2 Inc.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
