Possible classpath scanning issues by using XPathFactory.newInstance() #86
Labels
Comments
dfranssen
pushed a commit
to dfranssen/dxa-web-application-java
that referenced
this issue
Dec 8, 2017
rpannekoek
pushed a commit
that referenced
this issue
Feb 2, 2018
…022 to develop * commit 'cbf5a71ee694931dad050529ebae1ec4ff17b198': TSI-3022 Replaced UnknownCMD class with a simple String content holder (TSI-3010)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In pre 2.0 releases the dxa-tridion-provider is using
XPathFactory.newInstance()in theXPathResolverenum to create anXPathExpression.By using that
XPathFactory.newInstance()a suitabable factory implementation will be found by scanning the classpath (cfr javadoc). This means that the classloading order could be different between restarts of Tomcat. Documentation of Tomcat 8 states that the order of loading is not anymore by alphabetical order as in previous versions but by order of which classes are requested first. This could lead to nullpointer exceptions when e.g.jstl-1.2.jaris on the classpath and has been loaded first. This is due toorg.apache.taglibs.standard.tag.common.xml.JSTLXPathFactorybeing used as factory for whichxpath.compile(sourceString)will always return null.Furthermore the usage of
ThreadLocalseems overhead as recreating theXPathExpressioneach time has no performance impact.The text was updated successfully, but these errors were encountered: