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=65&cpage=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 >
Wicket Session Management
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 wrote: > > 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 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-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
Wicket - Session Management
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 (constructor called twice)
et.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) >>> -- >>> View this message in context: >>> http://www.nabble.com/Wicket-Session-Management-%28constructor-called-twice%29-tp17956814p17956814.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/Wicket-Session-Management-%28constructor-called-twice%29-tp17956814p17957430.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: Wicket Session Management (constructor called twice)
ilter(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) >> -- >> View this message in context: >> http://www.nabble.com/Wicket-Session-Management-%28constructor-called-twice%29-tp17956814p17956814.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/Wicket-Session-Management-%28constructor-called-twice%29-tp17956814p17957430.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: Wicket Session Management (constructor called twice)
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) > -- > View this message in context: > http://www.nabble.com/Wicket-Session-Management-%28constructor-called-twice%29-tp17956814p17956814.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]
Wicket Session Management (constructor called twice)
ticatedWebApplication.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.Application$1.onInstantiation(Application.java:276) at org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:973) at org.apache.wicket.Component.(Component.java:866) at org.apache.wicket.MarkupContainer.(MarkupContainer.java:104) at org.apache.wicket.Page.(Page.java:231) at org.apache.wicket.markup.html.WebPage.(WebPage.java:184) at com.semantra.web.components.page.SemantraPage.(SemantraPage.java:14) at com.semantra.web.components.page.LicensedWebPage.(LicensedWebPage.java:21) at com.semantra.web.components.page.InquiryPage.(InquiryPage.java:106) 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.session.DefaultPageFactory.newPage(DefaultPageFactory.java:154) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:66) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1094) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1169) 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) -- View this message in context: http://www.nabble.com/Wicket-Session-Management-%28constructor-called-twice%29-tp17956814p17956814.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe
Re: Explanation of Wicket session management
Yes that is true,
Session is lazy created in Session.get() so only after the first time that
is called Session.exists() works.
I guess Session.exists() doesnt really make much sense
On Tue, Mar 11, 2008 at 8:29 PM, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> I have updated the code based on Johan's suggestion. Still no luck.
>
>
> public Session newSession(Request request, Response response) {
> ..
> Session session = new Session(request);
> return session;
> }
>
>
> public RequestCycle newRequestCycle(Request request, Response response) {
> return new WebRequestCycle(this, request, response) {
> if(Session.exists() && ) { <- The
> method Session.exists() still returns false
>Session mySession = Session.get();
>mySession.invalidateNow();
> }
>
> };
> }
>
>
> On Tue, Mar 11, 2008 at 12:02 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
> > RequestCycle is first made and the the Session is being resolved.
> > Because the session creation code needs the request cycle first.
> > So thats why your code doesn't work
> >
> > that test that you want should be done in Requestcycle.onBeginRequest
> >
> >
> >
> > On Tue, Mar 11, 2008 at 4:47 PM, Rajiv Jivan <[EMAIL PROTECTED]>
> wrote:
> >
> > > Yes I did. I was assuming that once newSession is called, on
> > > subsequent calls, the session will be set on a thread local variable.
> > > If that is not the case, what would be the right way to check if a
> > > session has been created.
> > >
> > > On Tue, Mar 11, 2008 at 10:32 AM, Martijn Dashorst
> > > <[EMAIL PROTECTED]> wrote:
> > > > Did you read the javadoc for Session#exists() ?
> > > >
> > > > http://wicket.sourceforge.net/apidocs/wicket/Session.html#exists()
> > > >
> > > > "Checks if the Session threadlocal is set in this thread"
> > > >
> > > > So not if the session was created or not.
> > > >
> > > > Martijn
> > > >
> > > >
> > > >
> > > >
> > > > On 3/11/08, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> > > > > I am having a tough time understanding how sessions are
> > > > > created/managed specifically related to the calls
> > > > >
> > > > > public RequestCycle newRequestCycle(Request request, Response
> > > response)
> > > > >
> > > > > and
> > > > >
> > > > > public Session newSession(Request request, Response response)
> > > > >
> > > > > I am creating a new session by overriding the method newSession
> and
> > > > > doing something like
> > > > >
> > > > > public Session newSession(Request request, Response response) {
> > > > >..
> > > > >Session session = new Session(request);
> > > > >return session;
> > > > > }
> > > > >
> > > > > This works fine. On subsequent calls, newSession isn't called
> as a
> > > > > session is already in place. This is working as expected.
> > > > >
> > > > > What isn't working is the call
> > > > > to Session.exists(), this is always returning false when its
> invoked
> > > > > in the method newRequestCycle which I override.
> > > > >
> > > > > public RequestCycle newRequestCycle(Request request, Response
> > > response) {
> > > > > if(Session.exists() && ) {
> <-
> > > The
> > > > > method Session.exists() is always returning false
> > > > > Session mySession = Session.get();
> > > > > mySession.invalidateNow();
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > Can someone explain why Session.exists() always returns false,
> and
> > > if
> > > > > the session truly doesn't exist why newSession isn't called
> after
> > > the
> > > > > first invocation
> > > > >
> > > > >
> > >
> -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Buy Wicket in Action: http://manning.com/dashorst
> > > > Apache Wicket 1.3.1 is released
> > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
> > > >
> > > >
> -
> > > > 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]
> > >
> > >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Explanation of Wicket session management
I have updated the code based on Johan's suggestion. Still no luck.
public Session newSession(Request request, Response response) {
..
Session session = new Session(request);
return session;
}
public RequestCycle newRequestCycle(Request request, Response response) {
return new WebRequestCycle(this, request, response) {
if(Session.exists() && ) { <- The
method Session.exists() still returns false
Session mySession = Session.get();
mySession.invalidateNow();
}
};
}
On Tue, Mar 11, 2008 at 12:02 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> RequestCycle is first made and the the Session is being resolved.
> Because the session creation code needs the request cycle first.
> So thats why your code doesn't work
>
> that test that you want should be done in Requestcycle.onBeginRequest
>
>
>
> On Tue, Mar 11, 2008 at 4:47 PM, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
>
> > Yes I did. I was assuming that once newSession is called, on
> > subsequent calls, the session will be set on a thread local variable.
> > If that is not the case, what would be the right way to check if a
> > session has been created.
> >
> > On Tue, Mar 11, 2008 at 10:32 AM, Martijn Dashorst
> > <[EMAIL PROTECTED]> wrote:
> > > Did you read the javadoc for Session#exists() ?
> > >
> > > http://wicket.sourceforge.net/apidocs/wicket/Session.html#exists()
> > >
> > > "Checks if the Session threadlocal is set in this thread"
> > >
> > > So not if the session was created or not.
> > >
> > > Martijn
> > >
> > >
> > >
> > >
> > > On 3/11/08, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> > > > I am having a tough time understanding how sessions are
> > > > created/managed specifically related to the calls
> > > >
> > > > public RequestCycle newRequestCycle(Request request, Response
> > response)
> > > >
> > > > and
> > > >
> > > > public Session newSession(Request request, Response response)
> > > >
> > > > I am creating a new session by overriding the method newSession and
> > > > doing something like
> > > >
> > > > public Session newSession(Request request, Response response) {
> > > >..
> > > >Session session = new Session(request);
> > > >return session;
> > > > }
> > > >
> > > > This works fine. On subsequent calls, newSession isn't called as a
> > > > session is already in place. This is working as expected.
> > > >
> > > > What isn't working is the call
> > > > to Session.exists(), this is always returning false when its invoked
> > > > in the method newRequestCycle which I override.
> > > >
> > > > public RequestCycle newRequestCycle(Request request, Response
> > response) {
> > > > if(Session.exists() && ) { <-
> > The
> > > > method Session.exists() is always returning false
> > > > Session mySession = Session.get();
> > > > mySession.invalidateNow();
> > > > }
> > > > }
> > > > }
> > > >
> > > > Can someone explain why Session.exists() always returns false, and
> > if
> > > > the session truly doesn't exist why newSession isn't called after
> > the
> > > > first invocation
> > > >
> > > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > > --
> > > Buy Wicket in Action: http://manning.com/dashorst
> > > Apache Wicket 1.3.1 is released
> > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
> > >
> > > -
> > > 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]
> >
> >
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explanation of Wicket session management
RequestCycle is first made and the the Session is being resolved.
Because the session creation code needs the request cycle first.
So thats why your code doesn't work
that test that you want should be done in Requestcycle.onBeginRequest
On Tue, Mar 11, 2008 at 4:47 PM, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> Yes I did. I was assuming that once newSession is called, on
> subsequent calls, the session will be set on a thread local variable.
> If that is not the case, what would be the right way to check if a
> session has been created.
>
> On Tue, Mar 11, 2008 at 10:32 AM, Martijn Dashorst
> <[EMAIL PROTECTED]> wrote:
> > Did you read the javadoc for Session#exists() ?
> >
> > http://wicket.sourceforge.net/apidocs/wicket/Session.html#exists()
> >
> > "Checks if the Session threadlocal is set in this thread"
> >
> > So not if the session was created or not.
> >
> > Martijn
> >
> >
> >
> >
> > On 3/11/08, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> > > I am having a tough time understanding how sessions are
> > > created/managed specifically related to the calls
> > >
> > > public RequestCycle newRequestCycle(Request request, Response
> response)
> > >
> > > and
> > >
> > > public Session newSession(Request request, Response response)
> > >
> > > I am creating a new session by overriding the method newSession and
> > > doing something like
> > >
> > > public Session newSession(Request request, Response response) {
> > >..
> > >Session session = new Session(request);
> > >return session;
> > > }
> > >
> > > This works fine. On subsequent calls, newSession isn't called as a
> > > session is already in place. This is working as expected.
> > >
> > > What isn't working is the call
> > > to Session.exists(), this is always returning false when its invoked
> > > in the method newRequestCycle which I override.
> > >
> > > public RequestCycle newRequestCycle(Request request, Response
> response) {
> > > if(Session.exists() && ) { <-
> The
> > > method Session.exists() is always returning false
> > > Session mySession = Session.get();
> > > mySession.invalidateNow();
> > > }
> > > }
> > > }
> > >
> > > Can someone explain why Session.exists() always returns false, and
> if
> > > the session truly doesn't exist why newSession isn't called after
> the
> > > first invocation
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.1 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
> >
> > -
> > 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: Explanation of Wicket session management
Yes I did. I was assuming that once newSession is called, on
subsequent calls, the session will be set on a thread local variable.
If that is not the case, what would be the right way to check if a
session has been created.
On Tue, Mar 11, 2008 at 10:32 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
> Did you read the javadoc for Session#exists() ?
>
> http://wicket.sourceforge.net/apidocs/wicket/Session.html#exists()
>
> "Checks if the Session threadlocal is set in this thread"
>
> So not if the session was created or not.
>
> Martijn
>
>
>
>
> On 3/11/08, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> > I am having a tough time understanding how sessions are
> > created/managed specifically related to the calls
> >
> > public RequestCycle newRequestCycle(Request request, Response response)
> >
> > and
> >
> > public Session newSession(Request request, Response response)
> >
> > I am creating a new session by overriding the method newSession and
> > doing something like
> >
> > public Session newSession(Request request, Response response) {
> >..
> >Session session = new Session(request);
> >return session;
> > }
> >
> > This works fine. On subsequent calls, newSession isn't called as a
> > session is already in place. This is working as expected.
> >
> > What isn't working is the call
> > to Session.exists(), this is always returning false when its invoked
> > in the method newRequestCycle which I override.
> >
> > public RequestCycle newRequestCycle(Request request, Response response) {
> > if(Session.exists() && ) { <- The
> > method Session.exists() is always returning false
> > Session mySession = Session.get();
> > mySession.invalidateNow();
> > }
> > }
> > }
> >
> > Can someone explain why Session.exists() always returns false, and if
> > the session truly doesn't exist why newSession isn't called after the
> > first invocation
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
>
> -
> 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: Explanation of Wicket session management
Did you read the javadoc for Session#exists() ?
http://wicket.sourceforge.net/apidocs/wicket/Session.html#exists()
"Checks if the Session threadlocal is set in this thread"
So not if the session was created or not.
Martijn
On 3/11/08, Rajiv Jivan <[EMAIL PROTECTED]> wrote:
> I am having a tough time understanding how sessions are
> created/managed specifically related to the calls
>
> public RequestCycle newRequestCycle(Request request, Response response)
>
> and
>
> public Session newSession(Request request, Response response)
>
> I am creating a new session by overriding the method newSession and
> doing something like
>
> public Session newSession(Request request, Response response) {
>..
>Session session = new Session(request);
>return session;
> }
>
> This works fine. On subsequent calls, newSession isn't called as a
> session is already in place. This is working as expected.
>
> What isn't working is the call
> to Session.exists(), this is always returning false when its invoked
> in the method newRequestCycle which I override.
>
> public RequestCycle newRequestCycle(Request request, Response response) {
> if(Session.exists() && ) { <- The
> method Session.exists() is always returning false
> Session mySession = Session.get();
> mySession.invalidateNow();
> }
> }
> }
>
> Can someone explain why Session.exists() always returns false, and if
> the session truly doesn't exist why newSession isn't called after the
> first invocation
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Explanation of Wicket session management
I am having a tough time understanding how sessions are
created/managed specifically related to the calls
public RequestCycle newRequestCycle(Request request, Response response)
and
public Session newSession(Request request, Response response)
I am creating a new session by overriding the method newSession and
doing something like
public Session newSession(Request request, Response response) {
..
Session session = new Session(request);
return session;
}
This works fine. On subsequent calls, newSession isn't called as a
session is already in place. This is working as expected.
What isn't working is the call
to Session.exists(), this is always returning false when its invoked
in the method newRequestCycle which I override.
public RequestCycle newRequestCycle(Request request, Response response) {
if(Session.exists() && ) { <- The
method Session.exists() is always returning false
Session mySession = Session.get();
mySession.invalidateNow();
}
}
}
Can someone explain why Session.exists() always returns false, and if
the session truly doesn't exist why newSession isn't called after the
first invocation
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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?
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]
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]
Wicket Session Management?
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 - 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. - 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. Dummy -- View this message in context: http://www.nabble.com/Wicket-Session-Management--tf4721575.html#a13498748 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
