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

Thu, 12 Dec 2002 11:23:41 -0800 

See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15328

 - Dennis

Glen Daniels wrote:
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())




































					Reply via email to