Skip to main content

[jsr362-observers:] [jsr362-experts:] Re: Backwards compatibiity

  • From: Kito Mann < >
  • To:
  • Subject: [jsr362-observers:] [jsr362-experts:] Re: Backwards compatibiity
  • Date: Mon, 12 Aug 2013 10:34:45 -0400
  • List-id: <jsr362-experts.portletspec3.java.net>

That makes sense to me. It's the opposite of what JSF does, but I think
it's actually better for developers in the long run.



___

Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com ;| JSF/Java EE training and consulting
http://www.JSFCentral.com ;| @jsfcentral
+1 203-998-0403

* Listen to the Enterprise Java Newscast:
*http://w<http://blogs.jsfcentral.com/JSFNewscast/>
ww.enterprisejavanews.com*
* JSFCentral Interviews Podcast:
http://www.jsfcentral.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17


On Mon, Aug 12, 2013 at 9:53 AM, Neil Griffin 
<
> wrote:

> Hi Kito,
>
> With the Portlet Spec, there is precedent for enabling
> non-backward-compatible changes by default. Portlet 2.0 introduced the
> "javax.portlet.escapeXml" container-runtime-option for backwards
> compatibility with Portlet 1.0. The default is "true", meaning the Portlet
> 2.0 non-backward-compatible "escaping" mechanism is enabled by default.
>
> I discussed it with my colleagues at Liferay and moving forward our
> company is in favor of enabling non-backward-compatible changes by default
> if the portlet.xml descriptor indicates "3.0". If this approach is adopted,
> then developers would have to set container-runtime-options in order to get
> backwards compatibility.
>
>
> Best Regards,
>
> Neil
>
> On Aug 7, 2013, at 12:44 PM, Kito Mann 
> < >
>  wrote:
>
> Hello everyone,
>
> Regarding backwards compatibility (as discussed yesterday), is there a
> standard pattern used to enable/disable new features across Java EE? For
> JSF, the general rule is that new functionality that breaks backwards
> compatibility is turned off by default, but can be changed on (on a
> feature-by-feature basis) via web.xml. Part of me thinks it should be the
> opposite, but I don't know if other Java EE JSRs use the same pattern.
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com ;| JSF/Java EE training and consulting
> http://www.JSFCentral.com ;<http://www.jsfcentral.com/> | @jsfcentral
> +1 203-998-0403
>
> * Listen to the Enterprise Java Newscast: 
> *http://w<http://blogs.jsfcentral.com/JSFNewscast/>
> ww.enterprisejavanews.com*
> * JSFCentral Interviews Podcast:
> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
>
>
>


[jsr362-observers:] [jsr362-experts:] Backwards compatibiity

Kito Mann 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: Backwards compatibiity

Werner Keil 08/07/2013

[jsr362-observers:] [jsr362-experts:] Re: Backwards compatibiity

Neil Griffin 08/12/2013

[jsr362-observers:] [jsr362-experts:] Re: Backwards compatibiity

Kito Mann 08/12/2013

[jsr362-observers:] [jsr362-experts:] Re: Backwards compatibiity

Werner Keil 08/12/2013
 
 
Close
loading
Please Confirm
Close