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){
    public IModel<MyEntity> model(Object object)
        return new DetachableMyEntityModel((MyEntity) object);

SerializableChecker does a nice job spotting:

private final java.util.List

private final java.util.List
[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


"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,


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

>you have to override listdataprovider#model and return a detachable model.
>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