1) "import.sdo" loads the WSDL/XSD to create SDO types for your model.
2) For the NPE, can any of the SDO folks take a look?
3) The SDO dependency for the Axis2 "binding.ws" is a temporary hack. It will
be removed when we have the pluggable databinding in place. Please refer to
another thread with title "Re: svn commit: r432156" for the related discussion.
Thanks,
Raymond
----- Original Message -----
From: Chris Wall
To: [EMAIL PROTECTED] ; tuscany-dev@ws.apache.org
Sent: Monday, August 21, 2006 11:21 AM
Subject: binding.ws, SDO, NPE
Hey Raymond. Thanks for finding my silly getString(str) bug.
I'd like to understand more about binding.ws. It looks like with your recent
check-ins binds SDO to binding.ws. With that, all outgoing and incoming
objects are converted to SDO objects to be manipulated by the Axis2 binding.
To do so, "import.sdo" reads in the WSDL to register schema types as SDO
objects. Is that correct?
The issue I'm having is that ImportSDOLoader bombs when upon registering the
following complex type:
<types>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified" targetNamespace="java: com.bea.proto.webservice"
xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:complexType name="Patient">
<xs:sequence>
<xs:element minOccurs="1" name="Id" nillable="true" type="xs:int"/>
<xs:element minOccurs="1" name="Dob" nillable="true"
type="xs:dateTime"/>
<xs:element minOccurs="1" name="FirstName" nillable="true"
type="xs:string"/>
<xs:element minOccurs="1" name="Gender" nillable="true"
type="xs:string"/>
<xs:element minOccurs="1" name="LastName" nillable="true"
type="xs:string"/>
<xs:element minOccurs="1" name="MiddleName" nillable="true"
type="xs:string"/>
<xs:element minOccurs="1" name="Phone" nillable="true"
type="xs:string"/>
<xs:element minOccurs="1" name="Ssn" nillable="true"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
...
</types>
java.lang.NullPointerException
at org.eclipse.xsd.ecore.XSDEcoreBuilder.createFeature(
XSDEcoreBuilder.java:1765)
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.createFeature(SDOXSDEcoreBuilder.java:139)
at
org.eclipse.xsd.ecore.XSDEcoreBuilder.createFeature(XSDEcoreBuilder.java:1850)
at
org.eclipse.xsd.ecore.XSDEcoreBuilder.computeEClass(XSDEcoreBuilder.java:1002)
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.computeEClass(SDOXSDEcoreBuilder.java:104)
at org.eclipse.xsd.ecore.XSDEcoreBuilder.computeEClassifier
(XSDEcoreBuilder.java:260)
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.computeEClassifier(SDOXSDEcoreBuilder.java:113)
at
org.eclipse.xsd.ecore.XSDEcoreBuilder.getEClassifier(XSDEcoreBuilder.java :212)
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEcoreBuilder.java:76)
at
org.eclipse.xsd.ecore.XSDEcoreBuilder.generate(XSDEcoreBuilder.java:2644)
at org.apache.tuscany.sdo.helper.XSDHelperImpl.define
(XSDHelperImpl.java:189)
(The above is lost when converting to IllegalArgumentException.)
java.lang.IllegalArgumentException
at
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:210)
at
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:169)
at
org.apache.tuscany.databinding.sdo.ImportSDOLoader.importWSDL(ImportSDOLoader.java:115)
at org.apache.tuscany.databinding.sdo.ImportSDOLoader.load
(ImportSDOLoader.java:77)
I haven't yet looked into the xsd source. Any ideas?
Also, I'm wondering is why SDO conversion is needed. Couldn't the impl be
simpler by relying on Axis2's native transport, Axiom? Wouldn't this also
eliminate the SDO dependency? I'd like to understand deeper as to why this
WSDL works outside of binding.ws.
Thanks.
-Chris
