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
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: 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'brien 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