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<[email protected]> 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<[email protected]> 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 ([email protected]) >>> 512-286-8420 (IBM TL 363-8420) >>> >>> Andreas Veithen ---07/28/2009 09:09:56 AM---Rich, >>> >>> Andreas Veithen<[email protected]> >>> >>> 07/28/2009 09:09 AM >>> >>> Please respond to >>> [email protected] >>> >>> To >>> [email protected] >>> 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<[email protected]> 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 ([email protected]) >>>> 512-286-8420 (IBM TL 363-8420) >>>> >>>> Andreas Veithen ---07/28/2009 07:34:54 AM---Dims, >>>> >>>> Andreas Veithen<[email protected]> >>>> >>>> 07/28/2009 07:33 AM >>>> >>>> Please respond to >>>> [email protected] >>>> >>>> To >>>> [email protected] >>>> 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<[email protected]> >>>> 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<[email protected]> >>>>> 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 >>>>>> >>>>> >>>> >>>> >>> >>> >
