Well, you could submit it as a patch if you're willing to fetch a tree.
On Fri, Mar 26, 2010 at 5:37 AM, J. Aparicio <juanjo.apari...@techideas.es> wrote: > > > bimargulies wrote: >> >> Looks like the doctype adds one more event/node to the picture, and >> something trips over it. >> >> On Thu, Mar 25, 2010 at 2:46 PM, Daniel Kulp <dk...@apache.org> wrote: >>> On Thursday 25 March 2010 10:02:07 am J. Aparicio wrote: >>>> OK, found out what the problem was. >>>> >>>> The xsd in question includes a DOCTYPE declaration. Of all the involved >>>> wsdl and xsd documents in the app, it's the only one with a DOCTYPE >>>> declaration. Taking it out of the document allowed CXF to return the >>>> xsd. >>> >>> Well, that's interesting. Unexpected, but interesting. >>> >>> >>>> Now, my question (which doesn't belong to cxf anymore) is whether that >>>> DOCTYPE declaration should be there at all, or if the standard xsd was >>>> revised at some point and the DOCTYPE declaration taken out. The latest >>>> version I've been able to find lies at >>>> http://www.w3.org/2005/08/addressing/ws-addr.xsd, and DOESN'T have a >>>> DOCTYPE declaration. >>>> >>>> On the CXF-related side, is it legal for StaxUtils to choke on such a >>>> node >>>> type? Can't it just ignore it? >>> >>> I would have also expected it to just ignore it. Not sure why it >>> wouldn't be. >>> Is there any way you could create a small testcase that shows it throwing >>> the >>> exception? That would make it easier to debug it. I'm really not >>> sure how >>> a DOCTYPE would cause this. Very bizzarre. >>> >> > > Actually class org.apache.cxf.staxutils.StaxUtils, function "public static > void writeNode(Node n, XMLStreamWriter writer, boolean repairing) throws > XMLStreamException" contains a big "switch(n.getNodeType()) {", > Node.DOCUMENT_TYPE_NODE is processed by the default case, which throws an > IllegalStateException. > > So taking away the DOCTYPE declaration (definition?) from the xsd document > avoids StaxUtils blind spot. IIRC, xmlschemas are favored over dtd, but dtds > are still legal, so the longer term solution would be to include an > additional case to that function in StaxUtils, something like: > > <code> > case Node.DOCUMENT_TYPE_NODE: > writer.writeDTD(((DocumentType)n).getTextContent()); > break; > </code> > > Just a suggestion, I've not even checked that the above compiles. > > > -- > View this message in context: > http://old.nabble.com/Relative-paths-in-xsd%3Aimport-tp28018462p28040040.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
