[issue 768]FromXmlParser lacks extension point for custom XmlTokenStream

[xzxiaoshan]

#768

This PR adds an extension point to FromXmlParser to allow customization of the XmlTokenStream implementation. No logic changes are made — it’s purely an additive change to support extensibility.

If this can be merged and released in a new version soon, it would be greatly appreciated as it's needed for our project.

Thank you!

---

1、By abstracting the createParser method, developers no longer need to override four _createParser methods in XmlFactory when implementing their own custom FromXmlParser.
2、Abstract a createGenerator method to make it easier to extend.

This change is purely structural and does not involve any modification to the underlying logic of the code.

[xzxiaoshan]

@cowtowncoder Hello, could you please take care of this pull request (PR)

[pjfanning]

@xzxiaoshan could you add a test case or 2 to demo and test the new constructor? - it would help to show why it is needed

[cowtowncoder]

Use JDK Objects.requireNonNull() like

_xmlTokens = Objects.requireNonNull(xmlTokenStream, "xmlTokenStream cannot be null");

[cowtowncoder]

Seems reasonable to me, happy to merge.

One process thing @xzxiaoshan: unless you have sent one earlier (if you have just LMK), we'd need CLA before merging the first contribution. It's from here:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

and the usual way is to print, fill & sign, scan/photo, email to cla at fasterxml dot com.
Once I have that I can proceed with merge.

[xzxiaoshan]

@cowtowncoder

Contribution Agreement (CLA) – Signed and Attached

and

Since has been added and the code has been adjusted.

[xzxiaoshan]

@cowtowncoder
Hi, Hello, I've added some related changes. There's still no change to the core logic — it's just an enhancement to improve extensibility.

[xzxiaoshan]

@xzxiaoshan could you add a test case or 2 to demo and test the new constructor? - it would help to show why it is needed

I tried to write test cases, but I found it difficult to construct the code for them. So I’ll explain the scenario here and leave a note about the use case in the pull request.

---

The XmlTokenStream is a class that handles XML parsing. My use case involves extending the _decodeAttributeName method to add a specific prefix — the @ symbol — to attribute names, so that they are stored as keys in the resulting map with this prefix. This allows a clear distinction between XML attributes and child node elements in the parsed data.

However, in the current framework, the instantiation of new XmlTokenStream is fixed within the constructor of FromXmlParser, making it difficult for developers to customize or extend XML parsing behaviors.

Here’s a code snippet from my use case:

public class MyFromXmlParser extends FromXmlParser {

    public MyFromXmlParser (IOContext ctxt, int genericParserFeatures, int xmlFeatures, ObjectCodec codec,
                              XMLStreamReader xmlReader, XmlNameProcessor tagProcessor) throws IOException {
        super(ctxt, genericParserFeatures, codec, new MyXmlTokenStream(xmlReader, ctxt.contentReference(), xmlFeatures, tagProcessor));
    }
}

// MyXmlTokenStream.java

@Override
protected void _decodeAttributeName(String namespaceURI, String localName) {
    localName = "@".concat(localName);
    super._decodeAttributeName(namespaceURI, localName);
}

With this override, I ensure that all XML attributes are marked with the @ prefix during parsing, which helps distinguish them from regular child elements in the resulting JSON structure.

My original intention was to achieve a seamless bidirectional conversion between XML, Map, and JSON, without being troubled by ambiguities caused by XML attributes.

@pjfanning

Moreover, this is not the only issue — as long as developers need to perform custom processing on XmlTokenStream, they are unable to extend or customize their own version of XmlTokenStream within the original code structure.