You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Hansen <ha...@gmail.com> on 2009/03/04 05:36:44 UTC
Non-serializable model objects
Hi all,
First off, I'm new to Wicket and I have to say I'm really liking it so far.
One concern I have is related to using non-serializable objects. If
I'm not mistaken, some other web frameworks will create dynamic,
serializable proxies for your non-serializable objects automatically,
when possible. I saw that this type of functionality is used in
Wicket's Guice integration, but I am wondering why it isn't a part of
Wicket proper. Using serializable model objects seems like a fine
goal, but what if those model objects are in a library which is not
under our control and they happen to not be serializable?
There must be downsides to the proxy approach that I'm not aware of,
or an easier way to work with non-serializable model objects. Am I
missing something?
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Non-serializable model objects
Posted by Chris Hansen <ha...@gmail.com>.
I'm familiar with that approach, but it seems a bit cumbersome -
especially for collections of non-serializable objects. I was hoping
there was some other way.
-Chris
On Tue, Mar 3, 2009 at 9:41 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> Use a LoadableDetachableModel that can re-inflate / re-retrieve your
> serializable object. It may only need to store something like a class name
> and an integer ID, etc. This keeps session state small as well.
> Serialization of all models allows for easier clustering when your site
> becomes the next Twitter.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
> On Tue, Mar 3, 2009 at 10:36 PM, Chris Hansen <ha...@gmail.com>wrote:
>
>> Hi all,
>>
>> First off, I'm new to Wicket and I have to say I'm really liking it so far.
>>
>> One concern I have is related to using non-serializable objects. If
>> I'm not mistaken, some other web frameworks will create dynamic,
>> serializable proxies for your non-serializable objects automatically,
>> when possible. I saw that this type of functionality is used in
>> Wicket's Guice integration, but I am wondering why it isn't a part of
>> Wicket proper. Using serializable model objects seems like a fine
>> goal, but what if those model objects are in a library which is not
>> under our control and they happen to not be serializable?
>>
>> There must be downsides to the proxy approach that I'm not aware of,
>> or an easier way to work with non-serializable model objects. Am I
>> missing something?
>>
>> Thanks,
>> Chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Non-serializable model objects
Posted by Jeremy Thomerson <je...@wickettraining.com>.
Use a LoadableDetachableModel that can re-inflate / re-retrieve your
serializable object. It may only need to store something like a class name
and an integer ID, etc. This keeps session state small as well.
Serialization of all models allows for easier clustering when your site
becomes the next Twitter.
--
Jeremy Thomerson
http://www.wickettraining.com
On Tue, Mar 3, 2009 at 10:36 PM, Chris Hansen <ha...@gmail.com>wrote:
> Hi all,
>
> First off, I'm new to Wicket and I have to say I'm really liking it so far.
>
> One concern I have is related to using non-serializable objects. If
> I'm not mistaken, some other web frameworks will create dynamic,
> serializable proxies for your non-serializable objects automatically,
> when possible. I saw that this type of functionality is used in
> Wicket's Guice integration, but I am wondering why it isn't a part of
> Wicket proper. Using serializable model objects seems like a fine
> goal, but what if those model objects are in a library which is not
> under our control and they happen to not be serializable?
>
> There must be downsides to the proxy approach that I'm not aware of,
> or an easier way to work with non-serializable model objects. Am I
> missing something?
>
> Thanks,
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Non-serializable model objects
Posted by Leszek Gawron <lg...@apache.org>.
Timo Rantalaiho wrote:
> On Tue, 03 Mar 2009, Chris Hansen wrote:
>> The situation that I'm dealing with most commonly is where I'm dealing
>> with simple, DTO-like POJOS with no-arg constructors and
>> getters/setters (why they are not serializable in the first place is
>> beyond me). It just seems like it would be possible, in this simple
>> case, to create a proxy for each object in the object graph which is
>> not serializable until you get down to the actual data (i.e.
>> primitives, Strings, etc.) which is serializable. The proxies would
>> have to keep track of whatever information they need to de-serialize
>> themselves (e.g. class name and constructor). It seems like this has
>> not been implemented, but do you think it is possible to do so?
>
> That sounds cumbersome too :)
>
> If the objects are in fact serializable, why can't you make
> them Serializable?
As I am learning AspectJ lately I try to solve every problem with it :)
it turns out you could weave DTOs you have no control over to implement
Serializable interface:
public aspect SerializerImplementer {
declare parents: ProductDTO implements Serializable;
declare parents: ContractorDTO implements Serializable;
declare parents: InvoiceDTO implements Serializable;
}
You can do it once and have no problem with it ever again...
--
Leszek Gawron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Non-serializable model objects
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Tue, 03 Mar 2009, Chris Hansen wrote:
> The situation that I'm dealing with most commonly is where I'm dealing
> with simple, DTO-like POJOS with no-arg constructors and
> getters/setters (why they are not serializable in the first place is
> beyond me). It just seems like it would be possible, in this simple
> case, to create a proxy for each object in the object graph which is
> not serializable until you get down to the actual data (i.e.
> primitives, Strings, etc.) which is serializable. The proxies would
> have to keep track of whatever information they need to de-serialize
> themselves (e.g. class name and constructor). It seems like this has
> not been implemented, but do you think it is possible to do so?
That sounds cumbersome too :)
If the objects are in fact serializable, why can't you make
them Serializable?
Alternatively, you could create Serializable wrappers for them.
Doing that to DTOs sounds strange though :)
Some people use HttpSessionStore and don't replicate nor
persist their sessions, but I suppose that's not a supported
nor advisable approach.
Best wishes,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Non-serializable model objects
Posted by Igor Vaynberg <ig...@gmail.com>.
of course its possible, you will basically be rewriting java's
serialization mechanism :) its been done before - eg xstream.
is it recommended or safe? probably not, so do at your own risk.
imagine a dao that holds onto a datasource. serializing the datasource
is probably not the best idea. also serializing singletons is not a
good idea because upon deserialization you will end up with many
instances of the singleton. imho, there are very good reason why some
objects are not declared serializable. does the flipside of the coin
exist? of course, ive seen it - but it hasnt happened very often.
-igor
On Tue, Mar 3, 2009 at 8:54 PM, Chris Hansen <ha...@gmail.com> wrote:
> Makes sense, and thanks for the quick replies.
>
> The situation that I'm dealing with most commonly is where I'm dealing
> with simple, DTO-like POJOS with no-arg constructors and
> getters/setters (why they are not serializable in the first place is
> beyond me). It just seems like it would be possible, in this simple
> case, to create a proxy for each object in the object graph which is
> not serializable until you get down to the actual data (i.e.
> primitives, Strings, etc.) which is serializable. The proxies would
> have to keep track of whatever information they need to de-serialize
> themselves (e.g. class name and constructor). It seems like this has
> not been implemented, but do you think it is possible to do so?
>
> -Chris
>
> On Tue, Mar 3, 2009 at 9:43 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> objects you put into the model are stored in components, which are in
>> turn stored in httpsession and are serialized to disk. in order to be
>> serialized to disk or to be stored in httpsession (per servlet spec)
>> those objects must be serializable.
>>
>> if your object is not serializable and all you do is wrap it in a
>> serializable proxy this will not help you much when it comes to dump
>> the page to disk.
>>
>> what is happening in wicket-guice and wicket-spring is that only
>> references you get from your container are held us serializable
>> proxies. this works because when it comes time to serialize the
>> component these values can be discarded because they can be later
>> looked up from the container again. but if your value is not
>> discardable this approach wont work.
>>
>> makes sense?
>>
>> -igor
>>
>> On Tue, Mar 3, 2009 at 8:36 PM, Chris Hansen <ha...@gmail.com> wrote:
>>> Hi all,
>>>
>>> First off, I'm new to Wicket and I have to say I'm really liking it so far.
>>>
>>> One concern I have is related to using non-serializable objects. If
>>> I'm not mistaken, some other web frameworks will create dynamic,
>>> serializable proxies for your non-serializable objects automatically,
>>> when possible. I saw that this type of functionality is used in
>>> Wicket's Guice integration, but I am wondering why it isn't a part of
>>> Wicket proper. Using serializable model objects seems like a fine
>>> goal, but what if those model objects are in a library which is not
>>> under our control and they happen to not be serializable?
>>>
>>> There must be downsides to the proxy approach that I'm not aware of,
>>> or an easier way to work with non-serializable model objects. Am I
>>> missing something?
>>>
>>> Thanks,
>>> Chris
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Non-serializable model objects
Posted by Chris Hansen <ha...@gmail.com>.
Makes sense, and thanks for the quick replies.
The situation that I'm dealing with most commonly is where I'm dealing
with simple, DTO-like POJOS with no-arg constructors and
getters/setters (why they are not serializable in the first place is
beyond me). It just seems like it would be possible, in this simple
case, to create a proxy for each object in the object graph which is
not serializable until you get down to the actual data (i.e.
primitives, Strings, etc.) which is serializable. The proxies would
have to keep track of whatever information they need to de-serialize
themselves (e.g. class name and constructor). It seems like this has
not been implemented, but do you think it is possible to do so?
-Chris
On Tue, Mar 3, 2009 at 9:43 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> objects you put into the model are stored in components, which are in
> turn stored in httpsession and are serialized to disk. in order to be
> serialized to disk or to be stored in httpsession (per servlet spec)
> those objects must be serializable.
>
> if your object is not serializable and all you do is wrap it in a
> serializable proxy this will not help you much when it comes to dump
> the page to disk.
>
> what is happening in wicket-guice and wicket-spring is that only
> references you get from your container are held us serializable
> proxies. this works because when it comes time to serialize the
> component these values can be discarded because they can be later
> looked up from the container again. but if your value is not
> discardable this approach wont work.
>
> makes sense?
>
> -igor
>
> On Tue, Mar 3, 2009 at 8:36 PM, Chris Hansen <ha...@gmail.com> wrote:
>> Hi all,
>>
>> First off, I'm new to Wicket and I have to say I'm really liking it so far.
>>
>> One concern I have is related to using non-serializable objects. If
>> I'm not mistaken, some other web frameworks will create dynamic,
>> serializable proxies for your non-serializable objects automatically,
>> when possible. I saw that this type of functionality is used in
>> Wicket's Guice integration, but I am wondering why it isn't a part of
>> Wicket proper. Using serializable model objects seems like a fine
>> goal, but what if those model objects are in a library which is not
>> under our control and they happen to not be serializable?
>>
>> There must be downsides to the proxy approach that I'm not aware of,
>> or an easier way to work with non-serializable model objects. Am I
>> missing something?
>>
>> Thanks,
>> Chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Non-serializable model objects
Posted by Igor Vaynberg <ig...@gmail.com>.
objects you put into the model are stored in components, which are in
turn stored in httpsession and are serialized to disk. in order to be
serialized to disk or to be stored in httpsession (per servlet spec)
those objects must be serializable.
if your object is not serializable and all you do is wrap it in a
serializable proxy this will not help you much when it comes to dump
the page to disk.
what is happening in wicket-guice and wicket-spring is that only
references you get from your container are held us serializable
proxies. this works because when it comes time to serialize the
component these values can be discarded because they can be later
looked up from the container again. but if your value is not
discardable this approach wont work.
makes sense?
-igor
On Tue, Mar 3, 2009 at 8:36 PM, Chris Hansen <ha...@gmail.com> wrote:
> Hi all,
>
> First off, I'm new to Wicket and I have to say I'm really liking it so far.
>
> One concern I have is related to using non-serializable objects. If
> I'm not mistaken, some other web frameworks will create dynamic,
> serializable proxies for your non-serializable objects automatically,
> when possible. I saw that this type of functionality is used in
> Wicket's Guice integration, but I am wondering why it isn't a part of
> Wicket proper. Using serializable model objects seems like a fine
> goal, but what if those model objects are in a library which is not
> under our control and they happen to not be serializable?
>
> There must be downsides to the proxy approach that I'm not aware of,
> or an easier way to work with non-serializable model objects. Am I
> missing something?
>
> Thanks,
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org