Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.1
    • Fix Version/s: 2.2 Sprint 8
    • Component/s: Managed Beans
    • Labels:
      None

      Description

      We should create a concept about what to do with the JSF managed bean mechanism with regard to CDI (JSR-299).

      Since CDI was created to handle JSF's managed bean mechanism better in the first place (remember: "webbeans") and since it is being used a lot already to handle managed beans in JSF web applications, we should think about what to do with JSF's own managed bean mechanism.

      The are some spec-issues in this tracker refering to improvements of the JSF managed bean mechanism, like e.g. new scopes (I saw @AccesScoped and something about @FlashScoped). However, we should think about if improving this mechanism is the right choice.

      Maybe a better idea is to deprecate JSF's managed bean mechanism (like we deprecated JSP support - meaning that we still support it, but do not create new features for it) and automatically map JSF managed bean annotations to CDI annotations at startup, if CDI is available (like MyFaces CODI or JBoss Seam are supporting already).

      For example:

      @javax.faces.bean.ManagedBean --> @javax.inject.Named
      @javax.faces.bean.SessionScoped --> @javax.enterprise.context.SessionScoped

      Also see [1] for a feature description.

      IMO you should not use JSF 2.x without CDI (at least if you're doing more than hello world).

      [1] https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-JSF2.0ScopeAnnotations

        Activity

        Hide
        Jakob Korherr added a comment -

        I totally agree with you, Andy. We absolutely should not force users into using CDI, Spring,... if they just want to do a very simple thing.

        However, deprecating JSF managed beans does not mean they will be completely removed from JSF. It means they will still be supported and will continue to work as they do right now. But it also means that there won't be any new features for it and thus, if you want new features, you have to use CDI (or Spring or ...).

        Show
        Jakob Korherr added a comment - I totally agree with you, Andy. We absolutely should not force users into using CDI, Spring,... if they just want to do a very simple thing. However, deprecating JSF managed beans does not mean they will be completely removed from JSF. It means they will still be supported and will continue to work as they do right now. But it also means that there won't be any new features for it and thus, if you want new features, you have to use CDI (or Spring or ...).
        Hide
        Ed Burns added a comment -

        Lots of the work in FacesModule from Seam3 <http://seamframework.org/Seam3/FacesModule> can be used for JSF 2.2.

        Show
        Ed Burns added a comment - Lots of the work in FacesModule from Seam3 < http://seamframework.org/Seam3/FacesModule > can be used for JSF 2.2.
        Hide
        arjan tijms added a comment -

        Java EE 6 greatly simplified working with the Java EE platform and it did a lot to align the various specifications, making it overall easier for people new to the platform.

        However, the fact that both JSF Managed Beans and CDI exist, with even annotations that have the same unqualified name (@RequestScoped, @SessionScoped, etc) makes it unnecessary confusing for beginners. I often see people annotating beans with a mix of JSF and CDI annotations, which of course doesn't give the expected result. This partly ruins the easy of programming theme from Java EE 6.

        Instead of mapping JSF annotations to CDI annotations, maybe JSF could actually use the CDI annotations directly and map these to JSF's managed bean facility instead when no CDI implementation is present?

        Going one step further, maybe an implementation like Mojarra could even offer a jsf-all.jar, that included Weld as its internal bean facility. The FacesServlet should then setup everything, so the end user would not have to add the Weld servlet listener nor the required empty beans.xml.

        Wouldn't a simple user-wanting-to-do-simple-things-with-just-JSF-&-Tomcat be virtually unaware of the fact that CDI was used in this situation instead of the internal JSF managed bean facility?

        Show
        arjan tijms added a comment - Java EE 6 greatly simplified working with the Java EE platform and it did a lot to align the various specifications, making it overall easier for people new to the platform. However, the fact that both JSF Managed Beans and CDI exist, with even annotations that have the same unqualified name (@RequestScoped, @SessionScoped, etc) makes it unnecessary confusing for beginners. I often see people annotating beans with a mix of JSF and CDI annotations, which of course doesn't give the expected result. This partly ruins the easy of programming theme from Java EE 6. Instead of mapping JSF annotations to CDI annotations, maybe JSF could actually use the CDI annotations directly and map these to JSF's managed bean facility instead when no CDI implementation is present? Going one step further, maybe an implementation like Mojarra could even offer a jsf-all.jar, that included Weld as its internal bean facility. The FacesServlet should then setup everything, so the end user would not have to add the Weld servlet listener nor the required empty beans.xml. Wouldn't a simple user-wanting-to-do-simple-things-with-just-JSF-&-Tomcat be virtually unaware of the fact that CDI was used in this situation instead of the internal JSF managed bean facility?
        Hide
        Ed Burns added a comment -

        Per long-standing JavaEE tradition, I will not deprecate the javax.faces.bean package in this version of the specification. I will announce that they may be deprecated in a future version of the specification with this text in the javadocs:

        The annotations in this package may be deprecated in a future version of this specification because they duplicate functionality provided by other specifications included in JavaEE. When possible, the corresponding annotations from the appropriate Java EE specification should be used in preference to these
        annotations.

        Also, note that there is no mention of this package in the spec PDF, and the javadoc text I mention above is actually a separate javadoc bundle from the rest of the JSF spec.

        Show
        Ed Burns added a comment - Per long-standing JavaEE tradition, I will not deprecate the javax.faces.bean package in this version of the specification. I will announce that they may be deprecated in a future version of the specification with this text in the javadocs: The annotations in this package may be deprecated in a future version of this specification because they duplicate functionality provided by other specifications included in JavaEE. When possible, the corresponding annotations from the appropriate Java EE specification should be used in preference to these annotations. Also, note that there is no mention of this package in the spec PDF, and the javadoc text I mention above is actually a separate javadoc bundle from the rest of the JSF spec.
        Hide
        Ed Burns added a comment -

        Sending jsf-api/src/main/resources/managed-bean-overview.html
        Sending jsf-api/src/main/resources/overview.html
        Transmitting file data ..
        Committed revision 9438.

        Show
        Ed Burns added a comment - Sending jsf-api/src/main/resources/managed-bean-overview.html Sending jsf-api/src/main/resources/overview.html Transmitting file data .. Committed revision 9438.

          People

          • Assignee:
            Ed Burns
            Reporter:
            Jakob Korherr
          • Votes:
            21 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1 week, 6 days
              1w 6d
              Remaining:
              Time Spent - 1 day, 7 hours, 26 minutes Remaining Estimate - 1 week, 4 days, 16 hours, 34 minutes
              1w 4d 16h 34m
              Logged:
              Time Spent - 1 day, 7 hours, 26 minutes Remaining Estimate - 1 week, 4 days, 16 hours, 34 minutes
              1d 7h 26m