[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xerces-j-user
Subject:    Re: Input Stream in Input Source not closed
From:       Micah Koch <mkoch () motive ! com>
Date:       2010-01-14 14:51:54
Message-ID: 32B5CF90-855B-4692-9CBB-FDBEA578F1BD () motive ! com
[Download RAW message or body]

From the application perspective it seems kinda burdensome to have to know that for \
some particular input source that the parser isn't going to close the resources \
associated with it, but for most others it is.  If you look at the javadoc for \
InputSource it says: "An InputSource object belongs to the application: the SAX \
parser shall never modify it in any way (it may modify a copy if necessary). However, \
standard processing of both byte and character streams is to close them on as part of \
end-of-parse cleanup, so applications should not attempt to re-use such streams after \
they have been handed to a parser."

I think even if Xerces isn't going to read from an inputsource it should call close \
on the byte/character streams in it, as that's what an application expects.  An \
application can of course work around this via one means or another once they \
discover the problem, but its certainly unexpected behavior.  I believe internal \
implementation details such has the way Xerces is handling the duplicate include \
shouldn't have unexpected side effects that the application has to handle. Micah

On Jan 13, 2010, at 10:49 PM, Michael Glavassevich wrote:

> There's nothing wrong with this schema.
> 
> Xerces will determine that both includes for "c.xsd" point to the same URI and only \
> load and process the schema document once. The comparison of the URIs is done after \
> any redirection from an entity resolver which could choose to map the two includes \
> of "c.xsd" to different URIs. This is why the resolver gets called twice. 
> The InputSource returned by the entity resolver for the second include of "c.xsd" \
> is ignored if it has the same system ID (URI) as the one returned for the first \
> include of "c.xsd". An InputStream attached to the second InputSource would never \
> be accessed (i.e Xerces doesn't call any methods on it including close()). If it's \
> important that these streams (that are never read) be closed the application is \
> able to manage that itself. 
> Thanks.
> 
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
> 
> Mukul Gandhi <mukulg@apache.org> wrote on 01/13/2010 10:34:46 PM:
> 
> > On Tue, Jan 12, 2010 at 4:03 AM, Micah Koch <mkoch@motive.com> wrote:
> > > So I have a few questions, and one way or another there seems to 
> > be a bug.  I have a schema where
> > > a.xsd includes b.xsd and c.xsd
> > > b.xsd includes c.xsd
> > > 
> > > 1) c.xsd gets included twice, is this allowed?
> > 
> > I did a quick test of this with Xerces-J. Here are the details of my test:
> > 
> > a.xsd
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> > 
> > <xs:include schemaLocation="b.xsd" />
> > <xs:include schemaLocation="c.xsd" />
> > 
> > <xs:complexType name="A">
> > <xs:sequence>
> > <xs:element name="z" type="xs:string" />
> > </xs:sequence>
> > </xs:complexType>
> > 
> > <xs:element name="x" type="A" />
> > 
> > </xs:schema>
> > 
> > b.xsd
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> > 
> > <xs:include schemaLocation="c.xsd" />
> > 
> > <xs:complexType name="B">
> > <xs:sequence>
> > <xs:element name="y" type="xs:string" />
> > </xs:sequence>
> > </xs:complexType>
> > 
> > </xs:schema>
> > 
> > c.xsd
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
> > 
> > <xs:complexType name="C">
> > <xs:sequence>
> > <xs:element name="x" type="xs:string" />
> > </xs:sequence>
> > </xs:complexType>
> > 
> > </xs:schema>
> > 
> > a.xml
> > <x>
> > <z>hello</z>
> > </x>
> > 
> > When I validated, a.xml with a.xsd, the validation passes and Xerces
> > doesn't report an error.
> > 
> > So the use case you pointed, seems to be allowed by Xerces-J (and I
> > believe, also by XSD language).
> > 
> > But as I wrote earlier, this kind of schema inclusions doesn't look a
> > good design, as we are including a schema twice. Only once schema
> > inclusion should be sufficient, to get the required schema components
> > into the parent schema.
> > 
> > 
> > 
> > -- 
> > Regards,
> > Mukul Gandhi
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-users-help@xerces.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]