Re: How does serialization work?
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 VisitorTextField?() {
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
VisitorTextField? () { ... }. Creating MyVisitor and replacing this
call solved the problem:
---
private abstract class MyVisitorX extends Component
implements IVisitorX, 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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
[EMAIL PROTECTED] 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 VisitorTextField?() {
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
VisitorTextField? () { ... }. Creating MyVisitor and replacing this
call solved the problem:
---
private abstract class MyVisitorX extends Component
implements IVisitorX, 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 [EMAIL PROTECTED]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 [EMAIL PROTECTED] 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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 [EMAIL PROTECTED] 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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 [EMAIL PROTECTED] 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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
On Mon, Nov 3, 2008 at 5:09 PM, Graeme Knight [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does serialization work?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
