XML Parsers: Part 3

I have made a case to use stream-based parsers.  There are occasions where I will use XPath instead, however.  Sometimes, performance isn't an issue.  Sometimes, it is better to have user friendly and maintainable code instead of fast running code.  For example, we had a problem with web.xml's that were provided by the developers.  We would deploy the war/web.xml to Tomcat and Websphere.  If there was a problem with the web.xml, Tomcat and Websphere would blow up and different but spectacular ways.  They often didn't give good error messages.  Tomcat would give NullPointerExceptions for a lot of these errors.  Websphere would give JNDI lookup errors (since the JNDI system didn't initialize due to a webapp startup failure).

That is when I decided to perform some deploy time web.xml validation.  The better time to do this validation was at build time, but I didn't control the build processes.  There were multiple processes as well.  It was much easier to validate at deploy time.  Now, I don't know the web.xml spec like the back of my hand.  I only know the problems that we have been hit with.  We would run into problems like filter mappings without filters, filters without filter mappings and duplicate servlet names.

The solution I came up with is an XPath-based parser that was exposed as a Javascript/Rhino api.  Then, I could write a batch JavaScript script that would parse the web.xml and search for known problems.  If a known problem is detected, then the war/ear deployment should fail.  One key thing to remember when designing a solution like this is the discovery of new problems.  This solution won't catch all web.xml errors.  It was easily modifiable in the event that a new problem pattern was discovered, however.  Not only that, almost anyone could make the change.  It didn't require a complicated development cycle to update the problem detector.  In this scenario, we were concerned with parsing a single web.xml at deploy time.  If the web.xml had a lot of entries, the detector would run slower, but so would the web app.  At that point, the developers would have more problems to worry about (a slow running app, vs a slow deploying app).