I would agree with Arjan on this. I think @resource is not explicitly
clear. @Inject tells you exactly what is going to happen.
John
____________________________
John Yeary
____________________________
*NetBeans Dream Team*
*President Greenville Java Users GroupJava Users Groups Community
LeaderJava Enterprise Community Leader*
____________________________
<
http://javaevangelist.blogspot.com/> <
https://twitter.com/jyeary>
<
http://www.youtube.com/johnyeary> <
http://www.linkedin.com/in/jyeary>
<
https://plus.google.com/112146428878473069965>
<
http://www.facebook.com/jyeary>
<
http://feeds.feedburner.com/JavaEvangelistJohnYearysBlog>
<
http://netbeans.org/people/84414-jyeary>
"Far better it is to dare mighty things, to win glorious triumphs, even
though checkered by failure, than to take rank with those poor spirits who
neither enjoy much nor suffer much, because they live in the gray twilight
that knows not victory nor defeat."
-- Theodore Roosevelt
On Thu, Oct 9, 2014 at 11:01 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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>:
>>>
>>> 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
>>>
>>>
>>>
>>>
>
>
>
>