流程验证时为selectManyCheckbox LazyInitializationException [英] selectManyCheckbox LazyInitializationException on process validation

问题描述

看来，如果使用由冬眠代理的集合作为后盾的selectManyCheckbox，则会遇到可怕的LazyInitializationException问题.这与备用bean的状态无关！

It appears that if you use a selectManyCheckbox backed by a set that is proxied by hibernate you will run into problems with the dreaded LazyInitializationException. This has nothing to do with the state of the backing bean!

在调试Mojarra 2.1之后，我发现如果不包括属性collectionType，它将在过程验证阶段尝试克隆支持值类，在我的情况下为PersistentSet.当然，为此添加任何值都将导致LazyInitializationException.

After debugging Mojarra 2.1 I discovered that if you do not included the attribute collectionType it will attempt to clone the backing value class in the process validations phase, which in my case is PersistentSet. Of course adding any value to this will cause a LazyInitializationException.

我的问题是，您是否认为在过程验证阶段这是合理的行为?

My question is whether you think this is reasonable behaviour at the process validations phase?

克隆收集类的更好算法是查看接口并从java.util实例化一个已知的类.

A better algorithm to clone the collection class would be to look at the interface and instantiate a known class from java.util.

推荐答案

这就是重点！它与会话状态无关. 我遇到了这个问题，可以通过在组件中添加以下内容(在我的情况下为selectManyMenu)来解决它:

Thats exactly the point! It has nothing todo with the session state... I've ran into this problem and I was able to solve it by adding the following within my component (in my case a selectManyMenu):

<f:attribute name="collectionType" value="java.util.ArrayList" />;

这篇关于流程验证时为selectManyCheckbox LazyInitializationException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！