geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: [woodstox-user] woodstox 4.1.1 is not compatible with JSR 107 ?
Date Thu, 11 Aug 2011 01:01:24 GMT
2011/8/11 Tatu Saloranta <>

> On Tue, Aug 9, 2011 at 5:15 PM, Ivan <> wrote:
> > 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,
> Do you know of a link to freely downloadable copy? It would definitely
> be nice to have access, it just has seemed to be less than public in
> the past for some reason.
> And I haven't fully understood what is the official stance; I assume
> practices and policies vary between JSR/JCPs, meaning that spec lead
> can choose to publicize different things (except they must be shared
> for official participants anyway).

   Just confirmed that, it is a bit difficult to get the TCK packages, :-(

> > which seems to be fine.
> Right; Woodstox made the chance to use "" instead of null in a few
> places specifically to try to be more compliant, since consensus was
> at the time that XML APIs generally expose empty/no-namespace with
> empty Strings, not nulls.
> Exceptions obviously being cases where we could see explicit wording
> stating otherwise, which seems to be what occurs here.
> Can you add a Jira request for this? This probably should be changed
> for next minor or major release, as our goal definitely is to be
> standards compliant.

   Sure, I will open a Jira.

> > 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.
> That is one possibility, although challenge here is that any changes
> to public API (including additions of new configuration property)
> should go in new minor release.
> In the past I think most Stax API users have accepted both null and
> empty String in most places, given that implementations have differed.
> Thank you for pointing out this issue, I appreciate your help in resolving
> this.
> I am bit frustrated with the specification itself (it has been a long
> journey...), but it is what it is. :-)
   Really be appreciated for following this issue,

> -+ Tatu +-
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:


View raw message