[
https://issues.apache.org/jira/browse/AXIOM-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114827#comment-18114827
]
ASF GitHub Bot commented on AXIOM-530:
--------------------------------------
ppkarwasz opened a new pull request, #941:
URL: https://github.com/apache/ws-axiom/pull/941
Fixes [AXIOM-530](https://issues.apache.org/jira/browse/AXIOM-530)
## Motivation
Last week we released [Apache Commons Secure
XML](https://commons.apache.org/proper/commons-secure-xml/), a single source of
secured JAXP factories across the stock JDK and external implementations. To
keep both the factories and the readers they produce easy to use, the library
hands out wrappers. For StAX, the wrapper installs an ignore-all resolver floor
that users cannot remove by accident: a resolver set by the caller is chained
in front of the floor rather than replacing it.
Axiom is where this approach currently breaks down. `StAXDialectDetector`
identifies the StAX implementation solely from the location of the factory
class: it looks up the JAR or `jrt:` module the class was loaded from and
inspects its manifest and neighboring classes. For a wrapped factory the class
is the wrapper's own, which says nothing about the implementation behind it.
Axiom then logs "Unable to determine dialect of the StAX implementation" and
falls back to `UnknownStAXDialect`, losing the implementation-specific
normalization it relies on. In practice this makes Commons Secure XML unusable
for Axis2 users.
This is the same class of failure that
[AXIOM-426](https://issues.apache.org/jira/browse/AXIOM-426) fixed for JBoss AS
7 with a reflective unwrapper, and that
[AXIOM-503](https://issues.apache.org/jira/browse/AXIOM-503) and
[AXIOM-505](https://issues.apache.org/jira/browse/AXIOM-504) hit through
manifests. Rather than adding one more adhoc rule, this change relies on
information that does not depend on the factory class at all.
## Changes
Before falling back to the existing location-based detection, query the
factory for properties that identify the implementation. Factory wrappers pass
property queries through to the wrapped factory, so this works for wrapped
factories:
- `org.codehaus.stax2.implName` (StAX2 API, supported by Woodstox 4+ and
Aalto) and Sun's `implementation-name` property (SJSXP) report the
implementation name.
- The implementation shipped with the JRE does not report its name. It is
recognized by Zephyr-specific properties that no other known implementation
supports: `ignore-external-dtd` on input factories and `reuse-instance` on
output factories.
The location-based detection, including the JBoss unwrapper, is left
untouched as a fallback for the legacy implementations that expose no
identifying property (BEA reference implementation, WebLogic, IBM XLXP).
Whether that code should eventually go is a separate decision for the
maintainers.
The property behavior was verified against the sources of Woodstox 4.4.1 and
7.2.2, Aalto 1.3.3, SJSXP 1.0.2, the BEA reference implementation 1.2.0 and the
JDK 17 `java.xml` module.
## Backports
A small ask, should this PR be accepted: could it be backported to 1.x? Like
many in the XML world, I have former clients stuck on JDK 8. Commons Secure XML
could improve their security posture, and an official `1.4.1` release would
serve them better than a private fork. The patch uses a pattern-matching
`instanceof` and an arrow `switch`, so a 1.x backport needs a small syntax
adjustment for the Java 8 baseline; I am happy to prepare it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
> 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: 1.4.0, 2.0.0
> Reporter: Piotr Karwasz
> Priority: Minor
>
> 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]
