Re: Wicket Session Management
Ok, I got the answer. Wicket tries to be as stateless as long as possible, I believe it takes some hints from how your pages are built to know if it needs to keep a Session around for longer than a Request. [1] [1] http://basementcoders.com/?p=65cpage=1 Thanks Nishant On Tue, Mar 9, 2010 at 11:53 PM, Nishant Neeraj nishant.has.a.quest...@gmail.com wrote: Hi, I have a registration system where, when you request for registration, you are mailed a URL with unique-key as parameter. When user clicks the link, he lands on a page where I am setting his UserVO object in session. This page has another BookmarkablePageLink that points to the user's profile setup page. Now, when the user clicks the link to profile setup page, I find that session object has changed... there is no UserVO, plus session's hashCode and session toString() value is different from the one for the previous page. Can anyone provide a clue? Or is it possible for a request originating from one page can have different session? Thanks Nishant
Re: Wicket - Session Management
Basically, the normal Wicket facility for transferring state client side is through PageParameters. Of course, if you're building links to another app, you'll basically need to build these links your self since App1 doesn't know how to build links for App2 since App2 pages aren't mounted in App1. So, you pretty much have your normal webapp options - store the state somewhere central to both apps (DB, etc), or transfer it some other way (perhaps a messaging bus). Wicket is just OO, so you can pretty much use whatever fits your situation. -- Jeremy Thomerson http://www.wickettraining.com On Wed, Mar 4, 2009 at 2:48 AM, subbu_tce subramanian.mur...@gmail.comwrote: Jeremy, I meant to ask about both the points that you have mentioned in your reply message: (i.e) Two wicket apps in two JVMs. How do we accomplish the following? - transfer state from first app to second app when clicking a link in the first app - access state in the first app from second app - preserve/expire state in the first app when moving to second app. Moreover, how do we accomplish the above three for two wicket apps in the same JVM? And also does wicket provide any extension points to have the state saved in the client side? --- I'm not sure exactly what you're asking. Is it one of the following? - I have two apps in two JVMs - how do I transfer state from one app to the second when clicking a link from one to the other? - I have two apps in two JVMs - how do I expire state in the first when moving to the second? -- Jeremy Thomerson http://www.wickettraining.com -- View this message in context: http://www.nabble.com/Wicket---Session-Management-tp22288083p22325909.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: Wicket - Session Management
Jeremy, I meant to ask about both the points that you have mentioned in your reply message: (i.e) Two wicket apps in two JVMs. How do we accomplish the following? - transfer state from first app to second app when clicking a link in the first app - access state in the first app from second app - preserve/expire state in the first app when moving to second app. Moreover, how do we accomplish the above three for two wicket apps in the same JVM? And also does wicket provide any extension points to have the state saved in the client side? --- I'm not sure exactly what you're asking. Is it one of the following? - I have two apps in two JVMs - how do I transfer state from one app to the second when clicking a link from one to the other? - I have two apps in two JVMs - how do I expire state in the first when moving to the second? -- Jeremy Thomerson http://www.wickettraining.com -- View this message in context: http://www.nabble.com/Wicket---Session-Management-tp22288083p22325909.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: Wicket - Session Management
I'm not sure exactly what you're asking. Is it one of the following? - I have two apps in two JVMs - how do I transfer state from one app to the second when clicking a link from one to the other? - I have two apps in two JVMs - how do I expire state in the first when moving to the second? -- Jeremy Thomerson http://www.wickettraining.com On Mon, Mar 2, 2009 at 7:26 AM, subbu_tce subramanian.mur...@gmail.comwrote: Hi, I have two wicket applications running in two different JVMs. If clicking on a link in the first wicket application that runs in the first JVM, is redirected to the second wicket application that runs in second JVM, What support does Wicket provide to manage the page map in the session for the first wicket application other than manually invalidating the objects in the session when redirected to the second wicket application? Moreover, I understand the state of all wicket components are maintained in the session. But does wicket provide any programmatic extension points to have the partially/fully managed on the client side? And also please help me point to good materials/articles on session management and custom session management in wicket. Thanks, Subbu. -- View this message in context: http://www.nabble.com/Wicket---Session-Management-tp22288083p22288083.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: Wicket - Session Management
There is a small typo in the second question. Second question is reworded as below: Does wicket provide any programmatic extension points to have the state of components managed on the client side? Thanks, Subbu. subbu_tce wrote: Hi, I have two wicket applications running in two different JVMs. If clicking on a link in the first wicket application that runs in the first JVM, is redirected to the second wicket application that runs in second JVM, What support does Wicket provide to manage the page map in the session for the first wicket application other than manually invalidating the objects in the session when redirected to the second wicket application? Moreover, I understand the state of all wicket components are maintained in the session. But does wicket provide any programmatic extension points to have the partially/fully managed on the client side? And also please help me point to good materials/articles on session management and custom session management in wicket. Thanks, Subbu. -- View this message in context: http://www.nabble.com/Wicket---Session-Management-tp22288083p22288126.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: Wicket Session Management (constructor called twice)
wicket creates temporary session objects for stateless pages until the
session is persisted.
-igor
On Tue, Jun 17, 2008 at 4:29 PM, Ravi_116 [EMAIL PROTECTED] wrote:
Is there any reason why custom wicket web session is instantiated twice when
presented with login screen. The application uses standard wicket-auth
implementation.
public class LingoWebSession extends AuthenticatedWebSession
{
public LingoWebSession(AuthenticatedWebApplication application, Request
request)
{
super(application, request);
InjectorHolder.getInjector().inject(this);
new Exception( here ).printStackTrace();
}
}
public class MagicEightBallWebApplication extends
AuthenticatedWebApplication
{
@Override
protected Class? extends AuthenticatedWebSession getWebSessionClass()
{
return LingoWebSession.class;
}
}
java.lang.Exception: here
at com.semantra.web.LingoWebSession.init(LingoWebSession.java:38)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.wicket.authentication.AuthenticatedWebApplication.newSession(AuthenticatedWebApplication.java:114)
at org.apache.wicket.Session.findOrCreate(Session.java:225)
at org.apache.wicket.Session.findOrCreate(Session.java:208)
at org.apache.wicket.Session.get(Session.java:244)
at
org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:43)
at
com.semantra.oem.mscrm.web.NtlmRequestCycle.onBeginRequest(NtlmRequestCycle.java:56)
at org.apache.wicket.RequestCycle.prepare(RequestCycle.java:1084)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1146)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1245)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
at
com.semantra.oem.mscrm.web.setup.SetupConfigFilter.doFilter(SetupConfigFilter.java:38)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:183)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:118)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
application USERNAME admin
java.lang.Exception: here
at com.semantra.web.LingoWebSession.init(LingoWebSession.java:38)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
Re: Wicket Session Management (constructor called twice)
Is there anyway around this problem? I am trying to do automatic
authentication and i would like the Wicket Session to be the same as a
HttpSession (so that the authentication will work).
Ravi
igor.vaynberg wrote:
wicket creates temporary session objects for stateless pages until the
session is persisted.
-igor
On Tue, Jun 17, 2008 at 4:29 PM, Ravi_116 [EMAIL PROTECTED] wrote:
Is there any reason why custom wicket web session is instantiated twice
when
presented with login screen. The application uses standard wicket-auth
implementation.
public class LingoWebSession extends AuthenticatedWebSession
{
public LingoWebSession(AuthenticatedWebApplication application,
Request
request)
{
super(application, request);
InjectorHolder.getInjector().inject(this);
new Exception( here ).printStackTrace();
}
}
public class MagicEightBallWebApplication extends
AuthenticatedWebApplication
{
@Override
protected Class? extends AuthenticatedWebSession
getWebSessionClass()
{
return LingoWebSession.class;
}
}
java.lang.Exception: here
at
com.semantra.web.LingoWebSession.init(LingoWebSession.java:38)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.wicket.authentication.AuthenticatedWebApplication.newSession(AuthenticatedWebApplication.java:114)
at org.apache.wicket.Session.findOrCreate(Session.java:225)
at org.apache.wicket.Session.findOrCreate(Session.java:208)
at org.apache.wicket.Session.get(Session.java:244)
at
org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:43)
at
com.semantra.oem.mscrm.web.NtlmRequestCycle.onBeginRequest(NtlmRequestCycle.java:56)
at org.apache.wicket.RequestCycle.prepare(RequestCycle.java:1084)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1146)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1245)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
at
com.semantra.oem.mscrm.web.setup.SetupConfigFilter.doFilter(SetupConfigFilter.java:38)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:183)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:118)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
application USERNAME admin
java.lang.Exception: here
at
com.semantra.web.LingoWebSession.init(LingoWebSession.java:38)
at
Re: Wicket Session Management (constructor called twice)
you can bind the session in constructor, just call bind();
-igor
On Tue, Jun 17, 2008 at 5:28 PM, Ravi_116 [EMAIL PROTECTED] wrote:
Is there anyway around this problem? I am trying to do automatic
authentication and i would like the Wicket Session to be the same as a
HttpSession (so that the authentication will work).
Ravi
igor.vaynberg wrote:
wicket creates temporary session objects for stateless pages until the
session is persisted.
-igor
On Tue, Jun 17, 2008 at 4:29 PM, Ravi_116 [EMAIL PROTECTED] wrote:
Is there any reason why custom wicket web session is instantiated twice
when
presented with login screen. The application uses standard wicket-auth
implementation.
public class LingoWebSession extends AuthenticatedWebSession
{
public LingoWebSession(AuthenticatedWebApplication application,
Request
request)
{
super(application, request);
InjectorHolder.getInjector().inject(this);
new Exception( here ).printStackTrace();
}
}
public class MagicEightBallWebApplication extends
AuthenticatedWebApplication
{
@Override
protected Class? extends AuthenticatedWebSession
getWebSessionClass()
{
return LingoWebSession.class;
}
}
java.lang.Exception: here
at
com.semantra.web.LingoWebSession.init(LingoWebSession.java:38)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.wicket.authentication.AuthenticatedWebApplication.newSession(AuthenticatedWebApplication.java:114)
at org.apache.wicket.Session.findOrCreate(Session.java:225)
at org.apache.wicket.Session.findOrCreate(Session.java:208)
at org.apache.wicket.Session.get(Session.java:244)
at
org.apache.wicket.authentication.AuthenticatedWebSession.get(AuthenticatedWebSession.java:43)
at
com.semantra.oem.mscrm.web.NtlmRequestCycle.onBeginRequest(NtlmRequestCycle.java:56)
at org.apache.wicket.RequestCycle.prepare(RequestCycle.java:1084)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1146)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1245)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354)
at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074)
at
com.semantra.oem.mscrm.web.setup.SetupConfigFilter.doFilter(SetupConfigFilter.java:38)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:183)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:118)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
application USERNAME admin
Re: Wicket Session Management?
- Also it looks like wicket requires code changes when more pages are added and each page needs to have separate handler and it can not be done in configuration file. This may become an issue when number of pages increase in future. what do you mean with this? You want to have the flow between pages in a xml file? Please explain to me how you want to do that exactly, i am always very curious why the web frameworks all really want this. How do you see that you can just drop in a new page. And then configure an xml file and that page is suddenly the response page of 5 other pages (actions) ? But what state does that new page get? Are all the pages that you show completely stateless they can construct themself from something and know what they must show and what there context is? So how do all the previous pages know exactly what context to set somewhere that the new page wants? Please if anybody could tell me how they can build an application with flow where all the pages don't really know anything of the next page of even what the next page really is. Is there 1 person on this list that made a struts or webflow application like this that they can randomly define flow and add pages without touching the existing code base? johan
Re: Wicket Session Management?
Pen wrote / napísal(a): I have a few question regarding the wicket usage. we are trying to Implement wicket as our next MVC framework, Can please someone answer the questions below Hi - about session support - wicket stores the render state of most renderer's in session for different users of the systems. This means large/very large sessions that need to be supported, means memory crunch, performance degradation and implementing the failover at production level really hard. Wicket doesn't store a render state of renderer's (have no clue what that might be). Wicket stores a component tree of last page in session. Btw. this doesn't even sound like a question, it sounds like stating facts, not to mention that the facts are based on wrong assumtptions. Very large sessions? I've seen a model 2 application with sessions over a megabyte. Usually a wicket page is (unless it's a big one - with lot of components) around 30kb (of course this is very relative, this just reflects my experience with most of my wicket based projects). I don't think a 30kb session results in performance degradation or makes implementing failover difficult. - Also it looks like wicket requires code changes when more pages are added and each page needs to have separate handler and it can not be done in configuration file. This may become an issue when number of pages increase in future. What handler? What configuration file? Page has a class that implements the logic (probably what you mean by handler). How is this related to a config file? Wicket doesn't need any config file. There's no external plumbing. I fail to see how this results in an issue with increased page numbers, as the pages are completely independent. Also I'm kinda missing a question mark in this question again, which make it seem like a statement (wrong again as far as I can tell). I'm not sure if that was intended. -Matej Dummy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session Management?
Thanks Matej for your quick reply, these are stupid questions asked by the team members, who are resisting to implement Wicket. Trying to come up with some issues. So basically you are telling that session management is not a issue at all in wicket, that's good. Thanks Again! Dummy Matej Knopp-2 wrote: Pen wrote / napísal(a): I have a few question regarding the wicket usage. we are trying to Implement wicket as our next MVC framework, Can please someone answer the questions below Hi - about session support - wicket stores the render state of most renderer's in session for different users of the systems. This means large/very large sessions that need to be supported, means memory crunch, performance degradation and implementing the failover at production level really hard. Wicket doesn't store a render state of renderer's (have no clue what that might be). Wicket stores a component tree of last page in session. Btw. this doesn't even sound like a question, it sounds like stating facts, not to mention that the facts are based on wrong assumtptions. Very large sessions? I've seen a model 2 application with sessions over a megabyte. Usually a wicket page is (unless it's a big one - with lot of components) around 30kb (of course this is very relative, this just reflects my experience with most of my wicket based projects). I don't think a 30kb session results in performance degradation or makes implementing failover difficult. - Also it looks like wicket requires code changes when more pages are added and each page needs to have separate handler and it can not be done in configuration file. This may become an issue when number of pages increase in future. What handler? What configuration file? Page has a class that implements the logic (probably what you mean by handler). How is this related to a config file? Wicket doesn't need any config file. There's no external plumbing. I fail to see how this results in an issue with increased page numbers, as the pages are completely independent. Also I'm kinda missing a question mark in this question again, which make it seem like a statement (wrong again as far as I can tell). I'm not sure if that was intended. -Matej Dummy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-Session-Management--tf4721575.html#a13500318 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
