>>>>> On Mon, 6 Oct 2014 14:35:58 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> The problem is we introduce a dependency in CDI for JSF, unless we get
Well, we're not *introducing* a dependency. We are adding more weight
to a dependency we already have.
LU> There is no real advantage to do that. As far as I remember, CDI is an
LU> optional dependency, even if there are classes in JSF that use CDI
LU> api, you can run JSF without CDI. Does that will change with JSF 2.3?
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].
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 | office: +1 407 458 0017
| 24 work days til Devoxx 2014