Off the top of my head (and I admit that I didn't think about repercussions
too much)... might it be possible to use a compatibility mode param that's
backwards compatible with N versions? This way Jersey can default to the
latest (and presumably recommended) approaches to whatever. It seems like
defaulting to a natural JSON notation could fit into this category as well.
Considering these two, if compatability mode is true, then apps would need
to enable the patch for 361 via init param, and define a JAXBContext
resolver if natural notation is desired.
PS: I brought up the JSON natural notation stuff because, if I remember
correctly, there was talk about making this the default. ...not to mention
my own selfish reasons! :)
On Tue, Mar 9, 2010 at 4:01 AM, Pavel Bucek <Pavel.Bucek_at_sun.com> wrote:
>
> Hello all,
>
> we have a patch for [1] (xml root element list tag name; we stopped
> decapitalizing first character and made sure that declaration from
> @XmlRootElement annotation will be used if present) but we are not sure how
> to make it available. There are two possibilities:
>
> 1) Enable patch through init param. That would mean you will have to set it
> in every application config if you want it to be enabled.
>
> 2) Enable patch by default, allow disabling it by init param. This is
> breaking backwards compatibility so you would have to add init param to
> "legacy" applications after upgrade.
>
> Do you have some comments, suggestions, .. ? Any feedback is welcomed.
>
> Regards,
>
> Pavel
>
>
> [1] https://jersey.dev.java.net/issues/show_bug.cgi?id=361 <
> https://jersey.dev.java.net/issues/show_bug.cgi?id=361>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>