[jboss-as7-dev] Validation of XML Parsers / Schemas

David M. Lloyd david.lloyd at redhat.com
Tue Sep 27 15:10:34 EDT 2011


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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
- DML


More information about the jboss-as7-dev mailing list