On Tuesday 30 March 2010 5:49:59 am J. Aparicio wrote: > Fetched a tree. 2.2.5 tag, actually. > Weird, I added a test case that reads a document with a doctype > declaration, and the parser just ignores it. So the writeDocument never > sees it, so it doesn't choke. > Somewhere else the document is being read, the doctype declaration is not > dropped, and when StaxUtils tries to spit the xsd out it chokes on the > unexpected doctype declaration. > I'll have to look further into this.
I added some code to StaxUtils that MIGHT work. Can you try the latest snapshots? I expect the Doctype to not get written out, but it at least might not bomb out. I'm not sure if the failure was when writing to a DOM or an actual stream. If an actual stream, it MIGHT work, to DOM, it won't as there isn't a standard way to create a DocType node in the DOM. Dan > > bimargulies wrote: > > 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 > > > > <[email protected]> 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 <[email protected]> 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. -- Daniel Kulp [email protected] http://dankulp.com/blog
