Mailing-List: contact dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ws.apache.org
Date: Thu, 8 Mar 2012 20:35:59 +0000 (UTC)
From: "Hudson (Commented) (JIRA)" <jira@apache.org>
To: dev@ws.apache.org
Message-ID: 
 <1696903367.40233.1331238959704.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1920620493.24264.1330986603814.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (AXIOM-412) DOOM's OMFactory implementation
 should be stateless
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/AXIOM-412?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13225=
471#comment-13225471 ]=20

Hudson commented on AXIOM-412:
------------------------------

Integrated in ws-axiom-trunk #817 (See [https://builds.apache.org/job/ws-ax=
iom-trunk/817/])
    AXIOM-412: Implemented rule (6) for attribute nodes and moved the owner=
Node attribute down from NodeImpl to ChildNode. (Revision 1298553)

     Result =3D SUCCESS
veithen :=20
Files :=20
* /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/=
org/apache/axiom/om/impl/dom/AttrImpl.java
* /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/=
org/apache/axiom/om/impl/dom/AttributeMap.java
* /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/=
org/apache/axiom/om/impl/dom/ChildNode.java
* /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/=
org/apache/axiom/om/impl/dom/ElementImpl.java
* /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/=
org/apache/axiom/om/impl/dom/NodeImpl.java

               =20
> DOOM's OMFactory implementation should be stateless
> ---------------------------------------------------
>
>                 Key: AXIOM-412
>                 URL: https://issues.apache.org/jira/browse/AXIOM-412
>             Project: Axiom
>          Issue Type: Improvement
>          Components: DOOM
>    Affects Versions: 1.2.12
>            Reporter: Andreas Veithen
>
> There is a sort of "impedance mismatch" between the Axiom API and DOM bec=
ause
> * the Axiom API is designed such that nodes are created using a factory (=
OMFactory or SOAPFactory) that is expected to be a singleton and stateless;
> * in the DOM API, the Document instance plays the role of node factory, a=
nd each node (explicitly or implicitly) keeps a reference to the Document i=
nstance from which it was created (the "owner document").
> The approach currently used by DOOM to solve that issue is to have a stat=
eful OMFactory implementation which has a reference to a (OM)Document insta=
nce. That (OM)Document instance is then used as the owner document for node=
s created using the Axiom API [Well, actually it is a bit more complicated =
and obscure than that...]. For this to work, the application code is requir=
ed to request an OMFactory once and only once for each document created. Th=
is is one of the reasons why in general code written for the standard Axiom=
 implementation (LLOM) doesn't work well when switching to DOOM. In additio=
n, although the implementation of that design is relatively simple, it make=
s DOOM quite obscure from the user's perspective.
> There is an alternative approach to solve the Axiom/DOM impedance mismatc=
h which doesn't require a stateful OMFactory implementation. It is based on=
 the following set of rules that determine how the DOM owner document is ha=
ndled when nodes are created and manipulated using the Axiom API:
> (1) Nodes created using the Axiom API and for which a parent node is spec=
ified will have as their owner document the owner document of the parent. T=
his is simply a consequence of the fact that DOM is designed such that two =
nodes that are part of the same tree must have the same owner document.
> (2) Nodes created using the Axiom API and for which no parent node is spe=
cified will get a new owner document. That is unavoidable if one wants a st=
ateless/singleton OMFactory.
> (3) When the Axiom API is used to add a node A as a child of another node=
 B, then the owner document of B becomes the new owner document of A and al=
l its descendants. In DOM parlance, this means that node A is automatically=
 adopted by the owner document of B. This rule ensures that any operation t=
hat is valid with the LLOM implementation will also work with DOOM (without=
 triggering a WRONG_DOCUMENT_ERR exception and without violating the rule t=
hat all nodes in a tree must have the same owner document).
> (4) When a node is detached from its parent using the Axiom API (i.e. usi=
ng OMNode#detach), it will get a new owner document. This rule is not stric=
tly required to make the approach work; it merely exists for consistency be=
cause together with the other rules it implies that every tree has a distin=
ct owner document (as long as only the Axiom API is used to manipulate the =
nodes).
> If implemented literally, these rules would obviously have a performance =
impact because (depending on the usage pattern) a large number of temporary=
 Document instances may be needed. In addition, rules (3) and (4) require a=
n efficient way to change the owner document of an entire tree (more effici=
ent than to traverse the entire tree). Therefore these rules would be suppl=
emented by the following design choices:
> (5) Owner documents are created lazily, namely when explicitly requested =
using DOM's Node#getOwnerDocument() API (or when DOOM needs to access data =
that it choses to store in the owner document).
> (6) Only the root node of a tree stores a reference to the owner document=
. As noted above, all nodes in a tree must have the same owner document. Th=
erefore it is not necessary for a node to have references to both its paren=
t and its owner document. Instead, a node should have a single attribute th=
at stores the reference either to the parent (if it has a parent) or to the=
 owner document (if it has no parent), as well as a flag that indicates the=
 meaning of the reference (this is important if the reference points to a D=
ocument instance, which would otherwise be ambiguous). With this design, ch=
anging the owner document of a tree is O(1) instead of O(N) where N is the =
number of nodes in the tree. However, requesting the owner document of a no=
de is O(M) instead of O(1) with M the depth of the tree. This is a good tra=
deoff considering that
> * Axiom methods never need to check the owner document;
> * DOM methods need to check the owner document more often (basically for =
every node addition) than the owner document of a tree is changed, but M <<=
 N.
> It should be noted that switching from the current design to the new desi=
gn proposed here is not entirely transparent for application code. It impli=
es a change in behavior if nodes are first created and manipulated using th=
e Axiom API and then later passed to DOM APIs such as appendChild. In that =
situation it is likely that with the new design, the nodes have different o=
wner documents, while this was not the case with the old design (because th=
e same OMFactory instance was used). Such application code needs to be chan=
ged to use Document#adoptNode where appropriate. However, it is expected th=
at in the Axis2 universe, the impact will be limited to a few places in the=
 SAAJ implementation as well as Rampart. There are quite some examples wher=
e these two components depended on incorrect behavior in DOOM's DOM impleme=
ntation or other implementation details, so that in general they can only b=
e expected to work with the Axiom version for which they were built. One ma=
y therefore assume that the impact is acceptable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
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