find . -name *.jar | xargs -L 1 unzip -l | grep "services/org.xml" inside my jdk/jre installation seems to indicate the JDK itself does not use the SPI mechanism, which is further backed by the default implementation in XMLReaderFactory being hardcoded.
Setting the system property to null forces the default implementation on sun java, but is not thread safe. Looking for a list of parsers or maintaining a map of jdk->parser mapping seems like the best option, unless there is something nice we can shade in. I'm not sure if shading in something like xerces just sets sets org.xml.sax.driver to point at the shaded version (being lazy, could find out ;) If we did shade in something I'm thinking we'd use "new" instead of XMLReaderFactory, since it's all private stuff anyway. Hopefully this would not disturb anyone's environment....(?) Kristian 2013/1/13 Benson Margulies <bimargul...@gmail.com>: > Well, you could scan for the JRE's builtin SPI file and pass the class > name you acquire to > http://docs.oracle.com/javase/6/docs/api/org/xml/sax/helpers/XMLReaderFactory.html. > > It is rather annoying that these classes don't let you say 'give me > the stock JRE method, ignore the system property'. > > Or you could write down a list consisting of the class name used in > the Oracle JRE and the class name used in the IBM JDK, and try them in > order. > > > On Sun, Jan 13, 2013 at 2:09 PM, Kristian Rosenvold > <kristian.rosenv...@gmail.com> wrote: >> We switched to SAX parsing in m-s-u, and we just had an interesting >> issue (https://jira.codehaus.org/browse/SUREFIRE-950) >> which basically happens because some plugin sets org.xml.sax.driver to >> point to a variable that is only present in that plugins classloader, >> when m-s-u later tries to instantiate a sax parser it blows up. >> >> This happens because the standard instantiation algorithm in >> org.xml.sax.helpers.XMLReaderFactory.createXMLReader() is >> not good enough for us. To my knowledge there is no standard way to >> determine what implementation is in use for different JDK's, >> so the best option is probably to shade in a nice small version of a >> sax parser from somewhere. >> >> I tried shading in xerces, which works nicely, but is hardly "small". >> Anyone have any other suggestions ? >> >> Kristian >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
