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 <[email protected]> > On Tue, Aug 9, 2011 at 6:49 AM, Ivan <[email protected]> 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
