History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XFIRE-617
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dan Diephouse
Reporter: Jose Manuel Valladares Pernas
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
XFire

NullPointerException when generating stub from WSDL

Created: 01/Sep/06 03:27 AM   Updated: 11/Sep/06 04:58 PM
Component/s: Generator
Affects Version/s: 1.2
Fix Version/s: 1.2.2

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive files.ZIP (128 kb)
2. Zip Archive XmlSchemaTestInclude.zip (2 kb)

Environment:
Linux OpenSuse 10.1
jsdk 1.5.0_06-b05
xfire 1.2


 Description  « Hide
I got a NullPointerException when I was trying to generate the stub files from a WSDL file that includes several schemas.

The same wsdl and schemas work fine with axis.

The schema files should be correct as they come from the OTA specification.

I attached the files: wsdl, xsds and build.xml in the zip file.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Jose Manuel Valladares Pernas - 04/Sep/06 04:32 AM
The error is also showing up in the snapshot from 9/04/2006: xfire-distribution-1.2-20060904.050711-1

The stack trace of the exception is the following:

/home/jmanuel/src/SpecsOTA/build.xml:35: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
at org.codehaus.xfire.gen.WsGenTask.execute(WsGenTask.java:48)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1712)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:130)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:273)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.visit(WSDLServiceBuilder.java:351)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.build(WSDLServiceBuilder.java:180)
at org.codehaus.xfire.gen.Wsdl11Generator.generate(Wsdl11Generator.java:102)
at org.codehaus.xfire.gen.WsGenTask.execute(WsGenTask.java:44)
... 12 more
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1750)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:125)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 19 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1750)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:125)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 25 more
Caused by: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.handleSimpleType(SchemaBuilder.java:347)
at org.apache.ws.commons.schema.SchemaBuilder.handleSimpleType(SchemaBuilder.java:481)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:108)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 31 more
— Nested Exception —
java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1712)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:130)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:273)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.visit(WSDLServiceBuilder.java:351)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.build(WSDLServiceBuilder.java:180)
at org.codehaus.xfire.gen.Wsdl11Generator.generate(Wsdl11Generator.java:102)
at org.codehaus.xfire.gen.WsGenTask.execute(WsGenTask.java:44)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1750)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:125)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 19 more
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1750)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:125)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 25 more
Caused by: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.handleSimpleType(SchemaBuilder.java:347)
at org.apache.ws.commons.schema.SchemaBuilder.handleSimpleType(SchemaBuilder.java:481)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:108)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 31 more


Michael Vorburger - 04/Sep/06 07:00 AM
This (NPE in WsGenTask) happens to me occassionally too... Just FYI: in general with a "bad" WSDL XFire typically launches a NPE, and one (I) then need XML Spy and/or Eclipse WTP to try to find out what is wrong with it. There are probably be different things that can cause NPEs here...

For example, just today I got the following stacktrace under v1.1.2:

[Maven/Ant stuff ommited]
Caused by: java.lang.NullPointerException
at ch.visana.maven.anttasks.xfire.WsGenTask.execute(WsGenTask.java:73)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
... 19 more
Caused by: java.lang.NullPointerException
at org.codehaus.xfire.wsdl11.parser.WSDLServiceConfigurator.visit(WSDLServiceConfigurator.java:224)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceConfigurator.configure(WSDLServiceConfigurator.java:179)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.build(WSDLServiceBuilder.java:213)
at org.codehaus.xfire.gen.Wsdl11Generator.generate(Wsdl11Generator.java:91)
at ch.visana.maven.anttasks.xfire.WsGenTask.execute(WsGenTask.java:69)
... 23 more

Not a big issue, as we are usually able to move on, but as somebody filed an issue, I thought our observation may be of interest.


Michael Vorburger - 04/Sep/06 07:10 AM
Another one, if this is of interest, this happens with v1.1.2 is there is no wsdl:input in WSDL:

Caused by: java.lang.NullPointerException
at ch.visana.maven.anttasks.xfire.WsGenTask.execute(WsGenTask.java:73)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
... 19 more
Caused by: java.lang.NullPointerException
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.isWrapped(WSDLServiceBuilder.java:495)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.visit(WSDLServiceBuilder.java:376)
at org.codehaus.xfire.wsdl11.parser.WSDLServiceBuilder.build(WSDLServiceBuilder.java:187)
at org.codehaus.xfire.gen.Wsdl11Generator.generate(Wsdl11Generator.java:91)
at ch.visana.maven.anttasks.xfire.WsGenTask.execute(WsGenTask.java:69)
... 23 more


Michael Vorburger - 04/Sep/06 07:11 AM

Or maybe wsdl4j can actually do that?

