Re: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.java

[Dennis Sosnoski]

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:[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())