axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.j ava
Date Wed, 11 Dec 2002 22:49:15 GMT
As stated in the bug report, the problem here is that SAX requires 
namespaces to be reported *before* the start of the element: 
http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html#startPrefixMapping(java.lang.String,%20java.lang.String)

There's a good reason for this - the element and its attributes may make 
use of the namespaces declared with that element, so the namespace 
declarations need to be reported first. For NSStack this means that the 
namespaces are pushed before the corresponding element, though, and are 
not removed from the stack until the close of the parent of that element.

XML:
  <multiRef id="id15" soapenc:root="0" 
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xsi:type="ns27:FlightBean" xmlns:ns27="http://flightsraw" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">

NSStack:
{http://flightsraw}=ns27
{http://schemas.xmlsoap.org/soap/encoding/}=soapenc
null

XML:
  </multiRef>

NSStack:
{http://flightsraw}=ns27
{http://schemas.xmlsoap.org/soap/encoding/}=soapenc

clearFrame() only goes until it sees a null - which it does immediately. 
The null is then removed by the top--.

I'll verify that the problem still occurs in tonight's drop, and prepare 
a SAX demo program using a patched version of NSStack to show the stack 
depth if necessary.

  - Dennis

Glen Daniels wrote:

>Hi Dennis:
>
>A quick scan of the logic in NSStack looks OK to me...
>
>When we get to a new element (while serializing or deserializing) the appropriate context
will push() manually, to ensure a null on the stack.  Then each time we add() a mapping, push()
gets called simply as a convenience to move the pointer forward and auto-grow the array. 
Hence, calling clearFrame() first when we pop will back the stack up to the null at the beginning
of the current frame.  Then the top-- after that backs the top up beyond the null (to the
end of the last frame).  In general, I think the nulls-as-markers pattern is fine.  The only
thing keeping another stack of frame indices around would buy us would be a quicker pop()
when there are a lot of mappings on a given frame - not a huge deal.
>
>There was an extraneous clearFrame() call in SerializationContextImpl, which I removed
- don't know if that might have contributed to your issues.
>
>If you still think there's a problem, the best thing to do is write up a small test case
which demonstrates it (i.e. call NSStack APIs in the same order that we do while (de)serializing,
and then check the size/top of the stack to make sure things look reasonable) and we can go
from there.
>
>Thanks for your attention to this stuff, btw.  I hope you get your build working and continue
to find Axis a valuable place for your energies!
>
>--Glen
>
>  
>
>>-----Original Message-----
>>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>>Sent: Wednesday, December 11, 2002 4:43 PM
>>To: axis-dev@xml.apache.org
>>Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis/utils
>>NSStack.java
>>
>>
>>Hi Glen,
>>
>>Looks like you've put the namespace stack problem back in by 
>>restoring 
>>the original order of operations (call to clearFrame() before 
>>decrementing top). Am I missing something here? The problem I saw was 
>>that namespaces were pushed on the stack before the null 
>>value, so the 
>>null value had to be removed before calling clearFrame(). If you can 
>>tell me what went wrong when the order was changed perhaps I 
>>can suggest 
>>an alternative fix. Sorry I didn't try this out with the whole test 
>>suite myself, I'm hoping to get set up for full build this 
>>next weekend.
>>
>>This whole business of pushing nulls on the stack as markers 
>>leaves me 
>>uncomfortable. I'd prefer using two stacks, one for the actual 
>>namespaces and one for the frames (as top of stack values for the 
>>namespace stack). It's a substantial change to make without a good 
>>reason, though.
>>
>>  - Dennis
>>
>>gdaniels@apache.org wrote:
>>
>>    
>>
>>>gdaniels    2002/12/11 08:12:30
>>>
>>> Modified:    java/src/org/apache/axis/providers/java 
>>>      
>>>
>>RPCProvider.java
>>    
>>
>>>              java/src/org/apache/axis/utils NSStack.java
>>> Log:
>>> Tweak NSStack fix, and throw the unwrapped exception if 
>>>      
>>>
>>deserializing
>>    
>>
>>> from within RPCProvider.
>>> 
>>>
>>>      
>>>
>>> 
>>> 1.35      +3 -6      
>>>      
>>>
>>xml-axis/java/src/org/apache/axis/utils/NSStack.java
>>    
>>
>>> 
>>> Index: NSStack.java
>>> ===================================================================
>>> RCS file: 
>>>      
>>>
>>/home/cvs/xml-axis/java/src/org/apache/axis/utils/NSStack.java,v
>>    
>>
>>> retrieving revision 1.34
>>> retrieving revision 1.35
>>> diff -u -r1.34 -r1.35
>>> --- NSStack.java	10 Dec 2002 17:22:03 -0000	1.34
>>> +++ NSStack.java	11 Dec 2002 16:12:30 -0000	1.35
>>> @@ -58,9 +58,6 @@
>>>  import org.apache.commons.logging.Log;
>>>  
>>>  import java.util.ArrayList;
>>> -import java.util.Enumeration;
>>> -import java.util.Stack;
>>> -import java.util.Iterator;
>>>  
>>>  /**
>>>   * The abstraction this class provides is a push down 
>>>      
>>>
>>stack of variable
>>    
>>
>>> @@ -79,7 +76,7 @@
>>>   * Accordingly, this stack is implemented as a single 
>>>      
>>>
>>array, will null
>>    
>>
>>>   * values used to indicate frame boundaries.
>>>   *
>>> - * @author: James Snell
>>> + * @author James Snell
>>>   * @author Glen Daniels (gdaniels@macromedia.com)
>>>   * @author Sam Ruby (rubys@us.ibm.com)
>>>   */
>>> @@ -118,9 +115,9 @@
>>>       * Remove the top frame from the stack.
>>>       */
>>>      public void pop() {
>>> -        top--;
>>> -
>>>          clearFrame();
>>> +
>>> +        top--;
>>>  
>>>          if (top == 0) {
>>>              if (log.isTraceEnabled())
>>> 
>>> 
>>> 
>>>
>>> 
>>>
>>>      
>>>
>
>  
>


Mime
View raw message