UISelectMany in ui:repeat causes java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.util.List

萝らか妹 提交于 2019-12-05 18:50:11
BalusC

As hinted in the related question UISelectMany on a List<T> causes java.lang.ClassCastException: java.lang.String cannot be cast to T, generic type arguments are unavailable during runtime. In other words, EL doesn't know you have a Map<String, List<Item>>. All EL knows is that you have a Map, so unless you explicitly specify a converter for the selected values, and a collection type for the collection, JSF will default to String for selected values and an object array Object[] for the collection. Do note that the [ in [Ljava.lang.Object indicates an array.

Given that you want the collection type to be an instance of java.util.List, you need to specify the collectionType attribute with the FQN of the desired concrete implementation.

<h:selectManyMenu ... collectionType="java.util.ArrayList">

JSF will then make sure that the right collection type is being instantiated in order to fill the selected items and put in the model. Here's a related question where such a solution is being used but then for a different reason: org.hibernate.LazyInitializationException at com.sun.faces.renderkit.html_basic.MenuRenderer.convertSelectManyValuesForModel.


Update: I should have tested the above theory. This doesn't work in Mojarra when the collection behind collectionType is in turn wrapped in another generic collection/map. Mojarra only checks the collectionType if the UISelectMany value itself already represents an instance of java.util.Collection. However, due to it being wrapped in a Map, its (raw) type becomes java.lang.Object and then Mojarra will skip the check for any collectionType.

MyFaces did a better job in this in its UISelectMany renderer, it works over there.

As far as I inspected Mojarra's source code, there's no way to work around this other way than replacing Map<String, List<Long>> by a List<Category> where Category is a custom object having String name and List<MyObject> selectedItems properties. True, this really kills the advantage of Map of having dynamic keys in EL, but it is what it is.

Here's a MCVE using Long as item type (just substitute it with your MyObject):

private List<Category> categories;
private List<Long> availableItems;

@PostConstruct
public void init() {
    categories = Arrays.asList(new Category("one"), new Category("two"), new Category("three"));
    availableItems = Arrays.asList(1L, 2L, 3L, 4L, 5L);
}

public void submit() {
    categories.forEach(c -> {
        System.out.println("Name: " + c.getName());

        for (Long selectedItem : c.getSelectedItems()) {
            System.out.println("Selected item: " + selectedItem);
        }
    });

    // ...
}

public class Category {

    private String name;
    private List<Long> selectedItems;

    public Category(String name) {
        this.name = name;
    }

    // ...
}

<h:form>
    <ui:repeat value="#{bean.categories}" var="category">
        <h:selectManyMenu value="#{category.selectedItems}" converter="javax.faces.Long">
            <f:selectItems value="#{bean.availableItems}" />
        </h:selectManyMenu>
    </ui:repeat>
    <h:commandButton value="submit" action="#{bean.submit}">
        <f:ajax execute="@form" />
    </h:commandButton>
</h:form>

Do note that collectionType is unnecessary here. Only the converter is still necessary.

Unrelated to the concrete problem, I'd like to point out that selectedItemMap.entrySet().forEach(entry -> { String key ...; List<Item> items ...;}) can be simplified to selectedItemMap.forEach((key, items) -> {}) and that ItemListValidator is unnecessary if you just use required="true" on the input component.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!