Hi,
On Thursday, October 9, 2014, Michael Müller <
michael.mueller_at_mueller-bruehl.de> wrote:
> What about @Inject vs. @resource to let CDI vs. JSF do the work?
>
I always felt @resource is a bit of a confusing and too much overloaded
annotation.
It also seems to bring with it visions of admins having to mandatory
administer whatever it is that's injected. This may not be entirely just
but seems to be the common perception.
Kind regards,
Arjan Tijms
>
> --
> Herzliche Grüße, best regards
> Michael Müller
>
> Am 9. Oktober 2014 15:36:41 MESZ, schrieb manfred riem <
> manfred.riem_at_oracle.com
> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>>
>>