- h:commandButton does not support onclick in certain versions of JSF (1.0 at least)
- Many issues with nested h:dataTables containing h:commandButton or h:commandLink
- Issues binding the rendered attribute to an expression that involves request-scoped data. Important to note with binding expressions on the rendered attribute is that if a component is not rendered, it is not part of the tree at the time actions are evaluated. We ran into a number of strange cases with h:commandLink or commandButtons nested inside dynamically rendered components. If the parent component didn’t evaluate to rendered=”true” at the time the “Invoke Application” phase occurred, the action wouldn’t fire.
- Many, many cases where native JSF logging is insufficient to describe what is actually going on when something doesn’t work as expected. This includes: commands not firing, validation not working, validation failures (with, in some cases, nothing going into FacesMessage), many many many NullPointerExceptions (or other exceptions) from the JSF code when incorrect value expressions are provided.
- Errors in the faces-config file will not always be caught or reported in meaningful ways. We ran into many cases where missing brackets or simple typos would result in meaningless exceptions.
- Obviously, the usual issues around use of arbitrary HTML in JSF 1.x applications.

That said, the application was very complex, and once we worked our way around some of the weird issues of JSF, some of the component magic was actually very helpful.

I think one of the big issues that developers have with JSF is that understanding the request and component lifecycle (and its bugs and quirks in implementation) can be very difficult to wrap your head around.

Beans should be request-scoped by default, and changed to session scoped only if you want to share data between requests.

If you have an application-scoped bean, data stored in that bean will be shared between ALL users.

That’s not impossible if you ensure that EL evaluted on <b>h:dataTable</b> from the managed bean on request-scope always will return the same value.

Form-level validations are a catch-22. If you perform them in an action method, where it is convenient to compare values, the validation phase has already completed.

From an action method, when validating values contained in a data table, it is virtually impossible to generate faces messages for a component (in a certain table row), and to set that component’s invalid attribute.

On the other hand, when performing form-level validations during the validation phase, it is difficult to obtain the values of the other components on the page. Again, when dealing with a data table the problem is compounded.

As another example, validations are not invoked if a field is empty. This makes is extremely complicated to implement common validations such as comparing two fields (e-mails, passwords).

One last example: implementing validations for unique constraints.

All of these difficulties are essentially undocumented, although, to be fair, “Core Java Server Faces” and “JSF Complete Reference”, do discuss them to some extent.

public clas JSFBean{
@Inject
private transient Service service;

@PostConstruct
void post(){

getInjector.inject(this);
}
}

1) In my opinion the spec isn’t clear enough about that. The javadoc is also misleading.

2) f:setPropertyActionListener is (logically) also bound to that behavior and I believe its benefit is much reduced because o that. Take the typical usecase of deleting a row in a table using a button, you need to be able to manipulate the row in the actionListener behind the button. Maaaany people try and discover that they can’t use setPropertyActionListener to set the row in a defined variable. It would be set too late, after the listener is called. Instead developers must use in their listener: ((UIData)actionEvent.getComponent()).getRowData() and cast the result again… “Why do easy when you can to difficult?” as some say.