You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Andreas Veithen <an...@gmail.com> on 2009/08/02 11:07:57 UTC
Re: Stax parsers - one more variation
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.
Andreas
On Tue, Jul 28, 2009 at 16:14, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
> 512-286-8420 (IBM TL 363-8420)
>
> Andreas Veithen ---07/28/2009 09:09:56 AM---Rich,
>
> Andreas Veithen <an...@gmail.com>
>
> 07/28/2009 09:09 AM
>
> Please respond to
> commons-dev@ws.apache.org
>
> To
> commons-dev@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,
>
> Andreas
>
> On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>> 512-286-8420 (IBM TL 363-8420)
>>
>> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,
>>
>> Andreas Veithen <an...@gmail.com>
>>
>> 07/28/2009 07:33 AM
>>
>> Please respond to
>> commons-dev@ws.apache.org
>>
>> To
>> commons-dev@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!
>>
>> Andreas
>>
>> On Tue, Jul 28, 2009 at 09:21, Andreas Veithen<an...@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<da...@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
>>>>
>>>> --
>>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>>
>>>
>>
>>
>
>
Re: Stax parsers - one more variation
Posted by Andreas Veithen <an...@gmail.com>.
Dims,
XLXP2 seems to have an issue with the
XMLStreamReader#getNamespaceContext implementation. In some cases, a
prefix binding becomes visible before the reader actually reaches the
START_ELEMENT event that declares the prefix (see the attached test
case). Can you check if you are able to reproduce this?
Andreas
On Mon, Aug 3, 2009 at 13:43, Davanum Srinivas<da...@gmail.com> wrote:
> Andreas,
>
> I'll forward the bug along. But since its fixed in xlxp2 it's probably a
> matter of time...
>
> thanks,
> dims
>
> On 08/03/2009 03:26 AM, Andreas Veithen wrote:
>>
>> Dims,
>>
>> With the xlxp2 from WAS7 it indeed works fine. I encountered the
>> problem with the XLXP version that is part of JDK 1.6.
>>
>> Andreas
>>
>> On Mon, Aug 3, 2009 at 03:42, Davanum Srinivas<da...@gmail.com> wrote:
>>>
>>> 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.
>>>>
>>>> Andreas
>>>>
>>>> On Tue, Jul 28, 2009 at 16:14, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>>>> 512-286-8420 (IBM TL 363-8420)
>>>>>
>>>>> Andreas Veithen ---07/28/2009 09:09:56 AM---Rich,
>>>>>
>>>>> Andreas Veithen<an...@gmail.com>
>>>>>
>>>>> 07/28/2009 09:09 AM
>>>>>
>>>>> Please respond to
>>>>> commons-dev@ws.apache.org
>>>>>
>>>>> To
>>>>> commons-dev@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,
>>>>>
>>>>> Andreas
>>>>>
>>>>> On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>>>>> 512-286-8420 (IBM TL 363-8420)
>>>>>>
>>>>>> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,
>>>>>>
>>>>>> Andreas Veithen<an...@gmail.com>
>>>>>>
>>>>>> 07/28/2009 07:33 AM
>>>>>>
>>>>>> Please respond to
>>>>>> commons-dev@ws.apache.org
>>>>>>
>>>>>> To
>>>>>> commons-dev@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!
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> On Tue, Jul 28, 2009 at 09:21, Andreas
>>>>>> Veithen<an...@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<da...@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
>>>>>>>>
>>>>>>>> --
>>>>>>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
Re: Stax parsers - one more variation
Posted by Davanum Srinivas <da...@gmail.com>.
Andreas,
I'll forward the bug along. But since its fixed in xlxp2 it's probably a matter of time...
thanks,
dims
On 08/03/2009 03:26 AM, Andreas Veithen wrote:
> Dims,
>
> With the xlxp2 from WAS7 it indeed works fine. I encountered the
> problem with the XLXP version that is part of JDK 1.6.
>
> Andreas
>
> On Mon, Aug 3, 2009 at 03:42, Davanum Srinivas<da...@gmail.com> wrote:
>> 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.
>>>
>>> Andreas
>>>
>>> On Tue, Jul 28, 2009 at 16:14, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>>> 512-286-8420 (IBM TL 363-8420)
>>>>
>>>> Andreas Veithen ---07/28/2009 09:09:56 AM---Rich,
>>>>
>>>> Andreas Veithen<an...@gmail.com>
>>>>
>>>> 07/28/2009 09:09 AM
>>>>
>>>> Please respond to
>>>> commons-dev@ws.apache.org
>>>>
>>>> To
>>>> commons-dev@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,
>>>>
>>>> Andreas
>>>>
>>>> On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>>>> 512-286-8420 (IBM TL 363-8420)
>>>>>
>>>>> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,
>>>>>
>>>>> Andreas Veithen<an...@gmail.com>
>>>>>
>>>>> 07/28/2009 07:33 AM
>>>>>
>>>>> Please respond to
>>>>> commons-dev@ws.apache.org
>>>>>
>>>>> To
>>>>> commons-dev@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!
>>>>>
>>>>> Andreas
>>>>>
>>>>> On Tue, Jul 28, 2009 at 09:21, Andreas
>>>>> Veithen<an...@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<da...@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
>>>>>>>
>>>>>>> --
>>>>>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
Re: Stax parsers - one more variation
Posted by Andreas Veithen <an...@gmail.com>.
Dims,
With the xlxp2 from WAS7 it indeed works fine. I encountered the
problem with the XLXP version that is part of JDK 1.6.
Andreas
On Mon, Aug 3, 2009 at 03:42, Davanum Srinivas<da...@gmail.com> wrote:
> 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.
>>
>> Andreas
>>
>> On Tue, Jul 28, 2009 at 16:14, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>> 512-286-8420 (IBM TL 363-8420)
>>>
>>> Andreas Veithen ---07/28/2009 09:09:56 AM---Rich,
>>>
>>> Andreas Veithen<an...@gmail.com>
>>>
>>> 07/28/2009 09:09 AM
>>>
>>> Please respond to
>>> commons-dev@ws.apache.org
>>>
>>> To
>>> commons-dev@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,
>>>
>>> Andreas
>>>
>>> On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>>> 512-286-8420 (IBM TL 363-8420)
>>>>
>>>> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,
>>>>
>>>> Andreas Veithen<an...@gmail.com>
>>>>
>>>> 07/28/2009 07:33 AM
>>>>
>>>> Please respond to
>>>> commons-dev@ws.apache.org
>>>>
>>>> To
>>>> commons-dev@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!
>>>>
>>>> Andreas
>>>>
>>>> On Tue, Jul 28, 2009 at 09:21, Andreas
>>>> Veithen<an...@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<da...@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
>>>>>>
>>>>>> --
>>>>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
Re: Stax parsers - one more variation
Posted by Davanum Srinivas <da...@gmail.com>.
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.
>
> Andreas
>
> On Tue, Jul 28, 2009 at 16:14, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>> 512-286-8420 (IBM TL 363-8420)
>>
>> Andreas Veithen ---07/28/2009 09:09:56 AM---Rich,
>>
>> Andreas Veithen<an...@gmail.com>
>>
>> 07/28/2009 09:09 AM
>>
>> Please respond to
>> commons-dev@ws.apache.org
>>
>> To
>> commons-dev@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,
>>
>> Andreas
>>
>> On Tue, Jul 28, 2009 at 15:35, R J Scheuerle Jr<sc...@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 (scheu@apache.org)
>>> 512-286-8420 (IBM TL 363-8420)
>>>
>>> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims,
>>>
>>> Andreas Veithen<an...@gmail.com>
>>>
>>> 07/28/2009 07:33 AM
>>>
>>> Please respond to
>>> commons-dev@ws.apache.org
>>>
>>> To
>>> commons-dev@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!
>>>
>>> Andreas
>>>
>>> On Tue, Jul 28, 2009 at 09:21, Andreas Veithen<an...@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<da...@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
>>>>>
>>>>> --
>>>>> Davanum Srinivas :: http://davanum.wordpress.com
>>>>>
>>>>
>>>
>>>
>>
>>