cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J. Aparicio" <juanjo.apari...@techideas.es>
Subject Re: Relative paths in xsd:import - Partial solution
Date Tue, 30 Mar 2010 09:49:59 GMT

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.


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
> <juanjo.aparicio@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 <dkulp@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.
>>
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/Relative-paths-in-xsd%3Aimport-tp28018462p28080192.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message