https://bz.apache.org/bugzilla/show_bug.cgi?id=68972
Bug ID: 68972
Summary: Prevent the web application's ClassLoader from being
pinned by the JSP compiler if an application uses a
custom XMLInputFactory.
Product: Tomcat 9
Version: 9.0.88
Hardware: PC
OS: All
Status: NEW
Severity: regression
Priority: P2
Component: Jasper
Assignee: dev@tomcat.apache.org
Reporter: ranjit.vadak...@gmail.com
Target Milestone: -----
Please see
https://github.com/apache/tomcat/commit/3b8f277a7ffc1193ed6c6d4fff85db6dc7327e39
for the specific change, which was built on top of
https://github.com/apache/tomcat/commit/a2167e13c19115aecd220cd3be19d43d36126f3b
This change is causing us major grief.
Our application -
1. programmatically sets "com.ctc.wstx.stax.WstxInputFactory" as the value of
the system property "javax.xml.stream.XMLInputFactory" on startup
2. is packaged as a WAR file with "woodstox-core" and "stax2-api" included in
the WAR/WEB-INF/lib
Up until 9.0.87, JSPs rendered without errors. Starting with 9.0.88, we get
this -
Caused by: java.lang.ExceptionInInitializerError: Exception
javax.xml.stream.FactoryConfigurationError: Provider
com.ctc.wstx.stax.WstxInputFactory not found [in thread "http-nio-8080-exec-7"]
at java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:184)
at java.xml/javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:135)
at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:248)
at java.xml/javax.xml.stream.FactoryFinder.find(FactoryFinder.java:210)
at
java.xml/javax.xml.stream.XMLInputFactory.newFactory(XMLInputFactory.java:185)
at
org.apache.jasper.compiler.EncodingDetector.<clinit>(EncodingDetector.java:41)
The problem is on line 40 (of
https://github.com/apache/tomcat/commit/3b8f277a7ffc1193ed6c6d4fff85db6dc7327e39)
where the context class loader is set to that of Tomcat.
According to
https://docs.oracle.com/en/java/javase/17/docs/api/java.xml/module-summary.html#LookupMechanism,
line 41 will now look for com.ctc.wstx.stax.WstxInputFactory in Tomcat's
context (because of the system property being set) and won't find it. Because
we (like most others) lazy load JSPs, by the time the EncodingDetector is
clinit-ed, it's too late because the system property has already been set.
A possible solution is to initialize the EncodingDetector class before any
applications are deployed so that it will find the default input factory
"com.sun.xml.internal.stream.XMLInputFactoryImpl"
The workaround is simple, but extremely inconvenient - we need to place the 2
jars - "woodstox-core" and "stax2-api" - in Tomcat/lib.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
