Igor,

Thanks very much for your suggestion which I followed.

I have overridden it and that is an improvement but still not good.

ListDataProvider dataProvider = new ListDataProvider(myList){
    @Override
    public IModel<MyEntity> model(Object object)
    {
        return new DetachableMyEntityModel((MyEntity) object);
    }
};

SerializableChecker does a nice job spotting:

...
private final java.util.List
org.apache.wicket.markup.repeater.data.ListDataProvider.list[write:1]
[class=[Ljava.lang.Object;]

private final java.util.List
org.apache.wicket.markup.repeater.data.ListDataProvider.list[write:1][0]
[class=MyEntity] <----- field that is not serializable

I guess that private final List<T> list; of ListDataProvider wants to
be serialized into the session which we don't want?

I am trying to apply best practice - may be I should not be using
ListDataProvider?

http://old.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html

"instead of using listdataprovider you should use a dataprovider in
that uses detachablemodels for each individual item -igor "

Today, with 1.4, what is best to use for <List> results from
EntityManager? Still DataProvider?

Many thanks,

Bernard



On Thu, 5 Nov 2009 14:25:01 -0800, you wrote:

>you have to override listdataprovider#model and return a detachable model.
>
>-igor
>
>On Thu, Nov 5, 2009 at 2:19 PM,  <b...@actrix.gen.nz> wrote:
>> Hi,
>>
>> I am trying to prevent the leaking of business objects into the
>> session.
>>
>> Michael made a good comment in
>>
>> http://www.mail-archive.com/users@wicket.apache.org/msg31187.html
>>
>> "... you could e.g. temporarily remove the "Serializable" from your
>> model-classes and go spotting nonserializable exceptions until they
>> don't ocurr anymore."
>>
>> which is what I did.
>>
>> It works nicely until I hit a problem with ListDataProvider in
>> DataView, where I get an exception even if I use LDMs:
>>
>> java.lang.ClassCastException: MyEntyty cannot be cast to
>> java.io.Serializable at
>> org.apache.wicket.markup.repeater.data.ListDataProvider.model(ListDataProvider.java:35)
>>
>> It appears to me that the approach has a conflict with framework
>> classes.
>>
>> What is the best way to spot session memory issues without hitting
>> this problem?
>>
>> Many thanks,
>>
>> Bernard
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to