You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Michail (Jira)" <xe...@xml.apache.org> on 2020/07/08 19:39:00 UTC

[jira] [Created] (XERCESJ-1723) Support StAX 1.2 update on javax.xml.stream.XmlFactoryInput

Michail created XERCESJ-1723:
--------------------------------

             Summary: Support StAX 1.2 update on javax.xml.stream.XmlFactoryInput
                 Key: XERCESJ-1723
                 URL: https://issues.apache.org/jira/browse/XERCESJ-1723
             Project: Xerces2-J
          Issue Type: Bug
          Components: StAX
    Affects Versions: 2.12.1
         Environment: Java 6 and above
            Reporter: Michail


Latest Xerces-J version (at this time 2.12.1) does not implement javax.xml.stream.XmlInputFactory.newFactory() method which is available from Java 7 and at least some Java 6 implementations: [https://docs.oracle.com/javase/7/docs/api/javax/xml/stream/XMLInputFactory.html] . This change was introduced in JSR 173 Revision 3: [https://jcp.org/aboutJava/communityprocess/maintenance/jsr173/173-mr3-rev.html]

 

Per this technote [https://docs.oracle.com/javase/8/docs/technotes/guides/standards/] the endorsed override mechanism should not be used to downgrade the Standard API version to an older version:

"...these technologies may be overridden only by providing a complete and newer implementation of the Standalone Technology than was provided in the original implementation of the Java Platform..."

Effectively when the StAX events were introduced in Xerces this downgrades StAX 1.2 to StAX 1.0 because otherwise the StAX APIs (javax.xml.sream) would have been taken from JRE. As a real world example, this broke an application using Xerces 2.9, which did not include javax.xml.stream in xml-api.jar, upgraded to Xerces 2.11 that does implement it. Essentially, even if Xerces clearly states it supports StAX 1.0 (and not 1.2) it does break this backward compatibility without leaving a straightforward solution.

Suggested solutions:

API jars packaged per technology (i.e. having an stax-api.jar) rather all in one jar (xml-api.jar). This can allow to exclude some jars when this backward compatibility is important but without having to choose between using xml-api.jar at all or between using Xerces at all. Of course, StAX 1.2 could also be included but a repackaging seems a more straightforward and simple solution to the problem

 

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org