-2

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.

grubi
  • 155
  • 2
  • 16

2 Answers2

3

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:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thanks. I still believe, that using the converter in both cases is the better approach as it is more consistent. We already have implemented the overrides as the "solution" of this problem, but I'm not really happy with this behavior. – grubi Dec 06 '13 at 12:17
  • Without it, you'd also face trouble anywhere else where those are used as "javabeans", such as being collected in a `Set`. – BalusC Dec 06 '13 at 12:23
  • I'm currently testing your approach and implemented equals()/hashCode() but now we have a new problem. We're hitting a lazy initialization exception when one of those methods is invoked and the (foreign) entity was not loaded. Any suggestions on this? We're using hibernate 4.1.6.Final as JPA provider. – grubi Apr 13 '15 at 11:58
  • @grubi: For entities, you'd better compare by class+PK instead of all fields. See also last "See also" link for a concrete example. – BalusC Apr 13 '15 at 12:03
  • It triggers the lazy loading before the equals() method is really invoked. The method itself is implemented comparing the class and the ID (PK). This was done using the meta attribute _use-in-equals_ of hibernate's revenge feature. – grubi Apr 13 '15 at 12:16
  • 1
    @grubi: I've never seen this problem. You'd better ask a new question targeted at Hibernate/JPA folks. – BalusC Apr 13 '15 at 12:21
0

I believe that this is the correct behavior. On Java side the values of the component and selection are POJOs. You have full control of the logic of their equality etc. It should not matter how it is converted to UI display and back. As a component user you should not bother to know how the POJO is displayed. As text, icon, color, whatever. The Java side of the component undestands and communicats with POJOs

   YOUR CODE ----------> JAVA COMPONENT --------> CONVERTER ----------> HTML

Also I guess that relying on reference equality for entities is a road to problems. Setting equals/hashCode to use actual ID is the best approach.

Piotr Gwiazda
  • 12,080
  • 13
  • 60
  • 91