You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by GK1971 <gr...@gmail.com> on 2008/11/03 22:24:06 UTC
How does serialization work?
Hi!
Again, I'm new, so hopefully I'm not posting in a bad way here. I've looked
through the forum but couldn't find the answer. Couldn't find the answers
from Tapestry in Action (I'm sure they are there if anyone can point me at a
page).
I have a simple page and form as below. The AuthenticationModel is a
LoadableDetatchableModel that queries the database for a username/password
based on a cookie id (I've cut all this code out for the example below).
My questions are perhaps super naive, but for some reason I am panicking
about serialized objects:
1) Exactly WHAT is getting serialized and where and when?
2) What are the main classes in the framework responsible for serialization
that I can look at (I have the source)? I guess I am after understanding the
flow of logic.
3) What happens if I make userIdField and passwordField scoped to the
constructor only? Is it common not to have them as member objects and why?
(I've not tried this yet, just wondered).
Many thanks for any help once again...
public class LoginPage extends AbstractWebPage
{
public LoginPage()
{
// create a login form and add it to the page
add( new LoginForm() );
}
}
public class LoginForm extends Form
{
private static final long serialVersionUID = 3975327499669581927L;
private TextField userIdField;
private PasswordTextField passwordField;
public LoginForm()
{
super( "loginForm", new AuthenticationModel() );
userIdField = new TextField( "username", new PropertyModel(
authenticationModel, "username" ) );
passwordField = new PasswordTextField( "password", new
PropertyModel( authenticationModel, "password" ) );
// add the components to the form
add( userIdField );
add( passwordField );
}
@Override
protected void onSubmit()
{
// authenticate user
}
}
--
View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20311180.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Mon, Nov 3, 2008 at 5:09 PM, Graeme Knight <gr...@gmail.com> wrote:
> Where on disk are these serialized pages?
i would imagine in a tmp dir, i would have to look in code for the
exact location - you can do the same....
> I remember reading you only cache
> the current page in memory. Is that correct?
yes, when using the diskstore only the current page is in httpsession.
the other pages are only needed if the user uses the back button.
> This serializing on disk - what
> is the strategy for keeping these files in sync in a clustered environment?
standard http session replication. when a node receives a page from
another node via session replication it adds it to its own local
diskstore.
-igor
>
> Appreciate the help very much! Graeme.
>
>
> igor.vaynberg wrote:
>>
>> it is cleaned up when the session expires. it used to be that we only
>> kept X last pages in the store, but now that we use disc that seems to
>> be redundant.
>>
>> -igor
>>
>> On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <gr...@gmail.com>
>> wrote:
>>>
>>> Hi.
>>>
>>> I wondered another thing - how and when are the serialized objects
>>> cleaned
>>> up? Is there a mechanism for making sure large amounts of memory or disk
>>> are
>>> not soaked up by long running sessions and lots of user interactions?
>>>
>>> Thanks again, Graeme.
>>>
>>>
>>> Graeme Knight wrote:
>>>>
>>>> Timo!
>>>>
>>>> Thanks for your answers - so you think its better NOT to have the
>>>> components as private member variables? I may misunderstand...
>>>>
>>>> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world
>>>> into
>>>> the Wicket world...
>>>>
>>>> Wicket in Action - VERY readable and well written, but perhaps I didn't
>>>> get far enough along to get to the serialization parts (I'm just
>>>> beginning
>>>> Part 2).
>>>>
>>>> Cheers, Graeme.
>>>>
>>>> Timo Rantalaiho wrote:
>>>>>
>>>>> On Mon, 03 Nov 2008, GK1971 wrote:
>>>>>> through the forum but couldn't find the answer. Couldn't find the
>>>>>> answers
>>>>>> from Tapestry in Action (I'm sure they are there if anyone can point
>>>>>> me
>>>>>> at a
>>>>>> page).
>>>>>
>>>>> You might want to have a look at Wicket in Action :--)
>>>>>
>>>>>> 1) Exactly WHAT is getting serialized and where and when?
>>>>>
>>>>> The page, which includes its whole Component tree.
>>>>>
>>>>>> 2) What are the main classes in the framework responsible for
>>>>>> serialization
>>>>>> that I can look at (I have the source)? I guess I am after
>>>>>> understanding
>>>>>> the
>>>>>> flow of logic.
>>>>>
>>>>> I find it easiest to start from Session.requestDetached().
>>>>> There you have
>>>>>
>>>>> page.getPageMap().put(page);
>>>>>
>>>>> =>
>>>>>
>>>>> SecondLevelCacheSessionStore.put(Page)
>>>>>
>>>>> =>
>>>>>
>>>>> DiskPageStore.storePage(String sessionId, Page page)
>>>>>
>>>>> and there's already stuff about serialisation.
>>>>>
>>>>> I'm sure that someone can give you a more scientific answer :)
>>>>>
>>>>>> 3) What happens if I make userIdField and passwordField scoped to the
>>>>>> constructor only? Is it common not to have them as member objects and
>>>>>> why?
>>>>>> (I've not tried this yet, just wondered).
>>>>>
>>>>> In here
>>>>>
>>>>>> add( userIdField );
>>>>>> add( passwordField );
>>>>>
>>>>> you add them as children of the constructed component.
>>>>> You can always access them for example with a visitor, if
>>>>> needed, and holding references to them makes it harder to
>>>>> replace them if needed (though it shouldn't be a problem if
>>>>> they won't be replaced).
>>>>>
>>>>> Best wishes,
>>>>> Timo
>>>>>
>>>>> --
>>>>> Timo Rantalaiho
>>>>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20313794.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: How does serialization work?
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 03 Nov 2008, Graeme Knight wrote:
> Where on disk are these serialized pages?
Servlet context temporary directory, which can be something
like /tmp/ or %HOME%\Local Settings\Temp . It can be changed
in web.xml (and I suppose that whether it's the servlet
context temp dir or some other place can be changed with
some Wicket setting or by providing a custom pagestore).
I remember seeing a presentation by Johan on some of this
stuff on slideshare.net .
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Graeme Knight <gr...@gmail.com>.
Thanks Igor! A great help!
Where on disk are these serialized pages? I remember reading you only cache
the current page in memory. Is that correct? This serializing on disk - what
is the strategy for keeping these files in sync in a clustered environment?
Appreciate the help very much! Graeme.
igor.vaynberg wrote:
>
> it is cleaned up when the session expires. it used to be that we only
> kept X last pages in the store, but now that we use disc that seems to
> be redundant.
>
> -igor
>
> On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <gr...@gmail.com>
> wrote:
>>
>> Hi.
>>
>> I wondered another thing - how and when are the serialized objects
>> cleaned
>> up? Is there a mechanism for making sure large amounts of memory or disk
>> are
>> not soaked up by long running sessions and lots of user interactions?
>>
>> Thanks again, Graeme.
>>
>>
>> Graeme Knight wrote:
>>>
>>> Timo!
>>>
>>> Thanks for your answers - so you think its better NOT to have the
>>> components as private member variables? I may misunderstand...
>>>
>>> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world
>>> into
>>> the Wicket world...
>>>
>>> Wicket in Action - VERY readable and well written, but perhaps I didn't
>>> get far enough along to get to the serialization parts (I'm just
>>> beginning
>>> Part 2).
>>>
>>> Cheers, Graeme.
>>>
>>> Timo Rantalaiho wrote:
>>>>
>>>> On Mon, 03 Nov 2008, GK1971 wrote:
>>>>> through the forum but couldn't find the answer. Couldn't find the
>>>>> answers
>>>>> from Tapestry in Action (I'm sure they are there if anyone can point
>>>>> me
>>>>> at a
>>>>> page).
>>>>
>>>> You might want to have a look at Wicket in Action :--)
>>>>
>>>>> 1) Exactly WHAT is getting serialized and where and when?
>>>>
>>>> The page, which includes its whole Component tree.
>>>>
>>>>> 2) What are the main classes in the framework responsible for
>>>>> serialization
>>>>> that I can look at (I have the source)? I guess I am after
>>>>> understanding
>>>>> the
>>>>> flow of logic.
>>>>
>>>> I find it easiest to start from Session.requestDetached().
>>>> There you have
>>>>
>>>> page.getPageMap().put(page);
>>>>
>>>> =>
>>>>
>>>> SecondLevelCacheSessionStore.put(Page)
>>>>
>>>> =>
>>>>
>>>> DiskPageStore.storePage(String sessionId, Page page)
>>>>
>>>> and there's already stuff about serialisation.
>>>>
>>>> I'm sure that someone can give you a more scientific answer :)
>>>>
>>>>> 3) What happens if I make userIdField and passwordField scoped to the
>>>>> constructor only? Is it common not to have them as member objects and
>>>>> why?
>>>>> (I've not tried this yet, just wondered).
>>>>
>>>> In here
>>>>
>>>>> add( userIdField );
>>>>> add( passwordField );
>>>>
>>>> you add them as children of the constructed component.
>>>> You can always access them for example with a visitor, if
>>>> needed, and holding references to them makes it harder to
>>>> replace them if needed (though it shouldn't be a problem if
>>>> they won't be replaced).
>>>>
>>>> Best wishes,
>>>> Timo
>>>>
>>>> --
>>>> Timo Rantalaiho
>>>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20313794.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Johan Compagner <jc...@gmail.com>.
we still have a last x pages stored on disk.
it is just not a number of pages but it is how many pages fit in the default
window size of the file on disk (1 file per pagemap)
by default it is 10MB per pagemap and 100MB per total session.
so by default you can hold 10 pagemaps of 10MB after that least used
pagemaps are cleared.
johan
On Tue, Nov 4, 2008 at 12:48 AM, Igor Vaynberg <ig...@gmail.com>wrote:
> it is cleaned up when the session expires. it used to be that we only
> kept X last pages in the store, but now that we use disc that seems to
> be redundant.
>
> -igor
>
> On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <gr...@gmail.com>
> wrote:
> >
> > Hi.
> >
> > I wondered another thing - how and when are the serialized objects
> cleaned
> > up? Is there a mechanism for making sure large amounts of memory or disk
> are
> > not soaked up by long running sessions and lots of user interactions?
> >
> > Thanks again, Graeme.
> >
> >
> > Graeme Knight wrote:
> >>
> >> Timo!
> >>
> >> Thanks for your answers - so you think its better NOT to have the
> >> components as private member variables? I may misunderstand...
> >>
> >> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world
> into
> >> the Wicket world...
> >>
> >> Wicket in Action - VERY readable and well written, but perhaps I didn't
> >> get far enough along to get to the serialization parts (I'm just
> beginning
> >> Part 2).
> >>
> >> Cheers, Graeme.
> >>
> >> Timo Rantalaiho wrote:
> >>>
> >>> On Mon, 03 Nov 2008, GK1971 wrote:
> >>>> through the forum but couldn't find the answer. Couldn't find the
> >>>> answers
> >>>> from Tapestry in Action (I'm sure they are there if anyone can point
> me
> >>>> at a
> >>>> page).
> >>>
> >>> You might want to have a look at Wicket in Action :--)
> >>>
> >>>> 1) Exactly WHAT is getting serialized and where and when?
> >>>
> >>> The page, which includes its whole Component tree.
> >>>
> >>>> 2) What are the main classes in the framework responsible for
> >>>> serialization
> >>>> that I can look at (I have the source)? I guess I am after
> understanding
> >>>> the
> >>>> flow of logic.
> >>>
> >>> I find it easiest to start from Session.requestDetached().
> >>> There you have
> >>>
> >>> page.getPageMap().put(page);
> >>>
> >>> =>
> >>>
> >>> SecondLevelCacheSessionStore.put(Page)
> >>>
> >>> =>
> >>>
> >>> DiskPageStore.storePage(String sessionId, Page page)
> >>>
> >>> and there's already stuff about serialisation.
> >>>
> >>> I'm sure that someone can give you a more scientific answer :)
> >>>
> >>>> 3) What happens if I make userIdField and passwordField scoped to the
> >>>> constructor only? Is it common not to have them as member objects and
> >>>> why?
> >>>> (I've not tried this yet, just wondered).
> >>>
> >>> In here
> >>>
> >>>> add( userIdField );
> >>>> add( passwordField );
> >>>
> >>> you add them as children of the constructed component.
> >>> You can always access them for example with a visitor, if
> >>> needed, and holding references to them makes it harder to
> >>> replace them if needed (though it shouldn't be a problem if
> >>> they won't be replaced).
> >>>
> >>> Best wishes,
> >>> Timo
> >>>
> >>> --
> >>> Timo Rantalaiho
> >>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > 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: How does serialization work?
Posted by Igor Vaynberg <ig...@gmail.com>.
it is cleaned up when the session expires. it used to be that we only
kept X last pages in the store, but now that we use disc that seems to
be redundant.
-igor
On Mon, Nov 3, 2008 at 4:08 PM, Graeme Knight <gr...@gmail.com> wrote:
>
> Hi.
>
> I wondered another thing - how and when are the serialized objects cleaned
> up? Is there a mechanism for making sure large amounts of memory or disk are
> not soaked up by long running sessions and lots of user interactions?
>
> Thanks again, Graeme.
>
>
> Graeme Knight wrote:
>>
>> Timo!
>>
>> Thanks for your answers - so you think its better NOT to have the
>> components as private member variables? I may misunderstand...
>>
>> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world into
>> the Wicket world...
>>
>> Wicket in Action - VERY readable and well written, but perhaps I didn't
>> get far enough along to get to the serialization parts (I'm just beginning
>> Part 2).
>>
>> Cheers, Graeme.
>>
>> Timo Rantalaiho wrote:
>>>
>>> On Mon, 03 Nov 2008, GK1971 wrote:
>>>> through the forum but couldn't find the answer. Couldn't find the
>>>> answers
>>>> from Tapestry in Action (I'm sure they are there if anyone can point me
>>>> at a
>>>> page).
>>>
>>> You might want to have a look at Wicket in Action :--)
>>>
>>>> 1) Exactly WHAT is getting serialized and where and when?
>>>
>>> The page, which includes its whole Component tree.
>>>
>>>> 2) What are the main classes in the framework responsible for
>>>> serialization
>>>> that I can look at (I have the source)? I guess I am after understanding
>>>> the
>>>> flow of logic.
>>>
>>> I find it easiest to start from Session.requestDetached().
>>> There you have
>>>
>>> page.getPageMap().put(page);
>>>
>>> =>
>>>
>>> SecondLevelCacheSessionStore.put(Page)
>>>
>>> =>
>>>
>>> DiskPageStore.storePage(String sessionId, Page page)
>>>
>>> and there's already stuff about serialisation.
>>>
>>> I'm sure that someone can give you a more scientific answer :)
>>>
>>>> 3) What happens if I make userIdField and passwordField scoped to the
>>>> constructor only? Is it common not to have them as member objects and
>>>> why?
>>>> (I've not tried this yet, just wondered).
>>>
>>> In here
>>>
>>>> add( userIdField );
>>>> add( passwordField );
>>>
>>> you add them as children of the constructed component.
>>> You can always access them for example with a visitor, if
>>> needed, and holding references to them makes it harder to
>>> replace them if needed (though it shouldn't be a problem if
>>> they won't be replaced).
>>>
>>> Best wishes,
>>> Timo
>>>
>>> --
>>> Timo Rantalaiho
>>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: How does serialization work?
Posted by Graeme Knight <gr...@gmail.com>.
Hi.
I wondered another thing - how and when are the serialized objects cleaned
up? Is there a mechanism for making sure large amounts of memory or disk are
not soaked up by long running sessions and lots of user interactions?
Thanks again, Graeme.
Graeme Knight wrote:
>
> Timo!
>
> Thanks for your answers - so you think its better NOT to have the
> components as private member variables? I may misunderstand...
>
> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world into
> the Wicket world...
>
> Wicket in Action - VERY readable and well written, but perhaps I didn't
> get far enough along to get to the serialization parts (I'm just beginning
> Part 2).
>
> Cheers, Graeme.
>
> Timo Rantalaiho wrote:
>>
>> On Mon, 03 Nov 2008, GK1971 wrote:
>>> through the forum but couldn't find the answer. Couldn't find the
>>> answers
>>> from Tapestry in Action (I'm sure they are there if anyone can point me
>>> at a
>>> page).
>>
>> You might want to have a look at Wicket in Action :--)
>>
>>> 1) Exactly WHAT is getting serialized and where and when?
>>
>> The page, which includes its whole Component tree.
>>
>>> 2) What are the main classes in the framework responsible for
>>> serialization
>>> that I can look at (I have the source)? I guess I am after understanding
>>> the
>>> flow of logic.
>>
>> I find it easiest to start from Session.requestDetached().
>> There you have
>>
>> page.getPageMap().put(page);
>>
>> =>
>>
>> SecondLevelCacheSessionStore.put(Page)
>>
>> =>
>>
>> DiskPageStore.storePage(String sessionId, Page page)
>>
>> and there's already stuff about serialisation.
>>
>> I'm sure that someone can give you a more scientific answer :)
>>
>>> 3) What happens if I make userIdField and passwordField scoped to the
>>> constructor only? Is it common not to have them as member objects and
>>> why?
>>> (I've not tried this yet, just wondered).
>>
>> In here
>>
>>> add( userIdField );
>>> add( passwordField );
>>
>> you add them as children of the constructed component.
>> You can always access them for example with a visitor, if
>> needed, and holding references to them makes it harder to
>> replace them if needed (though it shouldn't be a problem if
>> they won't be replaced).
>>
>> Best wishes,
>> Timo
>>
>> --
>> Timo Rantalaiho
>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20312968.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Adriano dos Santos Fernandes <ad...@uol.com.br>.
Johan Compagner escreveu:
> thats simple
>
> what you there create is an inner class in an inner class...
>
> so your textfield has a ajax behavior that is an inner class fo the Visitor
> inner class so that behavior has a parent reference to the visitor..
> make that ajax behavior his own class and your problem is solved
Very good catch. :-) Unfortunately the exception was not helpful.
Thanks,
Adriano
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Johan Compagner <jc...@gmail.com>.
thats simple
what you there create is an inner class in an inner class...
so your textfield has a ajax behavior that is an inner class fo the Visitor
inner class so that behavior has a parent reference to the visitor..
make that ajax behavior his own class and your problem is solved
johan
On Tue, Nov 4, 2008 at 4:26 PM, Adriano dos Santos Fernandes <
adrianosf@uol.com.br> wrote:
> I had a serialization problem (when redeploying the application in Tomcat)
> that I can't understand... Basically, I had this on my Page.onBeforeRender:
> ---------------
> visitChildren(TextField.class, new Visitor<TextField<?>>() {
> private static final long serialVersionUID = 1L;
>
> public Object component(TextField<?> textField)
> {
> textField.add(new AjaxEventBehavior("onchange") {
> private static final long serialVersionUID = 1L;
>
> @Override
> protected void onEvent(AjaxRequestTarget target)
> {
> if (mode == Mode.NAVIGATE)
> {
> mode = Mode.EDIT;
> setupMode();
> target.addComponent(buttonPanel);
> }
> }
> });
>
> setupValidators(textField);
> return IVisitor.CONTINUE_TRAVERSAL;
> }
> });
> ---------------
>
> The non-serializable class was the one created by "new
> Visitor<TextField<?>> () { ... }". Creating MyVisitor and replacing this
> call solved the problem:
> ---------------
> private abstract class MyVisitor<X extends Component>
> implements IVisitor<X>, Serializable
> {
> private static final long serialVersionUID = 1L;
> }
> ---------------
>
> Why should a non-serializable Visitor could case this problem? Does (why?)
> it get cached on the page?
>
>
> Adriano
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: How does serialization work?
Posted by Adriano dos Santos Fernandes <ad...@uol.com.br>.
I had a serialization problem (when redeploying the application in
Tomcat) that I can't understand... Basically, I had this on my
Page.onBeforeRender:
---------------
visitChildren(TextField.class, new Visitor<TextField<?>>() {
private static final long serialVersionUID = 1L;
public Object component(TextField<?> textField)
{
textField.add(new AjaxEventBehavior("onchange") {
private static final long serialVersionUID = 1L;
@Override
protected void onEvent(AjaxRequestTarget target)
{
if (mode == Mode.NAVIGATE)
{
mode = Mode.EDIT;
setupMode();
target.addComponent(buttonPanel);
}
}
});
setupValidators(textField);
return IVisitor.CONTINUE_TRAVERSAL;
}
});
---------------
The non-serializable class was the one created by "new
Visitor<TextField<?>> () { ... }". Creating MyVisitor and replacing this
call solved the problem:
---------------
private abstract class MyVisitor<X extends Component>
implements IVisitor<X>, Serializable
{
private static final long serialVersionUID = 1L;
}
---------------
Why should a non-serializable Visitor could case this problem? Does
(why?) it get cached on the page?
Adriano
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 03 Nov 2008, Igor Vaynberg wrote:
> it doesnt matter if you do this. because the page object is serialized
> and those components are fields of the page they are serialized only
> once and further references are replaced with links, this is how
> serialization works and it preserves proper references.
Right, it doesn't matter from the serialisation point of
view, but if you replace the component in the component
hierarchy, you should make sure that you also update these
references to point to the new component instances.
That's why I prefer accessing child components dynamically
whenever it can be easily done.
Best wishes,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Igor Vaynberg <ig...@gmail.com>.
as far as serialization wicket uses default java serialization with a
few tweaks to optimize it.
> Thanks for your answers - so you think its better NOT to have the components
> as private member variables? I may misunderstand...
it doesnt matter if you do this. because the page object is serialized
and those components are fields of the page they are serialized only
once and further references are replaced with links, this is how
serialization works and it preserves proper references.
-igor
>
> 'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world into
> the Wicket world...
>
> Wicket in Action - VERY readable and well written, but perhaps I didn't get
> far enough along to get to the serialization parts (I'm just beginning Part
> 2).
>
> Cheers, Graeme.
>
> Timo Rantalaiho wrote:
>>
>> On Mon, 03 Nov 2008, GK1971 wrote:
>>> through the forum but couldn't find the answer. Couldn't find the answers
>>> from Tapestry in Action (I'm sure they are there if anyone can point me
>>> at a
>>> page).
>>
>> You might want to have a look at Wicket in Action :--)
>>
>>> 1) Exactly WHAT is getting serialized and where and when?
>>
>> The page, which includes its whole Component tree.
>>
>>> 2) What are the main classes in the framework responsible for
>>> serialization
>>> that I can look at (I have the source)? I guess I am after understanding
>>> the
>>> flow of logic.
>>
>> I find it easiest to start from Session.requestDetached().
>> There you have
>>
>> page.getPageMap().put(page);
>>
>> =>
>>
>> SecondLevelCacheSessionStore.put(Page)
>>
>> =>
>>
>> DiskPageStore.storePage(String sessionId, Page page)
>>
>> and there's already stuff about serialisation.
>>
>> I'm sure that someone can give you a more scientific answer :)
>>
>>> 3) What happens if I make userIdField and passwordField scoped to the
>>> constructor only? Is it common not to have them as member objects and
>>> why?
>>> (I've not tried this yet, just wondered).
>>
>> In here
>>
>>> add( userIdField );
>>> add( passwordField );
>>
>> you add them as children of the constructed component.
>> You can always access them for example with a visitor, if
>> needed, and holding references to them makes it harder to
>> replace them if needed (though it shouldn't be a problem if
>> they won't be replaced).
>>
>> Best wishes,
>> Timo
>>
>> --
>> Timo Rantalaiho
>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20312172.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: How does serialization work?
Posted by GK1971 <gr...@gmail.com>.
Timo!
Thanks for your answers - so you think its better NOT to have the components
as private member variables? I may misunderstand...
'Tapestry' in Action.... LOL! Sorry! I'm moving over from that world into
the Wicket world...
Wicket in Action - VERY readable and well written, but perhaps I didn't get
far enough along to get to the serialization parts (I'm just beginning Part
2).
Cheers, Graeme.
Timo Rantalaiho wrote:
>
> On Mon, 03 Nov 2008, GK1971 wrote:
>> through the forum but couldn't find the answer. Couldn't find the answers
>> from Tapestry in Action (I'm sure they are there if anyone can point me
>> at a
>> page).
>
> You might want to have a look at Wicket in Action :--)
>
>> 1) Exactly WHAT is getting serialized and where and when?
>
> The page, which includes its whole Component tree.
>
>> 2) What are the main classes in the framework responsible for
>> serialization
>> that I can look at (I have the source)? I guess I am after understanding
>> the
>> flow of logic.
>
> I find it easiest to start from Session.requestDetached().
> There you have
>
> page.getPageMap().put(page);
>
> =>
>
> SecondLevelCacheSessionStore.put(Page)
>
> =>
>
> DiskPageStore.storePage(String sessionId, Page page)
>
> and there's already stuff about serialisation.
>
> I'm sure that someone can give you a more scientific answer :)
>
>> 3) What happens if I make userIdField and passwordField scoped to the
>> constructor only? Is it common not to have them as member objects and
>> why?
>> (I've not tried this yet, just wondered).
>
> In here
>
>> add( userIdField );
>> add( passwordField );
>
> you add them as children of the constructed component.
> You can always access them for example with a visitor, if
> needed, and holding references to them makes it harder to
> replace them if needed (though it shouldn't be a problem if
> they won't be replaced).
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/How-does-serialization-work--tp20311180p20312172.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: How does serialization work?
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 03 Nov 2008, GK1971 wrote:
> through the forum but couldn't find the answer. Couldn't find the answers
> from Tapestry in Action (I'm sure they are there if anyone can point me at a
> page).
You might want to have a look at Wicket in Action :--)
> 1) Exactly WHAT is getting serialized and where and when?
The page, which includes its whole Component tree.
> 2) What are the main classes in the framework responsible for serialization
> that I can look at (I have the source)? I guess I am after understanding the
> flow of logic.
I find it easiest to start from Session.requestDetached().
There you have
page.getPageMap().put(page);
=>
SecondLevelCacheSessionStore.put(Page)
=>
DiskPageStore.storePage(String sessionId, Page page)
and there's already stuff about serialisation.
I'm sure that someone can give you a more scientific answer :)
> 3) What happens if I make userIdField and passwordField scoped to the
> constructor only? Is it common not to have them as member objects and why?
> (I've not tried this yet, just wondered).
In here
> add( userIdField );
> add( passwordField );
you add them as children of the constructed component.
You can always access them for example with a visitor, if
needed, and holding references to them makes it harder to
replace them if needed (though it shouldn't be a problem if
they won't be replaced).
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org