The topic of how to validate the XML parsers or the schemas crops up every now and again. I have been having a couple of ideas of how we could at some point look into this: - http://community.jboss.org/docs/DOC-17243 The proposed idea actually covers two parts: - - A wrapper around the existing API that allows the parsers to just request the elements / attributes they require and leave the wrapper to handle all the error handling we currently have distributed across the parsers. - This then allows us during testing to validate that the calls match the structure defined in the schema. I may try prototyping something other the weekend but thought I would put this out there and see if anyone has any thoughts / comments. Regards, Darran Lofthouse.

I am not talking about validation of XML documents here, I am talking about validation of the parser implementations with AS7. Regards, Darran Lofthouse. On 09/27/2011 07:03 PM, Anil Saldhana wrote: > IMO schema validation is needed when: > a) users want to enable it to debug an issue. > b) testsuite needs to validate schemas. > > In both these instances, the Jaxp Validation API is sufficient if the > schema files are known. Would it be useful to just enable jaxp > validation (on demand) before the subsystem parsing kicks in? > > On 09/27/2011 11:42 AM, Darran Lofthouse wrote: >> The topic of how to validate the XML parsers or the schemas crops up >> every now and again. >> >> I have been having a couple of ideas of how we could at some point look >> into this: - >> >> http://community.jboss.org/docs/DOC-17243 >> >> The proposed idea actually covers two parts: - >> - A wrapper around the existing API that allows the parsers to just >> request the elements / attributes they require and leave the wrapper to >> handle all the error handling we currently have distributed across the >> parsers. >> >> - This then allows us during testing to validate that the calls match >> the structure defined in the schema. >> >> I may try prototyping something other the weekend but thought I would >> put this out there and see if anyone has any thoughts / comments. >> >> Regards, >> Darran Lofthouse.

On 9/27/11 11:42 AM, Darran Lofthouse wrote: > The topic of how to validate the XML parsers or the schemas crops up > every now and again. > > I have been having a couple of ideas of how we could at some point look > into this: - > > http://community.jboss.org/docs/DOC-17243 > > The proposed idea actually covers two parts: - > - A wrapper around the existing API that allows the parsers to just > request the elements / attributes they require and leave the wrapper to > handle all the error handling we currently have distributed across the > parsers. > > - This then allows us during testing to validate that the calls match > the structure defined in the schema. > > I may try prototyping something other the weekend but thought I would > put this out there and see if anyone has any thoughts / comments. Hmm while I like the idea of better error reporting, I worry that the mechanism to test schema correctness is going to be very involved. Are you sure it's not easier to just write a few test cases for each parser?

Can this be done without *requiring* changes to subsystems? ExtensionParsingContext.setSubsystemXmlMapping(String namespaceUri, XMLElementReader<List<ModelNode>> reader) is a stable API that we cannot break. A new method could be added to register a parser that requires a ValidatingXmlReader to be passed in, but we can't force subsystems to change their impl's public void readElement(final XMLExtendedStreamReader reader, final List<ModelNode> list) throws XMLStreamException to public void readElement(final ValidatingXmlReader reader, final List<ModelNode> list) throws XMLStreamException On 9/27/11 11:42 AM, Darran Lofthouse wrote: > The topic of how to validate the XML parsers or the schemas crops up > every now and again. > > I have been having a couple of ideas of how we could at some point look > into this: - > > http://community.jboss.org/docs/DOC-17243 > > The proposed idea actually covers two parts: - > - A wrapper around the existing API that allows the parsers to just > request the elements / attributes they require and leave the wrapper to > handle all the error handling we currently have distributed across the > parsers. > > - This then allows us during testing to validate that the calls match > the structure defined in the schema. > > I may try prototyping something other the weekend but thought I would > put this out there and see if anyone has any thoughts / comments. > > Regards, > Darran Lofthouse. > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I don't think that generic validation in the parser is going to work. We've been down this road before. Ultimately the *best* solution is going to be a code generator for the parsers - sort of like JAXB but streaming-friendly instead of mapping to object graphs - so that all the validation and parsing logic is factored out (the generated implementation will be optimal so that human error becomes impossible) and the manually-written code can focus on the logic of mapping the XML data to the target model instead of being 80% validation like today. As it is today, you can write element parser methods following a definite formula, so this isn't too lofty of a goal in my opinion. It's just a post-7.1 goal, that's all. On 09/27/2011 02:05 PM, Darran Lofthouse wrote: > Yes, at the moment the way I am thinking about this nothing would be > *required* to change - the ValidatingXmlReader would just be wrapping > the XMLExtendedStreamReader and the underlying calls to the > XMLExtendedStreamReader would remain the same so everything can continue > using the XMLExtendedStreamReader until ready. > > I think I would probably actually recommend not pro-actively making a > switch but instead for subsystems / domain parsers to switch at the time > the schema version is bumped. > > To begin with if we wanted to to try something out we could even > maintain the exact registration / calls we have today and just > instantiate the ValidatingXmlReader on the first line of a readElement > call to wrap the passed in reader. e.g. As a first step it could be > introduced for host.xml reading alone. > > Regards, > Darran Lofthouse. > > > > On 09/27/2011 07:38 PM, Brian Stansberry wrote: >> Can this be done without *requiring* changes to subsystems? >> >> ExtensionParsingContext.setSubsystemXmlMapping(String namespaceUri, >> XMLElementReader<List<ModelNode>> reader) is a stable API that we cannot >> break. >> >> A new method could be added to register a parser that requires a >> ValidatingXmlReader to be passed in, but we can't force subsystems to >> change their impl's >> >> public void readElement(final XMLExtendedStreamReader reader, final >> List<ModelNode> list) throws XMLStreamException >> >> to >> >> public void readElement(final ValidatingXmlReader reader, final >> List<ModelNode> list) throws XMLStreamException >> >> On 9/27/11 11:42 AM, Darran Lofthouse wrote: >>> The topic of how to validate the XML parsers or the schemas crops up >>> every now and again. >>> >>> I have been having a couple of ideas of how we could at some point look >>> into this: - >>> >>> http://community.jboss.org/docs/DOC-17243 >>> >>> The proposed idea actually covers two parts: - >>> - A wrapper around the existing API that allows the parsers to just >>> request the elements / attributes they require and leave the wrapper to >>> handle all the error handling we currently have distributed across the >>> parsers. >>> >>> - This then allows us during testing to validate that the calls match >>> the structure defined in the schema. >>> >>> I may try prototyping something other the weekend but thought I would >>> put this out there and see if anyone has any thoughts / comments. >>> >>> Regards, >>> Darran Lofthouse. >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev