geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: [woodstox-user] woodstox 4.1.1 is not compatible with JSR 107 ?
Date Wed, 10 Aug 2011 00:15:47 GMT
Stax TCK should be a bit different comparing others, it is somewhat
'public', IIRC. In the past time, Geronimo uses a very old 3.2.7 version,
which seems to be fine.
Yes, those specification sometimes did not clarify things clearly, and think
whether a system property flag could be used to change between the behavior,
by default, it might keep the empty string return value.
Thanks.

2011/8/9 Tatu Saloranta <tsaloranta@gmail.com>

> On Tue, Aug 9, 2011 at 6:49 AM, Ivan <xhhsld@gmail.com> wrote:
> > Hi, this is Ivan from Apache Geronimo community, we are trying to use the
> > latest woodstox 4.1.1 in the coming Geronimo 3.0, but while running it
> with
> > stax test cases, we find that it is not fully compatible with stax spec.
> One
> > is that XMLStreamReader.getNamespacePrefix(int index) does not return
> null
> > value if it is of default namespace declaration, which seems to be
> required
> > by Java Doc.  So has the woodstox 4.1.1 been verified with JSR 107 TCK ?
> > --->
>
> TCKs are not freely available, so we have no access to it. But others
> have succesfully run it in the past, and sometimes provided patches
> for problems uncovered by newer versions of TCK.
>
> > getNamespacePrefix
> >
> > String getNamespacePrefix(int index)
> >
> > Returns the prefix for the namespace declared at the index. Returns null
> if
> > this is the default namespace declaration
> >
> > Parameters: index - the position of the namespace declaration Returns:
> > returns the namespace prefix Throws: IllegalStateException - if this is
> not
> > a START_ELEMENT, END_ELEMENT or NAMESPACE
>
> I hate Stax specification -- this is just fucking idiotic. All other
> instances return empty String, as required, so why the hell should
> null be returned for default namespace. We have already had to change
> return values on multiple places over time, because neither Stax
> specification nor javadocs have clearly indicated correct choice of
> empty String and null. And/or have had inconsistent definitions.
>
> Due to backwards compatibility considerations, I don't think this can
> be changed for 4.1, as this is now the expected behavior.
>
> Going forward... I don't know. We could change that for 5.0.
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>


-- 
Ivan

Mime
View raw message