javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-608

dependency injection does not work on properties without a setter

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.1
    • Fix Version/s: 2.2
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      608
    • Status Whiteboard:
      Hide

      size_medium importance_large

      Show
      size_medium importance_large

      Description

      [copied from issue 1247 of mojara-JSF2-RI at javaserverfaces.dev.java.net]

      The following behaviour should be unified/fixed as as a convenience for the
      programmers and to fully follow the 'ease of configuraton' approach of JSF-2.

      Backingbeans can be considered as a glue and wiring tier between user interface
      and persistence layer (at least for many cases where there is no complex
      business logic in between). So in practice, there are dependencies on both
      flavours of JavaEE classes: JPA entities and JSF beans or components. Look at
      the following code:

      ------ code snippet of a backing bean:

      @EJB
      private IEntityServiceLocal entityService;

      @ManagedProperty(name = "bom", value = "#

      {applicationScope['bom']}

      ")
      private XmlDocument bom;

      ------ end code snippet

      Referencing the backing bean in an XHTML page causes an exception being raised
      from the JSF subsystem:

      Unable to create managed bean XYZ. The following problems were found:

      • Property bom for managed bean XYZ does not exist.

      whereas there is no problem with the short notation of the EJB dependency, no
      need for a setter.

      With an explicite implementation of the setter for the JSF managed property:

      // ,,,FH looks like a setter is needed for JSF managed property!
      // (JPA doesn't need setters for dependency injection, even for private fields)
      public void setBom(XmlDocument bom) {
      this.bom = bom;
      }

      the backing bean is instantiated correctly.

      Not only because of the typing effort, but also because of the discrepancy
      between the handling of the two cases (JPA injection vs. JSF injection) the
      behaviour is a litte bit annoying and for the sake of happy and efficient
      programmers, IMHO this should be unified (i.e. setter method should not be
      required for JSF managed properties, unless they are supposed to be modified by
      other means than JSF dependency injection at instantiation time).

      Some remarks:

      1) It is possible and common use to have read-only properties of backing beans
      with only a getter method (value is set from inside the bean with constructor or
      as a side effect of another method). Thus the missing setter is not unusual.

      2) I cannot remember, whether a setter method was required in the JSF-1.2 days
      when setting managed properties was done via the faces-config file.

        Activity

        Hide
        Ed Burns added a comment -

        triage

        Show
        Ed Burns added a comment - triage
        Hide
        Ed Burns added a comment -

        2.1

        Show
        Ed Burns added a comment - 2.1
        Hide
        Ed Burns added a comment -

        GlassFish 3.1 M6 at the latest.

        Show
        Ed Burns added a comment - GlassFish 3.1 M6 at the latest.
        Hide
        Ed Burns added a comment -

        Move these to 2.2

        Show
        Ed Burns added a comment - Move these to 2.2
        Hide
        Ed Burns added a comment -

        This is now a CDI concern.

        Show
        Ed Burns added a comment - This is now a CDI concern.

          People

          • Assignee:
            Unassigned
            Reporter:
            frankwhofmann
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: