Re: Serializable check
Thanks very much!
As pointed out, I was incorrectly using the keyword volatile instead
of transient. All is well now with IDataProvider and
SerializableChecker.
SerializableChecker is great!
Bernard
On Thu, 5 Nov 2009 22:30:59 -0800, you wrote:
>class mydataprovider implements idataprovider {
> private transient list cache;
> private list getresult() {
> if (cache==null) {
>// load the list from db;
>cache=list;
>} return cache;
> }
>
> public iterator iterator() { return getresult().iterator(); }
> public int size() { return getresult().size(); }
> public void detach() { cache=null; }
>}
>
>-igor
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Serializable check
class mydataprovider implements idataprovider {
private transient list cache;
private list getresult() {
if (cache==null) {
// load the list from db;
cache=list;
} return cache;
}
public iterator iterator() { return getresult().iterator(); }
public int size() { return getresult().size(); }
public void detach() { cache=null; }
}
-igor
On Thu, Nov 5, 2009 at 8:25 PM, wrote:
> 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, 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{
>>>
>>> private final Integer searchId;
>>> private volatile List entities;
>>>
>>> public MyEntityDataProvider(Integer searchId) {
>>> this(searchId, null);
>>> }
>>>
>>> public MyEntityDataProvider(Integer searchId, List
>>> entities) {
>>> this.searchId = searchId;
>>> this.entities = entities;
>>> }
>>>
>>> �...@override
>>> public Iterator 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 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, 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 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 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 results from
> EntityManager? Still DataProvider?
>
> Many thanks,
>
Re: Serializable check
I think the problem is that you are using the "volatile" keyword when you should be using "transient". bht wrote: > > 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? > -- View this message in context: http://old.nabble.com/Transactions-with-RuntimeException-tp26220780p26227378.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Serializable check
Hi James, Thanks for the question. In this case, yes. In other cases where I use IDataProvider, no. I know that IDataProvider provides functionality for pagination which I don't use here, that is why I ignored it. I must admit I have a few issues with IDataProvider but I don't want to distract from the original issue. 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? I just want to retrieve a list from the database, display it in a table while not having to deal with fake Serializable issues when I remove the Serializable interface from the business object. I have to do this to check the application for leaks of that business object into the session. Many thanks. Bernard On Thu, 5 Nov 2009 23:29:02 -0500, you wrote: >Are you always retrieving the entire list? [snip] - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Serializable check
Are you always retrieving the entire list?
On Thu, Nov 5, 2009 at 11:25 PM, wrote:
> 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, 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{
>>>
>>> private final Integer searchId;
>>> private volatile List entities;
>>>
>>> public MyEntityDataProvider(Integer searchId) {
>>> this(searchId, null);
>>> }
>>>
>>> public MyEntityDataProvider(Integer searchId, List
>>> entities) {
>>> this.searchId = searchId;
>>> this.entities = entities;
>>> }
>>>
>>> �...@override
>>> public Iterator 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 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, 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 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 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 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, wrote:
>>> Hi,
>>>
>>> I am trying to prevent the leaking of business objects into the
>>> session.
>
Re: Serializable check
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, 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{
>>
>> private final Integer searchId;
>> private volatile List entities;
>>
>> public MyEntityDataProvider(Integer searchId) {
>> this(searchId, null);
>> }
>>
>> public MyEntityDataProvider(Integer searchId, List
>> entities) {
>> this.searchId = searchId;
>> this.entities = entities;
>> }
>>
>> �...@override
>> public Iterator 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 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, 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 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 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 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, 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 unti
Re: Serializable check
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, 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{
>
> private final Integer searchId;
> private volatile List entities;
>
> public MyEntityDataProvider(Integer searchId) {
> this(searchId, null);
> }
>
> public MyEntityDataProvider(Integer searchId, List
> entities) {
> this.searchId = searchId;
> this.entities = entities;
> }
>
> �...@override
> public Iterator 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 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, 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 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 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 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, 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
Re: Serializable check
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{
private final Integer searchId;
private volatile List entities;
public MyEntityDataProvider(Integer searchId) {
this(searchId, null);
}
public MyEntityDataProvider(Integer searchId, List
entities) {
this.searchId = searchId;
this.entities = entities;
}
@Override
public Iterator 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 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, 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 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 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 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, 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
>>
>>
>
>
Re: Serializable check
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, 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 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 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 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, 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
Re: Serializable check
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 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 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 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, 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
Re: Serializable check
you have to override listdataprovider#model and return a detachable model. -igor On Thu, Nov 5, 2009 at 2:19 PM, 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
