Serializable check
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
Re: Serializable check
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
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 IModelMyEntity 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 ListT 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
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, 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 IModelMyEntity 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 ListT 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
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 IDataProviderMyEntity{
private final Integer searchId;
private volatile ListMyEntity entities;
public MyEntityDataProvider(Integer searchId) {
this(searchId, null);
}
public MyEntityDataProvider(Integer searchId, ListMyEntity
entities) {
this.searchId = searchId;
this.entities = entities;
}
@Override
public IteratorMyEntity 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 IModelMyEntity 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 IModelMyEntity 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 ListT 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
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, 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 IDataProviderMyEntity{
private final Integer searchId;
private volatile ListMyEntity entities;
public MyEntityDataProvider(Integer searchId) {
this(searchId, null);
}
public MyEntityDataProvider(Integer searchId, ListMyEntity
entities) {
this.searchId = searchId;
this.entities = entities;
}
�...@override
public IteratorMyEntity 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 IModelMyEntity 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 IModelMyEntity 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 ListT 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
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, 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 IDataProviderMyEntity{
private final Integer searchId;
private volatile ListMyEntity entities;
public MyEntityDataProvider(Integer searchId) {
this(searchId, null);
}
public MyEntityDataProvider(Integer searchId, ListMyEntity
entities) {
this.searchId = searchId;
this.entities = entities;
}
�...@override
public IteratorMyEntity 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 IModelMyEntity 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 IModelMyEntity 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 ListT 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
Re: Serializable check
Are you always retrieving the entire list?
On Thu, Nov 5, 2009 at 11:25 PM, b...@actrix.gen.nz 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, 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 IDataProviderMyEntity{
private final Integer searchId;
private volatile ListMyEntity entities;
public MyEntityDataProvider(Integer searchId) {
this(searchId, null);
}
public MyEntityDataProvider(Integer searchId, ListMyEntity
entities) {
this.searchId = searchId;
this.entities = entities;
}
�...@override
public IteratorMyEntity 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 IModelMyEntity 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 IModelMyEntity 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 ListT 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
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
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
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, b...@actrix.gen.nz 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, 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 IDataProviderMyEntity{
private final Integer searchId;
private volatile ListMyEntity entities;
public MyEntityDataProvider(Integer searchId) {
this(searchId, null);
}
public MyEntityDataProvider(Integer searchId, ListMyEntity
entities) {
this.searchId = searchId;
this.entities = entities;
}
�...@override
public IteratorMyEntity 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 IModelMyEntity 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 IModelMyEntity 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 ListT 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
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: label fails serializable check when i override model().getObject (wicket 1.3.6)
final _isgraph=isgraph;
graphLink.add(new Label(graphLinkLabel, new Model() {
@Override
public Object getObject() {
return _isgraph ? List : Graph;
}
}));
-igor
On Thu, Aug 27, 2009 at 12:19 PM, james o'brienjobr...@spinnphr.com wrote:
I'm trying to change the text of label based on whether a flag is set for
graph or not graph.
graphLink.add(new Label(graphLinkLabel, new Model() {
�...@override
public Object getObject() {
return isGraph ? List : Graph;
}
}));
When I do this, I get a private
org.apache.wicket.markup.html.link.PopupSettings
org.apache.wicket.markup.html.link.Link.popupSettings[6]
[class=com.spinn.ui.person.weight.ViewWeights$4, path=6:border:graphLink]
final javax.servlet.http.HttpServletRequest
com.spinn.ui.person.weight.ViewWeights$4.val$request
[class=org.apache.catalina.connector.RequestFacade] - field that is not
serializable
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:339)
If I change it to a normal label I do not.
Any ideas?
-jim
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
label fails serializable check when i override model().getObject (wicket 1.3.6)
I'm trying to change the text of label based on whether a flag is set for
graph or not graph.
graphLink.add(new Label(graphLinkLabel, new Model() {
@Override
public Object getObject() {
return isGraph ? List : Graph;
}
}));
When I do this, I get a private
org.apache.wicket.markup.html.link.PopupSettings
org.apache.wicket.markup.html.link.Link.popupSettings[6]
[class=com.spinn.ui.person.weight.ViewWeights$4, path=6:border:graphLink]
final javax.servlet.http.HttpServletRequest
com.spinn.ui.person.weight.ViewWeights$4.val$request
[class=org.apache.catalina.connector.RequestFacade] - field that is not
serializable
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:339)
If I change it to a normal label I do not.
Any ideas?
-jim
