We're updating the issue view to help you get more done. 

Use an "upgrade" approach to validate and bind (JAXB) mapping XML

Description

was kind enough to outline the basic steps needed:

So the general idea is to use StAX to read the first element of the XML file, determine the version of the file from that element and then act on it appropriately. We had this PortalDataKey concept that we would parse out of each XML file. From that we'd first go look in a Map<PortalDataKey, DataUpgrader> to see if there was a registered DataUpgrader implementation for that version of the XML file. If there was we would run it on the XML file then repeat the parsing of the first element and looking for another DataUpgrader. Once we didn't find a DataUpgrader we'd look up the DataImporter that was mapped to the PortalDataKey for the current version of the XML and run it on the contents.

This is a much more generalized solution as it is was designed to batch parse, update and import potentially millions of XML files across 20+ different schemes from 4+ versions.

What the process breaks down to is:

  • Parse the first bit of the XML document using StAX. StAX is used here as it only reads as much of the XML file as you request and can easily have validation disabled which you want for the first step.

    • Set up the Woodstox StAX parser for reading the first element: PortalDataKeyFileProcessor.java#L63

    • Read the first element and parse the type and version information from it: PortalDataKeyFileProcessor.java#L104

    • This code uses a bunch of custom StAX utility code that exists in org.jasig.portal.xml primarily to try and avoid ever reading from a file more than absolutely necessary. Not sure you'll need all of this extra logic since you're not parsing thousands or millions of files. You can simply re-create the StAX stream which is much simpler.

  • Update the XML if needed

  • You now have the XML in the most recent format and do whatever validation you would do on it otherwise.

The thing we got a lot of mileage from this process is that as you make changes to the XML file format you only ever have to worry about creating an XSLT to go from the most recent released XML format to the new XML format. It is also easy to write unit tests as weird cases come along to verify the XSLT for each version change is handling things correctly.

Some of this we already have in place, like the move to StAX and peeking at the version.

Environment

None

Status

Assignee

Steve Ebersole

Reporter

Steve Ebersole

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major