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 =
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
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
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
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
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
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
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
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
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.
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
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
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
13 matches
Mail list logo
