Igor,
Creating the list of entities exclusively inside iterator() requires
two database calls for retrieving a list for a single request, the
additional call being required for the size() method that is called
prior to iterator(). That is an unfortunate side effect of this API.
I don't have a problem with that as I work around it, as others have
done before me, by fetching the data eagerly with the size() method
and then caching it in a volatile field for use by iterator().
I just can't afford to make two database calls.
So I wonder, what is the situation with SerializableChecker
complaining about that volatile field not being Serializable. Is this
a bug or do I miss anything?
Should I use something else instead of IDataProvider?
Many thanks.
Bernard
On Thu, 5 Nov 2009 20:05:37 -0800, you wrote:
>you should create the list of entities inside iterator() call, not
>hold on to it in a field. see the phonebook example.
>
>-igor
>
>On Thu, Nov 5, 2009 at 7:06 PM, <b...@actrix.gen.nz> wrote:
>> Thanks again Igor.
>>
>> I have switched to plain IDataProvider as suggested, although I have
>> to admit that I still have to look at the phonebook example.
>>
>> Again, IDataProvider is an improvement, but still not good.
>>
>> It appears that SerializableChecker is complaining about a volatile
>> field not being Serializable. Is this a bug or do I miss anything?
>>
>> I think that SerializableChecker is a wondeful tool, that is why I am
>> persevering:
>>
>> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
>> Unable to serialize class: MyEntity
>>
>> ...
>> private volatile java.util.List MyEntityDataProvider.entities
>> [class=java.util.Vector]
>>
>> ...
>>
>>
>> public class MyEntityDataProvider implements IDataProvider<MyEntity>{
>>
>> private final Integer searchId;
>> private volatile List<MyEntity> entities;
>>
>> public MyEntityDataProvider(Integer searchId) {
>> this(searchId, null);
>> }
>>
>> public MyEntityDataProvider(Integer searchId, List<MyEntity>
>> entities) {
>> this.searchId = searchId;
>> this.entities = entities;
>> }
>>
>> �...@override
>> public Iterator<MyEntity> iterator(int first, int count)
>> {
>> return entities.iterator();
>> }
>>
>> �...@override
>> public int size()
>> {
>> if(this.entities == null){
>> SessionLocal sessionBean = MyApplication.getSessionBean();
>> this.entities = sessionBean.getMyEntities(this.searchId);
>> }
>> return this.entities.size();
>> }
>>
>> �...@override
>> public IModel<MyEntity> model(MyEntity entity)
>> {
>> return new DetachableMyEntityModel(entity);
>> }
>>
>> �...@override
>> public void detach()
>> {
>> }
>>
>> }
>>
>>
>>
>>
>> On Thu, 5 Nov 2009 18:30:20 -0800, you wrote:
>>
>>>no, you should not be using listdataprovider, it is only for static
>>>lists of things.
>>>
>>>if you want best practice look at the phonebook example in wicket-stuff.
>>>
>>>-igor
>>>
>>>On Thu, Nov 5, 2009 at 5:52 PM, <b...@actrix.gen.nz> wrote:
>>>> 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
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
