Hi Everyone,
If following the other specifications, the @Resource is used to specify a
resource on the server. As is the case with the Java EE Concurrency
utilities and others. Therefore, I agree that if @Resource were to be
utilized by JSF then it may muddy the waters and become confusing.
What about applying the @Vetoed annotation to resources to differentiate
which should be using JSF vs CDI? I understand (and agree) that JSF 2.3
and beyond should be taking advantage of CDI. However, there still may be
the case where one wishes to make use of the JSF runtime rather than CDI in
certain beans (perhaps for compatibility). Applying @Vetoed will allow CDI
to ignore the bean completely. Personally, I am already using CDI in most
of my solutions, but this would allow for more flexibility to those who are
not.
Thanks
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Thu, Oct 9, 2014 at 10:20 AM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> Hi John,
>
> I would like to push back on this by asking the question "Why it could not
> be done by adding a web.xml or faces-config.xml"?
>
> Manfred
>
>
> On 10/9/14, 10:13 AM, John Yeary wrote:
>
> Hello All,
>
> I like the new approach. This will allow users of the technology to keep
> up todate using a number of the new features without having to worry about
> a hard-fast requirement for CDI.
>
> It also allows users the opportunity to move forward with CDI, or
> migrate existing applications to CDI when appropriate.
>
> The changes using faces-config.xml are minimal.
>
> Do we want to have some functionality to allow it to be set
> programmatically? I have had some cases where I want to load a servlet,
> filter, etc. programmatically. I have found cases where there is some
> expectation of a file like web.xml existing, but since the servlet was
> loaded programmatically, certain configurations could not be set.
>
> John
>
> ____________________________
>
> John Yeary
> ____________________________
> *NetBeans Dream Team*
>
>
> *President Greenville Java Users Group Java Users Groups Community Leader
> Java 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 Wed, Oct 8, 2014 at 5:18 PM, manfred riem <manfred.riem_at_oracle.com>
> 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
>>
>>
>