I respectfully disagree on both counts. :) SerializationContextImpl has the desired behavior already with no changes. You can register mappings up until the point when you call startElement(), at which point we push() a new NSStack frame. We pop() on endElement()s.
--G > -----Original Message----- > From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 6:35 PM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis/utils > NSStack.j ava > > > Uhh, I think you'll also need to change > SerializationContextImpl to use > the same approach you implemented in > DeserializationContextImpl. To be > honest, I think just changing pop() to match the required usage is > simpler and cleaner. :-) > > - Dennis > > Glen Daniels wrote: > > >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:[EMAIL PROTECTED]] > >>Sent: Wednesday, December 11, 2002 5:49 PM > >>To: [EMAIL PROTECTED] > >>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:[EMAIL PROTECTED]] > >>>>Sent: Wednesday, December 11, 2002 4:43 PM > >>>>To: [EMAIL PROTECTED] > >>>>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 > >>>> > >>>>[EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) > >>>>> * @author Sam Ruby ([EMAIL PROTECTED]) > >>>>> */ > >>>>>@@ -118,9 +115,9 @@ > >>>>> * Remove the top frame from the stack. > >>>>> */ > >>>>> public void pop() { > >>>>>- top--; > >>>>>- > >>>>> clearFrame(); > >>>>>+ > >>>>>+ top--; > >>>>> > >>>>> if (top == 0) { > >>>>> if (log.isTraceEnabled()) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > > > > > >
