jsf 2 - Wrong selected option for selectOneMenu with POJOs and Converter

Question

in our company we're hitting a serious problem which we think is a serious design flaw of the JSF spec, if it is the normal behavior.

This is our usecase:

• SelectOneMenu (standard JSF or primefaces, doesn't matter, same behavior)
• SelectItems with a database entity as it's value and a string as the label
• A converter (via attribute on the selectOneMenu) which translates the entity to its ID (getAsString) and from the ID to the entity (getAsObject)

Everything works as expected as long as the entity inside the value attribute of the selectOneMenu is loaded using the same entityManager as the entities inside the selectItems. We have the same POJOs and therefore the same hashcode (Object#equals() returns true). But as soon as one of the entities is loaded via a different entityManager and therefore has a different hashcode, we are never able to get a match to generate the expected selected attribute of an select item (HTML <option /> ).

The cause of this behavior is, that the JSF-impl and primefaces both use the POJOs in the call

boolean selected = isSelected(context, menu, itemValue, valuesArray, converter);

for itemValue and valuesArray. The implementation of isSelected relies on Object#equals() for POJOs. In my opinion it should always use the value of Converter#getAsString if we have a Converter and pass it to isSelected. This is also the behavior for a POST request. Here we got a submittedValue for the selectOneMenu which is compared to the converted value of the POJO (Converter#getAsString).

Now the question: Is this the expected behavior as it's described in the spec? Isn't the output of the converter the better way to handle this comparision? Now we have to modify our entity classes and overwrite the equals method to be able to use this construct.

Answer 1

Your mistake is that you forgot to implement/autogenerate equals() (and hashCode()) method conform the contract. This is beyond control of JSF. Pointing the accusing finger to JSF isn't making any sense.

It's handy to have a base entity where all your entities extend from so that you don't need to repeat the task over all entities (even though the average IDE/tool can easily autogenerate them). You can find an elaborate example in 2nd "See also" link.

See also:

• Validation Error: Value is not valid
• Implement converters for entities with Java Generics