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 Davanum Srinivas <da...@gmail.com> on 2009/07/28 00:45:08 UTC
Stax parsers - one more variation
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 R J Scheuerle Jr <sc...@us.ibm.com>.
There are some IBM parsers that require this toggle.
My vote is to keep the toggle.
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
<andreas.veithen@
gmail.com> To
commons-dev@ws.apache.org
07/28/2009 02:21 cc
AM
Subject
Re: Stax parsers - one more
Please respond to variation
commons-dev@ws.ap
ache.org
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>.
Thanks Andreas. Will give this a whirl when i get a chance!
-- dims
On 08/08/2009 02:44 PM, Andreas Veithen wrote:
> The dialect detection now covers the following versions of XLXP:
>
> - The version from the Web Services Feature pack.
> - IBM JDK 1.6.
> - WebSphere 7
>
> In particular it fixes the setPrefix behavior of the early XLXP
> versions, so that I was able to eliminate the
> isSetPrefixBeforeStartElement stuff. All Axiom tests succeed with the
> three versions.
>
> Please review and let me know if there are any concerns.
>
> Andreas
>
> On Tue, Jul 28, 2009 at 15:04, Davanum Srinivas<da...@gmail.com> wrote:
>> Andreas,
>>
>> I have no clue what happens in the StaX JSR mailing lists...All i know is
>> that there are variations between the stax impl(s) currently in the field
>> and this is the only check where we could not find a better way to manage
>> the variations cleanly. Which is why the dialect stuff introduction is a
>> good thing :)
>>
>> thanks,
>> -- dims
>>
>> On 07/28/2009 08:33 AM, Andreas Veithen wrote:
>>>
>>> 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>.
The dialect detection now covers the following versions of XLXP:
- The version from the Web Services Feature pack.
- IBM JDK 1.6.
- WebSphere 7
In particular it fixes the setPrefix behavior of the early XLXP
versions, so that I was able to eliminate the
isSetPrefixBeforeStartElement stuff. All Axiom tests succeed with the
three versions.
Please review and let me know if there are any concerns.
Andreas
On Tue, Jul 28, 2009 at 15:04, Davanum Srinivas<da...@gmail.com> wrote:
> Andreas,
>
> I have no clue what happens in the StaX JSR mailing lists...All i know is
> that there are variations between the stax impl(s) currently in the field
> and this is the only check where we could not find a better way to manage
> the variations cleanly. Which is why the dialect stuff introduction is a
> good thing :)
>
> thanks,
> -- dims
>
> On 07/28/2009 08:33 AM, Andreas Veithen wrote:
>>
>> 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 have no clue what happens in the StaX JSR mailing lists...All i know is that there are variations between the stax
impl(s) currently in the field and this is the only check where we could not find a better way to manage the variations
cleanly. Which is why the dialect stuff introduction is a good thing :)
thanks,
-- dims
On 07/28/2009 08:33 AM, Andreas Veithen wrote:
> 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
>>>>>
>>>>
>>>
>>>
>>
>>
Re: Stax parsers - one more variation
Posted by Andreas Veithen <an...@gmail.com>.
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 R J Scheuerle Jr <sc...@us.ibm.com>.
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
<andreas.veithen@
gmail.com> To
commons-dev@ws.apache.org
07/28/2009 09:09 cc
AM
Subject
Re: Stax parsers - one more
Please respond to variation
commons-dev@ws.ap
ache.org
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>.
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 R J Scheuerle Jr <sc...@us.ibm.com>.
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
<andreas.veithen@
gmail.com> To
commons-dev@ws.apache.org
07/28/2009 07:33 cc
AM
Subject
Re: Stax parsers - one more
Please respond to variation
commons-dev@ws.ap
ache.org
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,
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,
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
>