Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Closed Closed
Resolution: Won't Fix
Priority: Critical Critical
Assignee: Unassigned
Reporter: frankwhofmann
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

dependency injection does not work on properties without a setter

Created: 11/Aug/09 02:07 PM   Updated: 24/Jan/14 08:42 PM   Resolved: 24/Jan/14 08:42 PM
Component/s: Uncategorized
Affects Version/s: 2.1
Fix Version/s: 2.2

Time Tracking:
Not Specified


Operating System: All
Platform: All

Issuezilla Id: 608
Status Whiteboard:

size_medium importance_large

Participants: Ed Burns and frankwhofmann

 Description  « Hide

[copied from issue 1247 of mojara-JSF2-RI at]

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 = "#{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) { = 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.

Ed Burns added a comment - 24/Sep/09 09:13 AM

Move to unscheduled target milestone

Ed Burns added a comment - 24/Nov/09 07:48 AM

Prepare to delete "spec" subcomponent.

Ed Burns added a comment - 24/Feb/10 10:04 AM

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.

Ed Burns added a comment - 04/Mar/10 01:37 PM

push to CDI

Ed Burns added a comment - 22/Jun/10 09:02 PM


Ed Burns added a comment - 22/Jun/10 09:44 PM


Ed Burns added a comment - 22/Jun/10 10:35 PM


Ed Burns added a comment - 24/Jun/10 02:41 PM

GlassFish 3.1 M6 at the latest.

Ed Burns added a comment - 10/Sep/10 01:31 PM

Move these to 2.2

Ed Burns added a comment - 24/Jan/14 08:42 PM

This is now a CDI concern.