atom feed15 messages in org.apache.ws.commons-devRe: Stax parsers - one more variation
FromSent OnAttachments
Davanum SrinivasJul 27, 2009 3:44 pm 
Andreas VeithenJul 28, 2009 12:21 am 
Andreas VeithenJul 28, 2009 5:33 am 
R J Scheuerle JrJul 28, 2009 5:51 am 
Davanum SrinivasJul 28, 2009 6:03 am 
R J Scheuerle JrJul 28, 2009 6:35 am 
Andreas VeithenJul 28, 2009 7:08 am 
R J Scheuerle JrJul 28, 2009 7:13 am 
Andreas VeithenAug 2, 2009 2:07 am.zip
Davanum SrinivasAug 2, 2009 6:41 pm 
Andreas VeithenAug 3, 2009 12:25 am 
Davanum SrinivasAug 3, 2009 4:43 am 
Andreas VeithenAug 8, 2009 8:24 am.zip
Andreas VeithenAug 8, 2009 11:43 am 
Davanum SrinivasAug 9, 2009 4:15 pm 
Subject:Re: Stax parsers - one more variation
From:Davanum Srinivas (dava@gmail.com)
Date:Aug 2, 2009 6:41:38 pm
List:org.apache.ws.commons-dev

Andreas,

What class name do you get if you print out factory and reader variables?

i tried with the WAS7 i had, basically added the xlxp jar in plugins directory
to my classpath and ran your test and it works fine.

thanks, dims

On 08/02/2009 05:07 AM, Andreas Veithen wrote:

Rich, Dims,

While doing some tests with XLXP I noticed that when it recycles a stream reader, it sometimes fails to completely reset the parser state, causing the recycled reader to return an incorrect sequence of events. Is that a known issue?

I attached a simple test that reproduces the problem.

On Tue, Jul 28, 2009 at 16:14, R J Scheuerle Jr<sch@us.ibm.com> wrote:

Hi Andreas,

I have not encountered any other parsers that have this interpretation.

Rich Scheuerle Senior Programmer, IBM Web Services Development, Support, and Open Source Apache Axis2 (sch@apache.org) 512-286-8420 (IBM TL 363-8420)

Andreas Veithen ---07/28/2009 09:09:56 AM---Rich,

Andreas Veithen<andr@gmail.com>

07/28/2009 09:09 AM

Please respond to comm@ws.apache.org

To comm@ws.apache.org cc

Subject Re: Stax parsers - one more variation Rich,

Are there any other "user communities" that believe(d) in this interpretation?

Regards,

On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<sch@us.ibm.com> wrote:

FYI,

There were some gray areas in the StAX specification with regards to the semantics of "set prefix".

In addition, there was an example in the specification that matched XLXP-J's interpretation.

Thanks,

Rich Scheuerle Senior Programmer, IBM Web Services Development, Support, and Open Source Apache Axis2 (sch@apache.org) 512-286-8420 (IBM TL 363-8420)

Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,

Andreas Veithen<andr@gmail.com>

07/28/2009 07:33 AM

Please respond to comm@ws.apache.org

To comm@ws.apache.org cc

Subject Re: Stax parsers - one more variation Dims,

I just stumbled over TUSCANY-1818. When reading this together with WSCOMMONS-66 and WSCOMMONS-262, things become clearer. Apparently, what happened is that in the first versions of XLXP-J, IBM didn't get the StAX specs right and Axiom had to adapt to this, i.e. the vague term "user community" actually refers to IBM! When they finally recognized this problem, they introduced the javax.xml.stream.XMLStreamWriter.isSetPrefixBeforeStartElement property as an elegant way to rectify this without making too much noise. Brilliant!

On Tue, Jul 28, 2009 at 09:21, Andreas Veithen<andr@gmail.com> wrote:

Dims,

Actually I initially developed the idea to have the concept of a "StAX dialect" in Axiom when I saw this piece of code. I started to implement this feature when trying to solve the thread safety issue, but the aim is clearly to get rid of the isSetPrefixBeforeStartElement hack(s).

I had a closer look at the code during the weekend, but I fail to see in which case we would actually need/have isSetPrefixBeforeStartElement == true. In my opinion, the StAX specifications don't leave enough room for the second interpretation (that setPrefix would apply to the next writeStartElement) [1]. Also, of all the StAX implementations I've seen, none expects this. Do you have any idea which "user community" "believes" this?

Andreas

[1] http://people.apache.org/~veithen/axiom/devguide/ch02.html#d0e69

On Tue, Jul 28, 2009 at 00:45, Davanum Srinivas<dava@gmail.com> wrote:

Andreas,

Not sure if you have seen this already. There's some convoluted code in org/apache/axiom/om/impl/util/OMSerializerUtil.java (method isSetPrefixBeforeStartElement) which basically has a toggle based on the parsers.

// Fallback: Toggle based on sun or woodstox implementation. NamespaceContext nc = writer.getNamespaceContext(); ret = (nc == null || (nc.getClass().getName().indexOf("wstx") == -1&& nc.getClass().getName().indexOf("weblogic") == -1&& nc.getClass().getName().indexOf("sun") == -1));

The javadoc has more information:

/** * Unfortunately there is disagreement in the user community about the semantics of setPrefix on * the XMLStreamWriter. An example will explain the difference: writer.startElement("a") * writer.setPrefix("pre", "urn://sample") writer.startElement("b") *<p/> * Some user communities (woodstox) believe that the setPrefix is associate with the scope for * "a" and thus remains in scope until the end of a. The basis for this believe is * XMLStreamWriter javadoc (which some would argue is incomplete). *<p/> * Some user communities believe that the setPrefix is associated with the "b" element. These * communities reference an example in the specification and historical usage of SAX. *<p/> * This method will return true if the setPrefix is associated with the next writeStartElement. * * @param writer * @return true if setPrefix should be generated before startElement */

Can you please take a look?

If we can find a way to totally remove the need for caching the boolean after checking the xmlstreamwriter, that would be a big bonus.

thanks, dims