fetchtype.LAZY results in JSF validation error

[roeber]

I found out that setting fetchtype.LAZY on a manyToOne association results in a JSF validation error for an selectOneMenu component.

@ManyToOne(fetch=FetchType.LAZY)
public OrgUnit getOrgUnit() {
return orgUnit;
}

<t:selectOneMenu id="orgunit" required="true" value="#{activity.orgUnit}" converter="orgunitconverter">
<f:selectItems value="#{selectitemservice.orgUnitChoices}"/>
</t:selectOneMenu>

public Object getAsObject(FacesContext context, UIComponent comp,
 String value) throws ConverterException {

 if (!StringUtils.isNumeric(value))
 return null ;

 Long id = Long.valueOf(value);
 Object object = em.find(OrgUnit.class, id);

 return object ;
}

public String getAsString(FacesContext context, UIComponent component,
 Object object) throws ConverterException {

 if (object == null) {
 return null;
 }
 if (object instanceof OrgUnit) {
 OrgUnit orgUnit = (OrgUnit)object ;
 String returnString = orgUnit.getId().toString();
 return returnString;
 }
 return null ;
}

The converter for OrgUnit seems to work: All units are displayed in the drop-down box and the current unit is also selected correctly in the box.
But submitting a page with this component shows a validation error saying: "orgunit": Value is not a valid option.
There are many things which could go wrong on my side but just removing the 'fetch=fetchtype.LAZY' (and therefore implicitly changing fetchtype to EAGER) results in a perfect working dialog. I suspect the use of a proxy for lazy fetching in Hibernate causing this, but debugging and tracing the converter and equals methods doesn't help me.

Any ideas would be appreciated.

--
Axel

[pmuir]

Some suggestions:

1) Association fetching in Hibernate is lazy by default AFAIK
2) How are you getting the EntityManager in your converter? I had problems with getting a reference to the EntityManager from JNDI and found that getting an EntityManagerFactory from JNDI worked better (otherwise the entity became detached)
3) '"xxx": Value is not a valid option' validation error occurs because the newly submitted converted selection is not a member of the original list. Have you overridden equals() on the OrgUnit so that it uses Id equality rather than object equality (you create a new OrgUnit from the database when you em.find()).
4) You could try the EntityConverter as it does this all for you for any EJB3 entity.

HTH

[roeber]

Thx for your suggestions. Encouraged by your suggestion 3 I have debugged my overridden equals method once again (ignoring the tracing output). What I found out:
other.name is null where it shouldn't be null. Changing this line to other.getName() fixed the problem!

public boolean equals(Object obj) {
 if (this == obj)
 return true;
 if (obj == null)
 return false;
 if (!(obj instanceof OrgUnit))
 return false;
 final OrgUnit other = (OrgUnit) obj;
 if (name == null) {
 if (other.name != null)
 return false;
 } else if (!name.equals(other.name))
 return false;
 return true;
}

"petemuir" wrote:

1) Association fetching in Hibernate is lazy by default AFAIK

Are you sure? This would make things strange anymore.

But now I know that this is an Hibernate issue - not a Seam issue.
Thanks!

[pmuir]

"roeber" wrote:

"petemuir" wrote:

1) Association fetching in Hibernate is lazy by default AFAIK

Are you sure? This would make things strange anymore.

Yep.

http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#d0e1570
http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-fetching-lazy

[mustaghattack]

3) '"xxx": Value is not a valid option' validation error occurs because the newly submitted converted selection is not a member of the original list. Have you overridden equals() on the OrgUnit so that it uses Id equality rather than object equality (you create a new OrgUnit from the database when you em.find()).

Using Id equality is not recommended AFAIK (http://www.hibernate.org/109.html)

[asavitsky]

"petemuir" wrote:

"roeber" wrote:

"petemuir" wrote:

1) Association fetching in Hibernate is lazy by default AFAIK

Are you sure? This would make things strange anymore.

Yep.

http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#d0e1570
http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-fetching-lazy

Nope.
Quoting from the first link (section 2.2.5.5):

@OneToMany and @ManyToMany associations are defaulted to LAZY and @OneToOne and @ManyToOne are defaulted to EAGER

and he had a @ManyToOne in his code, which is EAGER by default, not LAZY.