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

Hudson commented on AXIOM-282:
------------------------------

Integrated in ws-axiom-trunk #938 (See 
[https://builds.apache.org/job/ws-axiom-trunk/938/])
    Slightly changed the code for the optimization introduced by AXIOM-282 so 
that it interacts in a better way with the feature introduced by AXIOM-399. 
More precisely, a call to SOAPBody#hasFault() will now no longer expand an 
OMSourcedElement with unknown name present in the body. (Revision 1334113)

     Result = SUCCESS
veithen : 
Files : 
* 
/webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/soap/impl/llom/SOAPBodyImpl.java
* 
/webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java
* 
/webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/body/TestHasFaultWithOMSEUnknownName.java

                
> Get Payload QName information without building OMElement
> --------------------------------------------------------
>
>                 Key: AXIOM-282
>                 URL: https://issues.apache.org/jira/browse/AXIOM-282
>             Project: Axiom
>          Issue Type: Improvement
>            Reporter: Rich Scheuerle
>            Assignee: Rich Scheuerle
>
> Problem:
> The Axis2 code invokes MessageContext.isFault() before starting the phases.  
> This causes an Axiom tree to be built up to and including the
> first child element (payload) in the soap body.   The problem is that the 
> phases might have special CustomBuilders.  Building the Axiom tree past the 
> payload
> can defeat these kinds of optimizations.
> Solution1:
> The first solution is tactical and will work with all parsers.  The proposal 
> is to add some simple, protected "look ahead" code in the StaXOMBuilder.  
> The Axiom SOAPBody can use this information to determine whether the payload 
> is a fault, without actually building the object.    I am working on the 
> tests and code for this first solution, and will have it ready in the next 
> day or two.
> Solution 2:
> The second solution is support a custom property on the parser.  The 
> SOAPEnvelope can then call the custom property on the backing parser to get 
> the soap body payload qname.   The idea is that the parser (woodstox or ibm, 
> etc.) may have already looked ahead in the text before the StAX events are 
> fully pulled.
> The benefit of this solution is that calls, like MessageContext.isFault(), 
> will not cause the expansion of the header elements.    I will work on this 
> solution
> after solution 1 is done.  I don't have a proposed name for the property yet.
> (Note that both of these solutions will require some minor changes to the 
> Axis2 code.)
> P.S. I am working with Takahide Nogayama on these changes.
> Thanks,
> Rich Scheuerle

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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

Reply via email to