MyFaces Core
  1. MyFaces Core
  2. MYFACES-2590

Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: JSR-314
    • Labels:
      None
    • Environment:
      ALL

      Description

      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

        Activity

        Hide
        Jakob Korherr added a comment -

        Can you explain this a little further please, Lincoln? For example what use cases do you see in this?

        Show
        Jakob Korherr added a comment - Can you explain this a little further please, Lincoln? For example what use cases do you see in this?
        Hide
        Lincoln Baxter III added a comment -

        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?

        Show
        Lincoln Baxter III added a comment - 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?
        Hide
        Jakob Korherr added a comment -

        Hmm OK. This is actually not bad

        I personally really like CDI. I think it's a very great technique and it spares you lots of boilerplate code.

        Unfortunately, this will by no means get into the JSF 2.0 spec, I think. Maybe in JSF 2.NEXT but who knows.. However, I'll take a look at this, because it just seems right and it's a nice feature!

        Show
        Jakob Korherr added a comment - Hmm OK. This is actually not bad I personally really like CDI. I think it's a very great technique and it spares you lots of boilerplate code. Unfortunately, this will by no means get into the JSF 2.0 spec, I think. Maybe in JSF 2.NEXT but who knows.. However, I'll take a look at this, because it just seems right and it's a nice feature!
        Hide
        Gerhard Petracek added a comment -

        some parts are already covered by codi and some others aren't mentioned here but users see use-cases for injection in ExceptionHandler and UIComponent (see e.g. http://goo.gl/lYbaZ)

        however, since @Inject is specified in jsr330 it's imo more difficult than just providing an integration for cdi.

        Show
        Gerhard Petracek added a comment - some parts are already covered by codi and some others aren't mentioned here but users see use-cases for injection in ExceptionHandler and UIComponent (see e.g. http://goo.gl/lYbaZ ) however, since @Inject is specified in jsr330 it's imo more difficult than just providing an integration for cdi.

          People

          • Assignee:
            Unassigned
            Reporter:
            Lincoln Baxter III
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development