[
https://issues.apache.org/jira/browse/WSCOMMONS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521159
]
Rich Scheuerle commented on WSCOMMONS-236:
------------------------------------------
Thanks Ajith for the comment.
Let me try to pull out the concerns that you have.
=====================================
1) How should an OM with a builder get copied/cloned ?
Answer:
In the new CopyUtils code and in the existing clone hierarchy, copying the tree
causes the source tree to be completely built.
Making copies of attached builder, parser and input stream should be considered
a separate issue.
=====================================
2) What do you mean by not expanding the source tree ?
Answer:
The scenario is an OM tree that has an OMSourcedElement as
the body payload.
In the current clone code, the OMSourcedElement in
the source tree is expanded when cloned, and
the target tree is also fully expanded.
The new CopyUtils code will avoid the expansion of the OMSourcedElement.
Thus the source tree will not be expanded,
and the target tree will contain a similar tree that conatains an
OMSourcedElement.
As we move forward, my expectation is that OMSourcedElement will
be a more frequently utilized plugin in Axiom. So avoiding expansion
of OMSourcedElement is an important goal.
=====================================
3) Why can't we just upgrade the current clone hierarchy ?
Answer:
I think that the clone hierarchy needs to be upgraded, but this work
is slightly orthogonal to the new CopyUtils work.
---
First let me discuss some of the shortcomings of the existing clone hierarchy.
A) The cloneOMElement() code does not produce a clone that has the same class
identity.
For example, if you call cloneOMElement on a SOAPFault you don't get a
SOAPFault back.
B) There is no clone method on non-element Nodes. We need a way to clone Text
nodes.
C) To make clone useful for tree based cloning, the method should pass in the
OMContainer.
For example, the method should be clone(OMContainer parent). This is the only
way to properly
manage namespaces.
---
Second let me discuss some merits of having an external class (like CopyUtils)
control
the copying.
A) All of the code is contained in one place, which makes it easier to debug
and trace.
Some developers believe that this is a better design pattern for complicated
objects (like OM trees).
One example of this pattern is the Axiom Builder. The Builder handles the
complexity associated with the
tree and interaction between nodes in the tree.
B) It will allow us to provide alternate copying strategies that cannot be
handled via a clone hierarchy.
Scenario: The source tree is a large, deep tree.
We want to make a target tree, but we don't want it to consume a
huge amount of memory.
Scenario Solution:
Introduce a copyAndFlatten(SOAPEnvelope) method on CopyUtils. The
utility would
produce OMSourcedElements for the body contents.
===============================================
Here is one way to proceed forward.
A) Accept the changes for WSCOMMONS-236.
B) Open other JIRAs to fix the limitations in the current clone hierarchy.
(Use the information I provided above...plus you may know about other
limitations)
C) Once (B) is done, discuss the next steps based on what is learned during
(B).
Thanks,
Rich
> Introduce a CopyUtils class that makes copies of OM trees
> ---------------------------------------------------------
>
> Key: WSCOMMONS-236
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-236
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Rich Scheuerle
> Assignee: Rich Scheuerle
> Attachments: sandesha_patch.txt
>
>
> Problem Summary:
> Some consumers of Axiom need to make copies of the OM tree.
> Providing a CopyUtils utility in Axiom would allow them to delegate this
> work to Axiom.
> It would also allow the Axiom project to more tightly control this
> critical function.
> Goals of CopyUtils
> 1) The Source tree should be minimally affected by the copy. For example,
> copying an OM SOAPEnvelope
> should not cause unnecessary expansion of descendent OMDataSource
> elements.
> 2) Retain class identity for nodes in the tree. For example, a SOAPFault
> object in the source tree
> will cause a SOAPFault object to be created in the target tree.
> 3) Handle all of the nuances. For example, SOAPHeaderBlocks have
> processed flags. The state of these
> flags should be copied to the target tree.
> 4) If Axiom controls the CopyUtils code, then Axiom is in a better
> position to fix the utility as Axiom is
> improved/upgraded.
> Example Usage:
> An example is the Sandesha project. Here is the code in SandeshaUtils
> that makes a copy of a tree
> be writing and reparsing the data.
> public static MessageContext cloneMessageContext (MessageContext oldMsg)
> throws AxisFault {
> MessageContext newMsg = new MessageContext ();
> newMsg.setOptions(new Options (oldMsg.getOptions()));
>
>
> //TODO hd to use following hack since a 'clone' method was not
> available for SOAPEnvelopes.
> //Do it the correct way when that becomes available.
> OMElement newElement = oldMsg.getEnvelope().cloneOMElement();
> String elementString = newElement.toString();
>
> try {
> ByteArrayInputStream stream = new ByteArrayInputStream(
> elementString.getBytes("UTF8"));
> StAXSOAPModelBuilder builder = new StAXSOAPModelBuilder(
>
> XMLInputFactory.newInstance().createXMLStreamReader(stream),
> null);
> SOAPEnvelope envelope = builder.getSOAPEnvelope();
> newMsg.setEnvelope(envelope);
> } catch (XMLStreamException e) {
> throw AxisFault.makeFault(e);
> } catch (UnsupportedEncodingException e) {
> throw AxisFault.makeFault(e);
> }
>
>
> newMsg.setConfigurationContext(oldMsg.getConfigurationContext());
> newMsg.setAxisService(oldMsg.getAxisService());
> newMsg.setTransportOut(oldMsg.getTransportOut());
> newMsg.setTransportIn(oldMsg.getTransportIn());
>
> return newMsg;
>
> }
> This code will be changed to:
> /**
> * Clone the MessageContext
> * @param oldMsg
> * @return
> * @throws AxisFault
> */
> public static MessageContext cloneMessageContext (MessageContext
> oldMsg) throws AxisFault {
> MessageContext newMsg = new MessageContext ();
> newMsg.setOptions(new Options (oldMsg.getOptions()));
>
> // Create a copy of the envelope
> SOAPEnvelope oldEnvelope = oldMsg.getEnvelope();
> if (oldEnvelope != null) {
> SOAPEnvelope newEnvelope =
> CopyUtils.copy(oldMsg.getEnvelope());
> newMsg.setEnvelope(newEnvelope);
> }
>
>
> newMsg.setConfigurationContext(oldMsg.getConfigurationContext());
> newMsg.setAxisService(oldMsg.getAxisService());
> newMsg.setTransportOut(oldMsg.getTransportOut());
> newMsg.setTransportIn(oldMsg.getTransportIn());
>
> return newMsg;
>
> }
> Full Disclosure:
> I understand that Axiom provides a clone() method on its interfaces.
> Currently the implementation of clone() is
> inadequate and/or broken. For example, invoking clone() on a
> SOAP11BodyImpl will return a OMElement (not a SOAP11BodyImpl).
> Using a separate static utility to control the copying of a tree is an
> easy and effective way to fix the existing clone()
> inadequacies. If the clone() methods are fixed, then it will be easy to
> incorporate those changes into the CopyUtils code.
> In addition, an external copy utility allows us to provide more
> sophisticated copy support (e.g. copyAndFlatten).
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
