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

[jsr372-experts] Re: [1315-ELResolvingByCDI] Simplify EL resolver chain by using CDI

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 22 Oct 2014 12:59:50 -0700

>>>>> On Thu, 9 Oct 2014 11:13:55 -0400, John Yeary <johnyeary_at_gmail.com> said:

JY> Do we want to have some functionality to allow it to be set
JY> programmatically? I have had some cases where I want to load a servlet,
JY> filter, etc. programmatically. I have found cases where there is some
JY> expectation of a file like web.xml existing, but since the servlet was
JY> loaded programmatically, certain configurations could not be set.

>>>>> On Thu, 09 Oct 2014 10:20:53 -0500, manfred riem <manfred.riem_at_oracle.com> said:

MR> Hi John,
MR> I would like to push back on this by asking the question "Why it could
MR> not be done by adding a web.xml or faces-config.xml"?

Also, we have the JSF 2.2 feature ApplicationConfigurationPopulator [1].
However, ApplicationConfigurationPopulator would probably not fit the
bill exactly here because Manfred and I wanted to place the additional
requirement that, if you opting in to JSF 2.3 using faces-config.xml, it
must be *THE* WEB-INF/faces-config.xml file.

If we wanted to enable using ApplicationConfigurationPopulator for the
opt-in, we could say that if *any* of the Application Configuration
Resources loaded via that mechanism do the opt-in, then the app is
considered to be as if *THE* WEB-INF/faces-config.xml had the opt-in.

Is that ok?

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 12 work days til Devoxx 2014
[1] http://docs.oracle.com/javaee/7/api/javax/faces/application/ApplicationConfigurationPopulator.html