On Mon, 12 Aug 2002, Jean-francois Arcand wrote: > > I think that the dependency on Xerces 2.0.1 is excessively restrictive > > as well. IIRC (maybe Jean-François could provide some of the details > > he found?), Xerces 2.0.1 was the only Xerces parser that we have found > > so far that does not throw StackOverflow or other fatal exceptions > > when an XML file using XML schema is parsed. I believe (Jean-François: > > let me know if my understanding is incorrect) that this problem exists > > even if schema validation is turned off. > > The StackOverflowException _only_ occurs with released version of Xerces > 2.0.2. It has been fixed since the release (nightly build works fine). > Yes the problem exist even if the schema validation is on.
I only tested crimson - it fails if validation is on, but works fine and faster if validation is disabled. > >> And having schema validation turned on by default has a strong -1 from > >> me - if the spec _requires_ schema validation, then implement it at > >> deployment time. The performance hit is just unacceptable. > > > > > > Any performance increases through delayed validation sounds good to me. > > I agree. What behaviour do we want if a xml instance is not well-formed? Again - this is not 'delayed' validation, the validation and initalization will allways happen before the first request is served, and if an error is found the context will be disabled. There are 2 distinct issues: One is moving the 'validation' to a deploy stage. If validation fails, the app will not be deployed. The second issue is doing the context initialization in background and in parallel. That has nothing to do with validation. If we don't implement the 'deploy' - we can validate the XML file once ( during startup ), and keep a timestamp to avoid future re-validation. But the behavior remains the same - the app will not be started. Costin > > > > > > >> > >> ( in the process we should also move DTD validation to the same stage > >> and stop doing it on every startup if the xml file didn't change ) > >> > > > > Makes sense. Especially since we use this same technique for JSP page > > compilation. > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
