jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] [1311-FacesContextCDI] Let CDI handle #{facesContext}

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 7 Oct 2014 10:59:35 +0200

Hi,

On Monday, October 6, 2014, Edward Burns <edward.burns_at_oracle.com> wrote:
>
> You are right that prior to JSF 2.3, it was possible to use a subset of
> JSF features on containers that did not provide CDI. We are indeed
> proposing to change that in JSF 2.3, making CDI required. This change
> is most strongly articulated in [1287-RedefineManagedBeansAsCDIBeans].


I think this is a very good move. Other specs seem to be moving in a
similar direction, eg if I'm not mistaken JAX-RS stated that their
injection/bean handling will be delegated to CDI as well, JTA a while back
based their new @Transactional functionality on CDI and I think
Interceptors etc.

All in all this consolidates the Java EE platform and gives it a more
uniform feel, both to users and implementors.

It's also not unprecedented to have a mandatory dependency on another Java
EE spec, eg JSF has depended on Servlet from the very beginning.

For what it's worth, at OmniFaces we had a poll running for a while that
asked users how they felt about a mandatory CDI dependency for OmniFaces.
With 185 responses, a majority of 61% voted in favor of it (see
http://arjan-tijms.omnifaces.org).

I think it's likely this number will only increase over time, and it's of
course still a few years away before JSF 2.3 is done and most people will
actually start using it.

Kind regards,
Arjan Tijms






> In addition to this change, we are also requiring Java EE 8 and Java SE
> 8 in order to run JSF 2.3.
>
> We realize these two changes are departures to our decade old policy of
> lagging one version behind the platform. We reasoned that if people
> have stuck with JSF for this long, they would be willing to move up to
> EE 8 as well.
>
> LU> I think CDI provides a pluggable API that works for our needs. The
> LU> only thing that I miss about that API is that you can't control class
> LU> scanning, and that causes problems because application servers
> LU> sometimes need to customize that part.
>
> Yes, this is one of those areas that CDI hasn't fully addressed yet.
> However, we believe we can mitigate the impact of this by not even
> saying anything about CDI's pluggable API.
>
> Ed
> --
> | edward.burns_at_oracle.com <javascript:;> | office: +1 407 458 0017
> | 24 work days til Devoxx 2014
>