Michael Vorburger - 04/Sep/06 07:14 AM
Idea: If the WSDL was validated against WSDL's (and also the schema's) XML schema, maybe that would catch some problems and show clearer errors? Or maybe wsdl4j can actually do that, or some other form of validation, already? – Just an idea how to make this area more "robust" - short of having to put lot's of if (abc=null) all over the WSDLServiceBuilder and in the (Apache not XFire!) SchemaBuilder.

Marc Gagnon - 06/Sep/06 09:47 AM
I observed the same issue with another toolkit (axis2).
Reference: http://marc.theaimsgroup.com/
(search for "xsd:include", message title "[Axis2] WSDL2Java does not handle xsd:include correctly")

I am willing to switch to xfire if this issue gets solved!
I agree on a previous comment: the issue lies in the Apache SchemaBuilder.

The problem is with the following construct found in the OTA file "OTA_SimpleTypes.xsd":
...
<xs:simpleType name="PaymentCardCodeType">
<xs:annotation>
<xs:documentation xml:lang="en">The 2 digit code used that references the credit card used.</xs:documentation>
</xs:annotation>
<xs:union>
<xs:simpleType>
<xs:restriction base="UpperCaseAlphaLength1to2">
..

The base mentioned above is defined a few lines later in the same file:
...
<xs:simpleType name="UpperCaseAlphaLength1to2">
...

Note that the shema does not use a fully qualified name --> base="UpperCase..".

In most other restriction base types of the same file, a fully qualified name is used:
...
<xs:simpleType name="TransactionActionType">
<xs:annotation>
<xs:documentation xml:lang="en">To specify the type of action requested when more than one function could be handled by the message.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="Book"/>
...

In this case, base="xs:string".

Looking at the code where the NPE happens, we see that a fully qualified name is mandatory:
Look at class SchemaBuilder, method handleSimpleType:
...
XmlSchemaSimpleType handleSimpleType(XmlSchema schema,
Element simpleEl, Element schemaEl) {
...
if (restrictionEl.hasAttribute("base")) {
String name = restrictionEl.getAttribute("base");
String[] temp = Tokenizer.tokenize(name, ":");
String namespace = "";

if (temp.length != 1) { namespace = temp[0]; }

//let it crash because its mean being refered
//to unregistered namespace
namespace = schema.namespaces.get(namespace).toString();
name = Tokenizer.lastToken(name, ":")[1];
restriction.baseTypeName = new QName(namespace, name);
//simpleType.name = name;
} else if (inlineSimpleType != null) {
...

The comment in this code clearly states that a fully qualified name is required when defining a restriction base type definition for a simple type.

Now, what is the good behavior in this situation?

To summarize, from a WSDL definition using OTA shema, we have a xsd:include of a message like "OTA_HotelAvailRQ.xsd". This message includes basic types like "OTA_SimpleTypes.xsd" which defines UpperCaseAlphaLength1to2 which is used as a base to define "PaymentCardCodeType".

We need to follow the namespace definitions closely in this scenario in order to understand what the code should have done instead of the NPE. Our understanding must also be valid agains the W3C specification...

Let's start with the WSDL (I'm using the files.ZIP attachement):
In types, we find:
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:client="http://xmlns.oracle.com/OTA_HotelAvail" xmlns:ns1="http://www.opentravel.org/OTA/2003/05" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<import namespace="http://www.opentravel.org/OTA/2003/05" schemaLocation="xsd/OTA_HotelAvailRQ.xsd"/>
</schema>

The default namespace is therefore "http://www.opentravel.org/OTA/2003/05"
The import declares the same namespace.

Now, in file OTA_HotelAvailRQ.xsd:

<xs:schema xmlns="http://www.opentravel.org/OTA/2003/05" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.opentravel.org/OTA/2003/05" elementFormDefault="qualified" version="1.005" id="OTA2006A">
...
<xs:include schemaLocation="OTA_SimpleTypes.xsd"/>

Again, the default namespace is "http://www.opentravel.org/OTA/2003/05", this is also the target namespace.

Finally, look at the OTA_SimpleTypes.xsd file:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="2.002" id="OTA2003A2006A">

Here, only the xs namespace is defined for internal references like xs:string.

The real question is: Which namespaces should be known and valid when dealing with this inclusion coming from OTA_HotelAvailRQ?

In the OTA messages, the high level messages use the targetNamespace to set the namespace.

By design, all more primitive types are in separated schemas which are
included and they do not define a namespace.
This is a documented OTA practice: see OTA 2006A, "XML Schema Design
Best Practices"version 3.04 June 2006,page 15,
section 4.6.2 "No namespace for common XML schema files". The rationale
states that the messages which includes simple types
will 'coerce' the content in the RQ or RS schema.

This looks fine and seems logical.

Also, the W3C specification documents this practice. Specifically, the
document "XML Schema part 1: Structures" (W3C Recommendation 2 May 201)
says the following in section 4.2.1:
=====
...
A <schema> information item may contain any number of <include>
elements. Their schemaLocation attributes, consisting of a URI
reference, identify other - schema

documents- , that is <schema> information items.

The - XML Schema- corresponding to <schema> contains not only the
components corresponding to its definition and declaration [children],
but also all the components

of all the - XML Schemas- corresponding to any <include>d schema
documents. Such included schema documents must either (a) have the same
targetNamespace as the

<include>ing schema document, or (b) no targetNamespace at all, in
which case the <include>d schema document is converted to the
<include>ing schema document's

targetNamespace.
...
=====

The included schema will be in the OTA's RQ or RS namespace according
to the W3C recommendation AND the OTA's best practice guide.

What is the next step?
The XmlShema is located at http://ws.apache.org/commons/XmlSchema/index.html
So, we should confirm all of the above, and then contact the XmlSchema team.

What do you think?


Marc Gagnon - 07/Sep/06 03:53 PM
I've been able to reproduce the issue in XmlSchema independently of xfire (see attached files).

To reproduce, get XmlSchema (I used 1.0.3, same behavior as 1.0.1) and unzip IncludeTest.java in the tests directory, unzip the xsd files in test-resources and run the unit tests.

One test case is ok: the one which defines a default namespace in the included file.
The other test case fails because there is no default namespace defined, just like in OTA_SimpleTypes.xsd

So, this is clearly an issue for the XmlSchema team, so why write this here in this log? I would like that the current owner of this log reproduces the issue like I did to confirm the conclusion so far. Then, we'll (I?) open the log on XmlSchema's jira.

Sample xsd from the attachement:

<schema targetNamespace="http://soapinterop.org/xsd"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsd1="http://soapinterop.org/xsd"
xmlns:xsd2="http://soapinterop.org/xsd2"
elementFormDefault="qualified">
<include schemaLocation="includeAux.xsd"/>
</schema>

includeAux=
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsd1="http://soapinterop.org/xsd2"
elementFormDefault="qualified">

<xs:simpleType name="PaymentCardCodeType">
<xs:union>
<xs:simpleType>
<xs:restriction base="UpperCaseAlphaLength1to2"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>

<xs:simpleType name="UpperCaseAlphaLength1to2">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z]{1,2}"/>
</xs:restriction>
</xs:simpleType>

