[
https://issues.apache.org/jira/browse/MYFACES-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843184#action_12843184
]
Lincoln Baxter III commented on MYFACES-2590:
---------------------------------------------
Sure! Here's an example that I just ran across today:
http://www.seamframework.org/Community/PersistAndPassFacesMessagesOverMultiplePageRedirects?cid=2287109
The need for @Inject support in JSF artifacts is going to continue increasing,
and it's really a big setback now that we have CDI, which is a pervasive,
all-encompasing tool. Really, by omitting this functionality in the JSF spec,
we've done a disservice to anyone who wants to use a DI/IoC container. It means
that they need to jump through hoops in order to get references to managed
beans and other injectable services in their JSF lifecycle artifacts.
As we all know, a lot of business logic goes in to custom phase listeners,
validators, converters; having access to CDI/@Inject and other annotations will
address a wide range of real-life use-cases (such as the one above.)
I personally know that I want to be able to @Inject my LoggedInUserBean into my
LoggedInUserPasswordValidator -- but I have to access it much like David
accesses his MessagesRevival bean.
Does that help?
> Web Container injection support should be provided for additional lifecycle
> artifacts (not just managed beans)
> --------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2590
> URL: https://issues.apache.org/jira/browse/MYFACES-2590
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
> Environment: ALL
> Reporter: Lincoln Baxter III
>
> JSF implementations should treat the following framework components as JEE
> components, and pass them through the default WebInjectionProvider.inject()
> method part of any instantiation process. E.g: Whether or not the framework is
> instantiating the object for it's use, or the user is asking the framework
> for a
> new instance.
> The benefit: This means that any container provided injection points would
> automatically be available in the following artifacts:
> * ManagedBean
> * PhaseListener
> * SystemEventListener
> * Converter
> * Validator
> * ... more?
> For extension writers:
> Support for native container-injection for all artifacts defined in
> section 11.4.6 of the JSR-314 spec.
> ■ ActionListener
> ■ ApplicationFactory
> ■ FacesContextFactory
> ■ LifecycleFactory
> ■ NavigationHandler
> ■ PropertyResolver
> ■ RenderKit
> ■ RenderKitFactory
> ■ ResourceHandler
> ■ StateManager
> ■ VariableResolver
> ■ ViewHandler
> There is a related SPEC issue, Mojarra enhancement, and GlassFish bug also
> involved in getting this
> standardized across the board:
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=763
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=11655
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1578
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
