I don't know whether having compatibility mode is good idea. I can see
your point but this could result in having almost separate branch for
"legacy" stuff and I can imagine that maintaining could be difficult.
Additionally this approach may introduce init params for fixes which
would not need it without compatibility mode. Additionally this would
start another discussions which new feature should be enabled by default
and which are going to be activated just by init parameter.. this may
cause some additional confusion.
I was inclining more towards option 2, on the other side Paul wants to
keep jersey backwards compatible as possible. Now I'm starting to agree
with Paul with one TODO item for us: make a proper documentation about
jersey init params, which is be easily findable for users..
Maybe we should discuss this again when releasing Jersey 2.0 (or
different major release; we surely don't want have lots of init params
for "standard" applications)..
Paul, do you have any aditional comments/thoughts about this?
Pavel
Trolly Rogers wrote:
> 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
> <mailto: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
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
>
>