[JAVASERVERFACES_SPEC_PUBLIC-608] dependency injection does not work on properties without a setter Created: 11/Aug/09  Updated: 24/Jan/14  Resolved: 24/Jan/14

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Critical
Reporter: frankwhofmann Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 608
Status Whiteboard:

size_medium importance_large


[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:

private IEntityServiceLocal entityService;

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


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.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 24/Feb/10 ]

I'd like to have it in, but does it pass the Bill test:

B> That's not appropriate for an MR. It's a new requirement on an
B> implementation, not a clarification of existing requirements.

I'll ask him.

Comment by Ed Burns [ 04/Mar/10 ]

push to CDI

Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 22/Jun/10 ]


Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 24/Jan/14 ]

This is now a CDI concern.

Generated at Fri Aug 26 08:20:23 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.