</schema>

This example is ok, remove line <<xmlns="http://www.w3.org/2001/XMLSchema">> in the file above and it will fail. It seems to me that this declaration should be considered implicit and this should be handled in ShemaBuilder.handleSimpleType


Jose Manuel Valladares Pernas - 08/Sep/06 04:58 AM
I run the tests that you sent and you are perfectly right.

The one with default namespace works fine and the one without namespace returns a NullPointerException.
I run the tests using XMLSchema version 1.0.3.

The output is:
testSchemaIncludeNoDefaultNS(tests.IncludeTest)java.lang.RuntimeException: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1926)
at org.apache.ws.commons.schema.SchemaBuilder.handleInclude(SchemaBuilder.java:1750)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:125)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at tests.IncludeTest.testSchemaIncludeNoDefaultNS(IncludeTest.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Caused by: java.lang.NullPointerException
at org.apache.ws.commons.schema.SchemaBuilder.handleSimpleType(SchemaBuilder.java:347)
at org.apache.ws.commons.schema.SchemaBuilder.handleSimpleType(SchemaBuilder.java:481)
at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:108)
at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:52)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:268)
at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:230)
at org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1924)
... 20 more

It is clear then that the problem is in XMLSchema.
If you could open the JIRA issue in XmlSchema I would appreciate it.

Thank you very much to all the people that helped.


Marc Gagnon - 08/Sep/06 08:47 AM
Thank you for confirming the issue.
I created the entry in XmlSchema's Jira:
http://issues.apache.org/jira/browse/WSCOMMONS-87

Dan Diephouse - 08/Sep/06 08:54 AM
Thanks! I will try to get this fixed in the xml schema project.

Marc Gagnon - 08/Sep/06 09:02 AM
Hum, I should had a closer look at the existing issues:
http://issues.apache.org/jira/browse/WSCOMMONS-78
Is about the same issue and seems fixed.

Dan Diephouse - 11/Sep/06 04:58 PM
There is an XmlSchema build here that you can use until the next XmlSchema release (in a couple days):

http://people.apache.org/repository/org.apache.ws.commons/jars/XmlSchema-SNAPSHOT.jar

Closing this issue as it seems to be fixed now. Thanks.