[jira] [Commented] (AXIOM-353) Need a replacement for OMXMLBuilderFactory

["Andreas Veithen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIOM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096638#comment-13096638 ] 

Andreas Veithen commented on AXIOM-353:
---------------------------------------

OMXMLBuilderFactory should also define a higher level API to create XOP and MTOM builders. With the current API it is the responsibility of the application code to set up the XML parser with the correct charset encoding (which must be derived from the content type of the MIME message or the content type of the root MIME part).

To illustrate the need for such a higher level API, consider the following code that appears several times in the Axiom test suite (and also in other projects):

XMLStreamReader reader = StAXUtils.createXMLStreamReader(new BufferedReader(
    new InputStreamReader(attachments.getRootPartInputStream())));
MTOMStAXSOAPModelBuilder builder = new MTOMStAXSOAPModelBuilder(reader, attachments, null);
OMElement root = builder.getDocumentElement();

This code has two problems:
* Converting the byte stream to a character stream before passing it to the XML parser is an anti-pattern. The XML parser does a much better job than InputStreamReader.
* The code doesn't correctly take into account the character set encoding. The code shown above only works if the root MIME part is encoded with the platform default charset encoding.

This shortcoming of the Axiom API leads to aberrations such as having charset autodection logic (i.e. an implementation of appendix F of the XML specification; see AXIS2-2508) in Axis2, which is something that the XML parser should be responsible for.


> Need a replacement for OMXMLBuilderFactory
> ------------------------------------------
>
>                 Key: AXIOM-353
>                 URL: https://issues.apache.org/jira/browse/AXIOM-353
>             Project: Axiom
>          Issue Type: Improvement
>          Components: API
>            Reporter: Andreas Veithen
>            Assignee: Andreas Veithen
>             Fix For: 1.2.13
>
>
> Historically, org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory was used to create Axiom trees from XML documents (and there are still places in Axis2 where this is used). Unfortunately, this class is located in the wrong package and JAR (it is implementation independent but belongs to LLOM). Nowadays, the standard way to create an Axiom tree is to instantiate StAXOMBuilder or one of its subclasses directly. However, this is not optimal for two reasons:
> * It implies the assumption that every implementation of the Axiom API necessarily uses StAXOMBuilder. This means that an implementation doesn't have the freedom to provide its own builder implementation (e.g. in order to implement some special optimizations).
> * StAXOMBuilder belongs to a package which has "impl" in its name. This tends to blur the distinction between the public API and internal implementation classes.
> There should be an abstract API for creating builder instances. It should be defined in terms of interfaces (such as OMXMLParserWrapper). OMMetaFactory is a good candidate for this because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DOOM).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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