From dev-return-10276-apmail-ws-dev-archive=ws.apache.org@ws.apache.org Tue Nov 30 09:05:48 2010 Return-Path: Delivered-To: apmail-ws-dev-archive@www.apache.org Received: (qmail 67665 invoked from network); 30 Nov 2010 09:05:41 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 30 Nov 2010 09:05:41 -0000 Received: (qmail 24079 invoked by uid 500); 30 Nov 2010 09:05:39 -0000 Delivered-To: apmail-ws-dev-archive@ws.apache.org Received: (qmail 23713 invoked by uid 500); 30 Nov 2010 09:05:39 -0000 Mailing-List: contact dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ws.apache.org Delivered-To: mailing list dev@ws.apache.org Received: (qmail 23146 invoked by uid 99); 30 Nov 2010 09:05:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Nov 2010 09:05:37 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Nov 2010 09:05:35 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id oAU95BLc008179 for ; Tue, 30 Nov 2010 09:05:11 GMT Message-ID: <20168260.20971291107910983.JavaMail.jira@thor> Date: Tue, 30 Nov 2010 04:05:10 -0500 (EST) From: "Andreas Veithen (JIRA)" To: dev@ws.apache.org Subject: [jira] Updated: (AXIOM-353) Need a replacement for OMXMLBuilderFactory In-Reply-To: <10821169.19781291101430828.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/AXIOM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-353: ---------------------------------- Description: 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). was: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 because 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). There should be an abstract API for this. OMMetaFactory is a good candidate because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DDOM). > 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 > > 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. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org For additional commands, e-mail: dev-help@ws.apache.org