In my previous entry, I tried to explain why Xerces and Xalan are so complicated. In this entry I want to focus in System.setProperty. Because, as I said that is the usual solution you are going to find when you need a specific parser for whatever reason.
And that solution is wrong. Very wrong.
Because, if you choose to change the provider using System.setProperty, you are changing the provider for all the applications in the container/server. It doesn’t matter that you change it, then instantiate, and then change to the original value. Because, when you’re running in an application server, there are some chances of additional threads needing to instantiate and getting a different provider of the one they are trying to get. In fact, that same problem was reported to my group a couple of weeks ago. We tend to give support to applications that use our framework. And, as I say, we received a strange error. Sometimes one report was generated OK, and sometimes it failed with some exception (don’t remember off hand). Same query, same data. Fortunately, the stacktrace came with some reference to xerces. Quick search and discovered the report failed when a different report changed the Property for DocumentBuilderFactory to an old sun implementation. What was even better: the old implementation seemed to be not particularly needed. Looked like a copy&paste.
I guess you’ll be asking yourself what to do if you can’t use System.setProperty. Too late for this blog post. Wait for the next.
EDIT: Stack trace
First published here