What about @Inject vs. @resource to let CDI vs. JSF do the work?
--
Herzliche Grüße, best regards
Michael Müller
Am 9. Oktober 2014 15:36:41 MESZ, schrieb manfred riem <manfred.riem_at_oracle.com>:
>Hi all,
>
>Just a heads up I have reverted all the changes done so far, so now
>embarking on getting the changes done as described below.
>
>Thanks!
>Manfred
>
>On 10/8/14, 4:18 PM, manfred riem wrote:
>> Hi all,
>>
>> After working on
>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1311 it has
>> become clear to Ed and I that there is more work to be done so I have
>
>> temporarily reverted the work done for 1311 and I will now describe
>> what we think would be a good way forward.
>>
>> Use case #1 - Old applications prior to Servlet 4.0 / JSF 2.3
>>
>> Make sure this keeps working as usual without making it hard CDI
>> dependent. Which means we are not going to change in the EL
>resolvers,
>> the EL resolver chain or how the integration is currently done. This
>> will maintain our backwards compatibility.
>>
>> Use case #2 - New application wanting to use Servlet 4.0 / JSF 2.3
>>
>> 1. Required to either have a web.xml with version 4.0 or a
>> WEB-INF/faces-config.xml stating version 2.3, as this will activate
>> the new behavior.
>>
>> 2. Let CDI do most of the EL resolving, which means adding producers
>> for the old EL resolvers (e.g. ImplicitObject, Composite etc).
>>
>> 3. Rework the EL resolver chain to use the new CDI EL Resolver plus
>> any other EL resolvers that we need.
>>
>> 4. Define the default producers in a javax.faces package so they are
>> consistent between JSF implementations and allow for overriding.
>>
>> 5. By making it an opt-in the component vendor / developer will have
>> to support the new requirements if they want to take advantage of
>> these new capabilities.
>>
>> Comments, thoughts?
>>
>> Regards,
>> Manfred
>>
>>