s:selectItems and subclasses

[mschmidke]

Hello all,

I'm not quite sure whether this is a seam problem or a general JSF problem, but perhaps you can help me.

I have problems getting the right h:selectOneMenu highlighted caused by Hibernate proxy class hierarchie.

I am using a h:selectOneMenu together with s:selectItems and s:convertEntity.

The objects displayed are from a class hierarchie, say,

abstract class A
class B extends A
class C extends A

, which are EJB3 entities.

The list which is displayed (the selectitems) are some entities of class B or C.

The object which is selected is a lazy loaded reference from some other entity, so that in fact, the displayed object is not an instance of B or C but an instance of Proxy-For-A ("A_$$_javassist_77" or so).

com.sun.faces.renderkit.html_basic.MenuRenderer.renderOption() now tries to determine for every object in the list whether it is selected. To check the selected state, it first tries to coerce the current iterated value to the type of the selected value, i.e. from B to Proxy-For-A, before it does an equals() compare.

Of course, this leads to an exception, which is silently ignored and no object is displayed as selected.

Any ideas??


Marcus.

[pmuir]

What version of Seam. Lets see the exception stack trace.

[mschmidke]

Seam Version is 2.0.0.CR1.
JSF RI from JBoss 4.2.

No stack trace available since the exception is silently caught.

Have a look at JSF RI MenuRenderer.java lines 535 ff:

 try {
 newValue = context.getApplication().getExpressionFactory().
 coerceToType(itemValue, type);
 } catch (Exception e) {
 // this should catch an ELException, but there is a bug
 // in ExpressionFactory.coerceToType() in GF
 newValue = null;
 }

So, I think it is not a bug of Seam, but it is a limitation of JSF which appears when using Seam UI components (it might appear without Seam, but it will appear with Seam), and since Seam is nothing but repairing things which are missing in the other frameworks, it would be nice if Seam could repair even this.

I have worked around this by replacing the MenuRenderer class, changing getCurrentSelectedValues() method: Instead of

if (size > 0) {
 // get the type of the first element - Should
 // we assume that all elements of the List are
 // the same type?
 return list.toArray((Object[]) Array.newInstance(
 list.iterator().next().getClass(),
 size));
} else {
 return ((Collection) value).toArray();
}

I have

if (size > 0) {
 // get the type of the first element - Should
 // we assume that all elements of the List are
 // the same type?
 return list.toArray((Object[]) Array.newInstance(
 getObjectClass(list.iterator().next()),
 size));
} else {
 return ((Collection) value).toArray();
}

with

private Class getObjectClass(Object o) {
 Class r = o.getClass();
 if (r.getName().contains("$$")) {
 r = r.getSuperclass();
 }
 return r;
}

This method changes the class from "Proxy-For-A" to "A", so that even Bs and Cs may match.

This is clearly a hack, but for the moment, it works for me.

[pmuir]

Please open a JIRA issue. I shall use it to track a discussion with the JSF RI team to see if we can improve this.

[mschmidke]

Please open a JIRA issue.

Perhaps this is a little off topic, but I do not seem to have the permission to create new issues on jira.jboss.org. What can I do?

Marcus.

[pmuir]

log into jira using the same account you use to log in to jboss.com for the forums