Piotr Karwasz created AXIOM-530:
-----------------------------------
Summary: Detect the StAX dialect from factory properties instead
of the factory class
Key: AXIOM-530
URL: https://issues.apache.org/jira/browse/AXIOM-530
Project: Axiom
Issue Type: Improvement
Components: API
Affects Versions: 2.0.0, 1.4.0
Reporter: Piotr Karwasz
Apache Commons has released [Commons Secure
XML|https://commons.apache.org/proper/commons-secure-xml/] 1.0.0, which
provides secure-by-default JAXP factories. For StAX, {{SecureXMLInputFactory}}
returns a wrapper around the platform's {{XMLInputFactory}} that installs a
non-removable entity resolution floor and delegates everything else (including
{{isPropertySupported}} and {{{}getProperty{}}}) to the wrapped factory.
This library is currently unusable by Axis2 users, because Axiom identifies the
StAX implementation from the {*}class of the factory instance{*}:
{{StAXDialectDetector}} locates the JAR (or {{jrt:}} module) that the factory
class was loaded from and inspects its manifest and the classes next to it. For
a wrapped factory the class is the wrapper's class, which says nothing about
the implementation behind it. The detector therefore logs
{noformat}
WARN StAXDialectDetector - Unable to determine dialect of the StAX
implementation at jar:file:/.../commons-secure-xml-1.0.0.jar!/
{noformat}
and falls back to {{{}UnknownStAXDialect{}}}, which drops the
implementation-specific normalization Axiom relies on (DTD information via
{{{}DTDReader{}}}, CDATA reporting, prolog whitespace, thread safety
configuration, ...).
This is not a new class of problem. The same symptom has been reported for
every situation where the factory class doesn't live next to the implementation
or the manifest is not the one the detector expects:
* AXIOM-426: JBoss AS 7 wraps factories in
{{{}__redirected.__XMLInputFactory{}}}. Fixed by adding
{{{}JBossFactoryUnwrapper{}}}, which uses reflection on a private field of a
JBoss internal class. JBoss Modules 2.x no longer ships these classes, so the
code is now dead.
* AXIOM-443: IBM JRE 1.7 ships {{com.sun.xml.internal.stream}} facade classes
in front of XLXP, so XLXP was mis-detected as SJSXP. Fixed by inspecting the
superclass.
* AXIOM-503: Woodstox 6 was not recognized because the manifest parser only
knew major versions 3 to 5.
* AXIOM-505 (open): a {{jar-with-dependencies}} build merges manifests, so
Woodstox is not recognized.
Rather than adding one more ad-hoc unwrapping rule for Commons Secure XML, the
detector should rely on something that does *not* depend on the factory class
at all.
h3. Proposal
Query the factory itself before falling back to the existing location-based
detection. All actively maintained implementations can be identified through
properties, and factory wrappers pass property queries through to the wrapped
factory:
* {{org.codehaus.stax2.implName}}
({{{}XMLStreamProperties.XSP_IMPLEMENTATION_NAME{}}} of the StAX2 API) is
read-only and supported by Woodstox 4 and later ({{{}"woodstox"{}}}) and by
Aalto ({{{}"aalto"{}}}).
* {{[http://java.sun.com/xml/stream/properties/implementation-name]}} is the
equivalent introduced by SJSXP ({{{}"sjsxp"{}}}) and also supported by Woodstox
and Aalto as an alias.
* The implementation shipped with the JRE (the descendant of SJSXP/Zephyr)
does not report its name, but it supports Zephyr-specific properties that no
other known implementation does:
{{[http://java.sun.com/xml/stream/properties/ignore-external-dtd]}} on
{{XMLInputFactory}} and {{reuse-instance}} on {{{}XMLOutputFactory{}}}.
(AXIOM-443 documents that XLXP rejects {{{}reuse-instance{}}}, and the JRE
registers the JAXP 1.5 security properties only for input factories, hence two
different hints. Standard properties such as
{{XMLConstants.ACCESS_EXTERNAL_DTD}} are not usable as a JRE signature because
Woodstox 7.2+ supports them too.)
The location-based detection (manifest and class probing, including the JBoss
unwrapper) stays in place unchanged as a fallback for the legacy
implementations that expose no identifying property: the BEA reference
implementation, WebLogic's parser and IBM XLXP. Whether to eventually remove
that code is a separate decision.
h3. Related issues
* AXIOM-505 - jar-with-dependencies fails to detect StAX dialect (open;
resolved by this change)
* AXIOM-426 - StAX dialect resolved as UnknownStAXDialect under JBoss AS 7.1
(the ad-hoc unwrapper this proposal avoids repeating)
* AXIOM-443 - StAX dialect detection fails on IBM JRE 1.7 (XLXP mis-detected
as SJSXP through class probing; documents that XLXP rejects
{{{}reuse-instance{}}})
* AXIOM-503 - Unable to determine dialect of the StAX implementation at
jar:[file:woodstox-core-6.2.0.jar|file:///woodstox-core-6.2.0.jar] (manifest
version table out of date)
* AXIOM-488 - Unable to determine dialect of the StAX implementation at
jar:file (Tibco; Won't Fix, same warning for a proprietary parser)
* AXIOM-352 - StAXDialectDetector doesn't recognize
com.bea.core.weblogic.stax_1.7.0.0.jar (another manifest rule)
* AXIOM-454 - Import-package org.codehaus.stax2 should be declared optional
(why the property names are string literals rather than StAX2 API constants)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
