axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.j ava
Date Wed, 11 Dec 2002 23:26:15 GMT

Oh, I see!

That doesn't sound like an NSStack problem, but a usage problem.  Check out my last commit
and see if that makes things happier - we now push a frame when we see the first new mapping
OR when we hit startElement if there aren't any mappings.  This ensures that the pop() during
endElement will always clear out the current mappings.

Does that address the problem?

--Glen

> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Wednesday, December 11, 2002 5:49 PM
> To: axis-dev@xml.apache.org
> Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis/utils
> NSStack.j ava
> 
> 
> 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.ht
> ml#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