Re: Session creation with stateless pages in Chrome
That's the problem. Session.bind() isn't called. I put a breakpoin in AbstractHttpSessionStore.bind() but still it's hard to tell what's causing this to be called... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659122.html Sent from the Users forum 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: Session creation with stateless pages in Chrome
Hi! Ok, so just to confirm: your original post states that you see a bound wicket session when loading a stateless page with google chrome, but Session.bind() is never called? For as far as I know when wicket binds a sessions it always does so through Session.bind(). So if that is not called, there's another piece of code outside wicket which binds the session. Do you have any other servlets or servlet filters in place? How do you know a wicket session is bound? And how are you checking if Session.bind() is called? Met vriendelijke groet, Kind regards, Bas Gooren Op 29-5-2013 8:36, schreef ChambreNoire: That's the problem. Session.bind() isn't called. I put a breakpoin in AbstractHttpSessionStore.bind() but still it's hard to tell what's causing this to be called... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659122.html Sent from the Users forum 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
Session creation with stateless pages in Chrome
Hello folks, I have rendered all of my pre-login wicket pages fully stateless. I have just noticed that while no wicket sessions are created until a valid login occurs using most browsers, when accessing the site via Google Chrome, the wicket session is bound after the initial rendering. As for various reasons I have opted to extract cetain pageparameters within the wicket session constructor, this is problematic. I suppose could always move this pageparameter extraction into the various stateless pages which need these parameters (and thus duplicate it) however I'd like to know why on earth this happens exclusively with Google Chrome (in case it's symptomatic of some other undetected problem). Any ideas? Thanks, Anthony -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106.html Sent from the Users forum 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: Session creation with stateless pages in Chrome
Have you checked if Chrome is prefetching other pages (which may be stateful)? Met vriendelijke groet, Kind regards, Bas Gooren Op 28-5-2013 12:14, schreef ChambreNoire: Hello folks, I have rendered all of my pre-login wicket pages fully stateless. I have just noticed that while no wicket sessions are created until a valid login occurs using most browsers, when accessing the site via Google Chrome, the wicket session is bound after the initial rendering. As for various reasons I have opted to extract cetain pageparameters within the wicket session constructor, this is problematic. I suppose could always move this pageparameter extraction into the various stateless pages which need these parameters (and thus duplicate it) however I'd like to know why on earth this happens exclusively with Google Chrome (in case it's symptomatic of some other undetected problem). Any ideas? Thanks, Anthony -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106.html Sent from the Users forum 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: Session creation with stateless pages in Chrome
How would I check this? I disabled Predict network actions to improve page load performance but that hasn't changed anything. Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659111.html Sent from the Users forum 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: Session creation with stateless pages in Chrome
Simply by having a look at your tomcat (or reverse proxy) access log? Of course this is only needed if the page you are hitting has links to other, stateful pages. You can also set a breakpoint in Session.bind() to see when it's called. Met vriendelijke groet, Kind regards, Bas Gooren Op 28-5-2013 15:59, schreef ChambreNoire: How would I check this? I disabled Predict network actions to improve page load performance but that hasn't changed anything. Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659111.html Sent from the Users forum 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: Stateless pages
Thanks for your quick response, guys! Got it working. No session expired message for now. Very helpful was the hint on how to decide between new/expired session but also the general information about stateless-ness. And your guide is awesome, Andrea! Can't believe I didn't run across this earlier. Would've saved me some time for sure :) 2013/5/15 Andrea Del Bene an.delb...@gmail.com For a brief introduction to stateless vs stateful pages you can read chapter 6 of free guide: http://code.google.com/p/**wicket-guide/http://code.google.com/p/wicket-guide/ Hey there, i'm currently trying to understand what is actually needed so Wicket considers a page stateful. Could you provide me some basic information on that? Basically, I want the user to authorize for the application and if he's not, he should be send back to the login page. In the case of session timeout, I want to add an error message to the login page, explaining what happened. I thought of using a SimplePageAuthorizationStrateg**y for the authorization part, and solve the session timeout topic by subclassing the LoginPage (as SessionTimeoutReloginPage or something) and register that as the PageExpiredErrorPage. But somehow, I can't get that error page to show up. The SimplePageAuthorizationStrateg**y always sends me straight back to the LoginPage after session timeout. --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Stateless pages
Hey there, i'm currently trying to understand what is actually needed so Wicket considers a page stateful. Could you provide me some basic information on that? Basically, I want the user to authorize for the application and if he's not, he should be send back to the login page. In the case of session timeout, I want to add an error message to the login page, explaining what happened. I thought of using a SimplePageAuthorizationStrategy for the authorization part, and solve the session timeout topic by subclassing the LoginPage (as SessionTimeoutReloginPage or something) and register that as the PageExpiredErrorPage. But somehow, I can't get that error page to show up. The SimplePageAuthorizationStrategy always sends me straight back to the LoginPage after session timeout.
Re: Stateless pages
Hi, On Wed, May 15, 2013 at 4:16 PM, Benedikt Schlegel codecab.dri...@gmail.com wrote: Hey there, i'm currently trying to understand what is actually needed so Wicket considers a page stateful. Could you provide me some basic information on that? A Page is stateless by default. It becomes stateful when: - you call page.setStatelessHint(false) - you add a Component which org.apache.wicket.Component#getStatelessHint() returns false - you add a Behavior which org.apache.wicket.Behavior#getStatelessHint() returns false Basically, I want the user to authorize for the application and if he's not, he should be send back to the login page. In the case of session timeout, I want to add an error message to the login page, explaining what happened. I'm not sure you are able to do this. How you can recognize a request to an expired session versus a completely new request to the app (i.e. there is no session yet) ? I thought of using a SimplePageAuthorizationStrategy for the authorization part, and solve the session timeout topic by subclassing the LoginPage (as SessionTimeoutReloginPage or something) and register that as the PageExpiredErrorPage. PageExpierdErrorPage doesn't mean necessary that the session has expired. PageExpiredException is thrown when a page instance cannot be found in the page store. Reasons could be: - the page is not stored at all (e.g. problems during serialization or simply there is was no store operation for page with id=XYZ) - the store has been overloaded and the oldest page has been removed from it - the session has expired and all pages in the store (i.e. the history stack) has been removed But somehow, I can't get that error page to show up. The SimplePageAuthorizationStrategy always sends me straight back to the LoginPage after session timeout. -- Martin Grigorov Wicket Training Consulting http://jWeekend.com http://jweekend.com/
Re: Stateless pages
For a brief introduction to stateless vs stateful pages you can read chapter 6 of free guide: http://code.google.com/p/wicket-guide/ Hey there, i'm currently trying to understand what is actually needed so Wicket considers a page stateful. Could you provide me some basic information on that? Basically, I want the user to authorize for the application and if he's not, he should be send back to the login page. In the case of session timeout, I want to add an error message to the login page, explaining what happened. I thought of using a SimplePageAuthorizationStrategy for the authorization part, and solve the session timeout topic by subclassing the LoginPage (as SessionTimeoutReloginPage or something) and register that as the PageExpiredErrorPage. But somehow, I can't get that error page to show up. The SimplePageAuthorizationStrategy always sends me straight back to the LoginPage after session timeout. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless pages
Thank you I understand that Wicket reverts back to statefulness if required. Can I get Wicket to log when and why (the offending component) is reverts to statefulness? Is it correct that the number after an URL (ex. host/path?8) indicates the page is stateful? Statefulness concerns me, as I suppose statefulness creates a server side session. The server side session make scaling difficult/more complex, as the session must be replicated or use sticky sessions. My site have not real use for state, but I really like how Wicket does components and rendering. Thanks, -René On 10 December 2012 22:43, Phillips, David david.phill...@usaa.com wrote: setStatelessHint() tells the page to attempt to be stateless, but if any of the components or the behaviors are not stateless than the page will revert back to statefulness. There are several components which have stateless alternatives (StatelessForm and StatelessLink for example), but the very nature of Ajax and it's callback functionality means that the page cannot be stateless. The server must maintain state about the current page for each Ajax request to have the correct starting point. If I may ask, what is it about statefulness that concerns you? Thanks, -David Phillips - USAA -Original Message- From: René Vangsgaard [mailto:rene.vangsga...@gmail.com] Sent: Monday, December 10, 2012 3:29 PM To: users@wicket.apache.org Subject: EXTERNAL: stateless pages I am looking into stateless wicket. Do the setStatelessHint() work as expected? My links are generated correctly, but when the page is rendered a ?#number is rendered - the #number being the normal wicket counter. I read that the presence of this number indicates my page is not stateless. And it is true that any use of Ajax will make a page stateful. On a more general note, I am looking into creating a stateless application, mainly because of scaling. Do you think Wicket will fit, even though I will be using Ajax? I really think the separation of HTML and code, the approach with components and the use of wicket:id is the best, and I have not found it anywhere else. Basically I like Wicket, but do not need the statefulness. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless pages
On Tue, Dec 11, 2012 at 10:02 AM, René Vangsgaard rene.vangsga...@gmail.com wrote: Thank you I understand that Wicket reverts back to statefulness if required. Can I get Wicket to log when and why (the offending component) is reverts to statefulness? There are two ways: 1) add wicket-devutils dependency and use its StatelessChecker 2) Set logging to DEBUG for o.a.w.Page class Is it correct that the number after an URL (ex. host/path?8) indicates the page is stateful? Yes. Statefulness concerns me, as I suppose statefulness creates a server side session. The server side session make scaling difficult/more complex, as the session must be replicated or use sticky sessions. My site have not real use for state, but I really like how Wicket does components and rendering. You may be interested in https://github.com/jolira/wicket-stateless AFAIK it is not migrated to Wicket 6 .. Thanks, -René On 10 December 2012 22:43, Phillips, David david.phill...@usaa.com wrote: setStatelessHint() tells the page to attempt to be stateless, but if any of the components or the behaviors are not stateless than the page will revert back to statefulness. There are several components which have stateless alternatives (StatelessForm and StatelessLink for example), but the very nature of Ajax and it's callback functionality means that the page cannot be stateless. The server must maintain state about the current page for each Ajax request to have the correct starting point. If I may ask, what is it about statefulness that concerns you? Thanks, -David Phillips - USAA -Original Message- From: René Vangsgaard [mailto:rene.vangsga...@gmail.com] Sent: Monday, December 10, 2012 3:29 PM To: users@wicket.apache.org Subject: EXTERNAL: stateless pages I am looking into stateless wicket. Do the setStatelessHint() work as expected? My links are generated correctly, but when the page is rendered a ?#number is rendered - the #number being the normal wicket counter. I read that the presence of this number indicates my page is not stateless. And it is true that any use of Ajax will make a page stateful. On a more general note, I am looking into creating a stateless application, mainly because of scaling. Do you think Wicket will fit, even though I will be using Ajax? I really think the separation of HTML and code, the approach with components and the use of wicket:id is the best, and I have not found it anywhere else. Basically I like Wicket, but do not need the statefulness. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
stateless pages
I am looking into stateless wicket. Do the setStatelessHint() work as expected? My links are generated correctly, but when the page is rendered a ?#number is rendered - the #number being the normal wicket counter. I read that the presence of this number indicates my page is not stateless. And it is true that any use of Ajax will make a page stateful. On a more general note, I am looking into creating a stateless application, mainly because of scaling. Do you think Wicket will fit, even though I will be using Ajax? I really think the separation of HTML and code, the approach with components and the use of wicket:id is the best, and I have not found it anywhere else. Basically I like Wicket, but do not need the statefulness.
RE: stateless pages
setStatelessHint() tells the page to attempt to be stateless, but if any of the components or the behaviors are not stateless than the page will revert back to statefulness. There are several components which have stateless alternatives (StatelessForm and StatelessLink for example), but the very nature of Ajax and it's callback functionality means that the page cannot be stateless. The server must maintain state about the current page for each Ajax request to have the correct starting point. If I may ask, what is it about statefulness that concerns you? Thanks, -David Phillips - USAA -Original Message- From: René Vangsgaard [mailto:rene.vangsga...@gmail.com] Sent: Monday, December 10, 2012 3:29 PM To: users@wicket.apache.org Subject: EXTERNAL: stateless pages I am looking into stateless wicket. Do the setStatelessHint() work as expected? My links are generated correctly, but when the page is rendered a ?#number is rendered - the #number being the normal wicket counter. I read that the presence of this number indicates my page is not stateless. And it is true that any use of Ajax will make a page stateful. On a more general note, I am looking into creating a stateless application, mainly because of scaling. Do you think Wicket will fit, even though I will be using Ajax? I really think the separation of HTML and code, the approach with components and the use of wicket:id is the best, and I have not found it anywhere else. Basically I like Wicket, but do not need the statefulness. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Question re: stateless pages and setResponsePage()
Hi, I have a bunch of stateless pages, each calling setStatelessHint(true) in the constructor to indicate this. I've now noticed that when one of these pages calls setResponsePage, the target page is always considered stateful, since RequestCycle#setResponsePage explicitly resets the hint. Why is this done? Gereon - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Question re: stateless pages and setResponsePage()
Hi, Because you pass an instance of a page and this instance to be reachable in the next request should be stored. Use setResponsePage(Class) instead. Your page is stateless, so instantiating a completely new instance in the next request should be the same. On Mon, Sep 3, 2012 at 9:19 AM, Gereon Steffens gereon.steff...@finanzen100.de wrote: Hi, I have a bunch of stateless pages, each calling setStatelessHint(true) in the constructor to indicate this. I've now noticed that when one of these pages calls setResponsePage, the target page is always considered stateful, since RequestCycle#setResponsePage explicitly resets the hint. Why is this done? Gereon - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WICKET-1.5.6 Feedback messages not updated on stateless pages
Hi Thomas,
It seems WICKET-4468 broke it somehow.
Please file a ticket.
On Sun, May 6, 2012 at 1:55 PM, Thomas Heigl tho...@umschalt.com wrote:
Hello,
I'm currently in the process of migrating a largish Wicket 1.4 application
to 1.5. When moving from 1.5.5 to 1.5.6 something related to feedback
messages breaks.
On all my stateless pages, feedback messages are not rendered anymore when
using:
@Override
protected void onError(AjaxRequestTarget target, Form? form) {
target.addChildren(MyForm.this, FeedbackPanel.class);
}
The form is correctly traversed, all FeedbackPanels are added to the ajax
target, and the ajax response actually contains the updated markup for the
feedback panel. Just the message itself is missing and Wicket shows the
typical Component-targeted feedback message has been left unrendered
message.
I checked the JIRA issues for 1.5.6 but didn't see anything related to
feedback messages. Has there been some intentional change or is something
broken in 1.5.6?
Cheers,
Thomas
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: WICKET-1.5.6 Feedback messages not updated on stateless pages
I've already created the ticket (WICKET-4536) and committed a fix.
Best regards,
Emond
On Monday 07 May 2012 11:13:22 Martin Grigorov wrote:
Hi Thomas,
It seems WICKET-4468 broke it somehow.
Please file a ticket.
On Sun, May 6, 2012 at 1:55 PM, Thomas Heigl tho...@umschalt.com wrote:
Hello,
I'm currently in the process of migrating a largish Wicket 1.4 application
to 1.5. When moving from 1.5.5 to 1.5.6 something related to feedback
messages breaks.
On all my stateless pages, feedback messages are not rendered anymore when
using:
@Override
protected void onError(AjaxRequestTarget target, Form? form) {
target.addChildren(MyForm.this, FeedbackPanel.class);
}
The form is correctly traversed, all FeedbackPanels are added to the ajax
target, and the ajax response actually contains the updated markup for the
feedback panel. Just the message itself is missing and Wicket shows the
typical Component-targeted feedback message has been left unrendered
message.
I checked the JIRA issues for 1.5.6 but didn't see anything related to
feedback messages. Has there been some intentional change or is something
broken in 1.5.6?
Cheers,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
WICKET-1.5.6 Feedback messages not updated on stateless pages
Hello,
I'm currently in the process of migrating a largish Wicket 1.4 application
to 1.5. When moving from 1.5.5 to 1.5.6 something related to feedback
messages breaks.
On all my stateless pages, feedback messages are not rendered anymore when
using:
@Override
protected void onError(AjaxRequestTarget target, Form? form) {
target.addChildren(MyForm.this, FeedbackPanel.class);
}
The form is correctly traversed, all FeedbackPanels are added to the ajax
target, and the ajax response actually contains the updated markup for the
feedback panel. Just the message itself is missing and Wicket shows the
typical Component-targeted feedback message has been left unrendered
message.
I checked the JIRA issues for 1.5.6 but didn't see anything related to
feedback messages. Has there been some intentional change or is something
broken in 1.5.6?
Cheers,
Thomas
Session for Stateless Pages (logged in user)
Hi, I have a web application that contains only stateless pages. I need to allow users to register and login. So I need to store user's login in a session. Could you please advise me how to start session after successful login and make session persistent for stateless pages? Any links to examples would be appreciated. Thanks Sergej Sizov
Re: Session for Stateless Pages (logged in user)
Just call Session.get().bind() after successful login. On Tue, Feb 21, 2012 at 11:04 AM, Sergej Sizov sergej.si...@wincor-nixdorf.cz wrote: Hi, I have a web application that contains only stateless pages. I need to allow users to register and login. So I need to store user's login in a session. Could you please advise me how to start session after successful login and make session persistent for stateless pages? Any links to examples would be appreciated. Thanks Sergej Sizov -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptedUrlWebRequestCodingStrategy, mounted stateless pages and IOException
On Mon, Jun 28, 2010 at 6:36 AM, nmetzger nmetz...@odu.edu wrote: Hi all, I'm running into problems with my CryptedUrlWebRequestCodingStrategy. First a question: I understand that the CryptedUrlWebRequestCodingStrategy creates a http session for all pages, even stateless ones. If I mount my stateless pages in my application, does this override the session creation? (My stateless pages are the homepage, login page, faq etc). the session is created to keep the encryption key the strategy uses. -igor Second, I occasionally see the following error in my application logs, but haven't been able to reproduce it in my test environment. Has any one any idea where this is coming from? I'm using wicket 1.4.9 with Shiro 1.0 Exception: java.lang.IllegalStateException: IOException: Premature end of POST data at com.evermind.server.http.EvermindHttpServletRequest.getParameterMap(EvermindHttpServletRequest.java:1642) at javax.servlet.ServletRequestWrapper.getParameterMap(ServletRequestWrapper.java:211) at org.apache.wicket.protocol.http.servlet.ServletWebRequest.getParameterMap(ServletWebRequest.java:147) at org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy$DecodedUrlRequest.init(CryptedUrlWebRequestCodingStrategy.java:434) at org.apache.wicket.protocol.http.request.CryptedUrlWebRequestCodingStrategy.decode(CryptedUrlWebRequestCodingStrategy.java:124) at org.apache.wicket.Request.getRequestParameters(Request.java:183) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:359) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:275) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:343) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:272) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:83) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:623) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:370) at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:889) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:453) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:313) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:199) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/CryptedUrlWebRequestCodingStrategy-mounted-stateless-pages-and-IOException-tp2270917p2270917.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Don't increment the Session.pageIdCounter for stateless pages?
What about using the @StatelessComponent (moving it from devutils into wicket) as an indicator, that pages are intended to be stateless (_must_ be stateless)? Or introduce a new annotation @StatelessPage? When a page that is intented to be stateless turns to be stateful, it's always an issue (small or big one). Probably there are cases where pages *should* be stateless and it doesn't really matter if they get stateful, but there are also other cases, where pages *must* be stateless, e.g. due to high load. The @Stateless annotation would target the latter cases, where pages *must* be stateless. And in this case, the pageIdCounter should also not be modified. What do you think? Cheers, Martin On Sun, 2010-03-14 at 00:18 +0100, Martin Grotzke wrote: There are cases where pages are intended to be stateless (and might get annotated with @StatelessComponent). At least for these pages the page id should not be incremented, even if the session already has been bound. Cheers, Martin On Sat, 2010-03-13 at 22:58 +0100, Matej Knopp wrote: I'm not sure about all this. If the session has not been bound the page id will always be 0. If the session has been bound, I don't think we shouldn't increment page Id. Stateless page can became stateful any time, not incrementing the id can have sideeffects. -Matej On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, just submitted this as https://issues.apache.org/jira/browse/WICKET-2782 I tried incrementing the pageId when the page's numericId is first accessed, but soon realized, that this does happen rather often (also e.g. to construct bookmarkable page links) ;-) Seems to be not as easy as I thought. Still, it would be really cool if this could be implemented! Cheers, Martin On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote: i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org signature.asc Description: This is a digitally signed message part
Re: Don't increment the Session.pageIdCounter for stateless pages?
Hi, just submitted this as https://issues.apache.org/jira/browse/WICKET-2782 I tried incrementing the pageId when the page's numericId is first accessed, but soon realized, that this does happen rather often (also e.g. to construct bookmarkable page links) ;-) Seems to be not as easy as I thought. Still, it would be really cool if this could be implemented! Cheers, Martin On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote: i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org signature.asc Description: This is a digitally signed message part
Re: Don't increment the Session.pageIdCounter for stateless pages?
I'm not sure about all this. If the session has not been bound the page id will always be 0. If the session has been bound, I don't think we shouldn't increment page Id. Stateless page can became stateful any time, not incrementing the id can have sideeffects. -Matej On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, just submitted this as https://issues.apache.org/jira/browse/WICKET-2782 I tried incrementing the pageId when the page's numericId is first accessed, but soon realized, that this does happen rather often (also e.g. to construct bookmarkable page links) ;-) Seems to be not as easy as I thought. Still, it would be really cool if this could be implemented! Cheers, Martin On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote: i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Don't increment the Session.pageIdCounter for stateless pages?
There are cases where pages are intended to be stateless (and might get annotated with @StatelessComponent). At least for these pages the page id should not be incremented, even if the session already has been bound. Cheers, Martin On Sat, 2010-03-13 at 22:58 +0100, Matej Knopp wrote: I'm not sure about all this. If the session has not been bound the page id will always be 0. If the session has been bound, I don't think we shouldn't increment page Id. Stateless page can became stateful any time, not incrementing the id can have sideeffects. -Matej On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, just submitted this as https://issues.apache.org/jira/browse/WICKET-2782 I tried incrementing the pageId when the page's numericId is first accessed, but soon realized, that this does happen rather often (also e.g. to construct bookmarkable page links) ;-) Seems to be not as easy as I thought. Still, it would be really cool if this could be implemented! Cheers, Martin On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote: i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org signature.asc Description: This is a digitally signed message part
AW: Re: Don't increment the Session.pageIdCounter for stateless pages?
From my basic understanding I'd say that for stateless pages nothing should depend on the pageId. What do you think about incrementing the pageId when it's first accessed? I'd like to create a patch for it to see if this works. Cheers, Martin -- Urspr. Mitt. -- Betreff: Re: Don't increment the Session.pageIdCounter for stateless pages? Von: Igor Vaynberg igor.vaynb...@gmail.com Datum: 10.03.2010 17:50 i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Re: Don't increment the Session.pageIdCounter for stateless pages?
patches are always welcome. -igor On Thu, Mar 11, 2010 at 1:23 PM, martin.grot...@javakaffee.de wrote: From my basic understanding I'd say that for stateless pages nothing should depend on the pageId. What do you think about incrementing the pageId when it's first accessed? I'd like to create a patch for it to see if this works. Cheers, Martin -- Urspr. Mitt. -- Betreff: Re: Don't increment the Session.pageIdCounter for stateless pages? Von: Igor Vaynberg igor.vaynb...@gmail.com Datum: 10.03.2010 17:50 i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Don't increment the Session.pageIdCounter for stateless pages?
i think we can do this in 1.5 i would rather not mess with 1.4 because i think there is a lot of code there that depends on the fact that the id is available right away. please create a jira issue for this -igor On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke martin.grot...@javakaffee.de wrote: Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Don't increment the Session.pageIdCounter for stateless pages?
Hi, the Page.init(PageMap) invokes setNextAvailableId(), which invokes getSession().nextPageId() if isPageIdUniquePerSession is set. getSession().nextPageId() modifies the Session.pageIdCounter. When I have a session and afterwards access a stateless page, the Session.pageIdCounter is the only data that is changed in the session AFAICS, everything else is the same as in the request before. Is it possible _not_ to modify the Session.pageIdCounter if the page is really stateless (or just don't invoke Page.setNextAvailableId())? I'm interested in this, as I'm just implementing a feature for the memcached-session-manager ([1], memcached based session replication), which checks if session data has changed and replicates sessions only if this is provided. If session data did not change, the replication is omitted. Therefore, if the Session.pageIdCounter would be left unchanged for stateless pages, this would allow to make use of this feature in wicket apps. Thanx cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ signature.asc Description: This is a digitally signed message part
Re: Lazy loading via AJAX on stateless pages?
stateless pages
with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I
want.
Basically I have a simple page where I added an AjaxBehavior to a
label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded
asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript(
getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS
because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired
on the AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grotzke
http://www.javakaffee.de/blog/
signature.asc
Description: This is a digitally signed message part
Re: Lazy loading via AJAX on stateless pages?
What exactly causes the page to be stateful when urlFor(Component,
Interface) is invoked?
I would like to make only minimal changes compared to original wicket
ajax handling and would really like to reuse as much as possible of
wicket ajax handling (e.g. adding components to be updated to the
AjaxRequestTarget).
Do you think it would be possible to create a Behavior that uses a
callback url which links to a (stateless) page with page parameters.
This page provides a constructor taking parameters and sets an
AjaxRequestTarget on the RequestCycle. It creates and adds all
components which shall be changed to the target.
What do you think? Can you imagine other ways of being as close as
possible to wicket?
Thanx cheers,
Martin
On Fri, 2009-04-17 at 15:40 -0700, Igor Vaynberg wrote:
sure, you can use behaviors and requesttargets of whatever kind. just
make sure nothing on your page calls urlfor(component, interface) -
this is what causes the page to be stateful.
-igor
On Fri, Apr 17, 2009 at 3:14 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Wow, very fast response!
Is it possible to use wicket concepts like RequestTarget and Behavior on
the serverside? I'd like to have this integrated with wicket as much as
possible.
Cheers,
Martin
On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
you cannot use wicket ajax facilities as they are designed for
stateful pages - the link that wicket uses for ajax callback is
inherently stateful.
what you can do is write javascript yourself using jquery, or
something else to perform an ajax callback to some url you control and
then replace some markup on your page with returned markup.
-igor
On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Hello,
can somebody help with this?
Thanx cheers,
Martin
On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
Hi,
I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I want.
Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded
asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript(
getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired on
the AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
signature.asc
Description: This is a digitally signed message part
Re: Lazy loading via AJAX on stateless pages?
Using urlFor(...) generates a stateful, session-relative link - unless you
call urlFor(Class, PageParameters) - which is stateless because it encodes
the class and parameters in the URL. In the other URLs, the state is stored
in the session, and the URL is basically a map to navigate the component
tree to get back to the component that generated the URL.
--
Jeremy Thomerson
http://www.wickettraining.com
On Sat, Apr 18, 2009 at 4:27 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
What exactly causes the page to be stateful when urlFor(Component,
Interface) is invoked?
I would like to make only minimal changes compared to original wicket
ajax handling and would really like to reuse as much as possible of
wicket ajax handling (e.g. adding components to be updated to the
AjaxRequestTarget).
Do you think it would be possible to create a Behavior that uses a
callback url which links to a (stateless) page with page parameters.
This page provides a constructor taking parameters and sets an
AjaxRequestTarget on the RequestCycle. It creates and adds all
components which shall be changed to the target.
What do you think? Can you imagine other ways of being as close as
possible to wicket?
Thanx cheers,
Martin
On Fri, 2009-04-17 at 15:40 -0700, Igor Vaynberg wrote:
sure, you can use behaviors and requesttargets of whatever kind. just
make sure nothing on your page calls urlfor(component, interface) -
this is what causes the page to be stateful.
-igor
On Fri, Apr 17, 2009 at 3:14 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Wow, very fast response!
Is it possible to use wicket concepts like RequestTarget and Behavior
on
the serverside? I'd like to have this integrated with wicket as much as
possible.
Cheers,
Martin
On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
you cannot use wicket ajax facilities as they are designed for
stateful pages - the link that wicket uses for ajax callback is
inherently stateful.
what you can do is write javascript yourself using jquery, or
something else to perform an ajax callback to some url you control and
then replace some markup on your page with returned markup.
-igor
On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Hello,
can somebody help with this?
Thanx cheers,
Martin
On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.dewrote:
Hi,
I'm currently evaluating how it's possible to have stateless pages
with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I
want.
Basically I have a simple page where I added an AjaxBehavior to a
label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded
asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript(
getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS
because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired
on the AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lazy loading via AJAX on stateless pages?
Hello,
can somebody help with this?
Thanx cheers,
Martin
On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
Hi,
I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I want.
Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript( getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired on the
AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
signature.asc
Description: This is a digitally signed message part
Re: Lazy loading via AJAX on stateless pages?
you cannot use wicket ajax facilities as they are designed for
stateful pages - the link that wicket uses for ajax callback is
inherently stateful.
what you can do is write javascript yourself using jquery, or
something else to perform an ajax callback to some url you control and
then replace some markup on your page with returned markup.
-igor
On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Hello,
can somebody help with this?
Thanx cheers,
Martin
On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
Hi,
I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I want.
Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript( getCallbackScript().toString()
);
}
} );
This turns the previously statelesss page to stateful, AFAICS because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired on the
AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lazy loading via AJAX on stateless pages?
Wow, very fast response!
Is it possible to use wicket concepts like RequestTarget and Behavior on
the serverside? I'd like to have this integrated with wicket as much as
possible.
Cheers,
Martin
On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
you cannot use wicket ajax facilities as they are designed for
stateful pages - the link that wicket uses for ajax callback is
inherently stateful.
what you can do is write javascript yourself using jquery, or
something else to perform an ajax callback to some url you control and
then replace some markup on your page with returned markup.
-igor
On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Hello,
can somebody help with this?
Thanx cheers,
Martin
On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
Hi,
I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I want.
Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded asynchronously
);
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript(
getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired on the
AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
signature.asc
Description: This is a digitally signed message part
Re: Lazy loading via AJAX on stateless pages?
sure, you can use behaviors and requesttargets of whatever kind. just
make sure nothing on your page calls urlfor(component, interface) -
this is what causes the page to be stateful.
-igor
On Fri, Apr 17, 2009 at 3:14 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Wow, very fast response!
Is it possible to use wicket concepts like RequestTarget and Behavior on
the serverside? I'd like to have this integrated with wicket as much as
possible.
Cheers,
Martin
On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
you cannot use wicket ajax facilities as they are designed for
stateful pages - the link that wicket uses for ajax callback is
inherently stateful.
what you can do is write javascript yourself using jquery, or
something else to perform an ajax callback to some url you control and
then replace some markup on your page with returned markup.
-igor
On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
martin.grot...@javakaffee.de wrote:
Hello,
can somebody help with this?
Thanx cheers,
Martin
On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
Hi,
I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I want.
Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded
asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript(
getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired on the
AJAX request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Lazy loading via AJAX on stateless pages?
Hi,
I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.
I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
but I'm not sure what exactly has to be done to achieve what I want.
Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:
final Label label = new Label( info, foo );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( info, loaded asynchronously );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}
@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript( getCallbackScript().toString() );
}
} );
This turns the previously statelesss page to stateful, AFAICS because of
getStatelessHint( Component component )
returning false for the label.
When I change this to return true, wicket says the page is expired on the AJAX
request...
Can anybody say what had to be done?
Btw: I'm using wicket-1.4-SNAPSHOT.
Thanx in advance,
cheers,
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page pooling (for stateless pages)
stateless != static, though If you cache the results of a stateless page, you could show stale information from the database, correct? On Mon, May 19, 2008 at 1:18 AM, Erik van Oosten [EMAIL PROTECTED] wrote: Hello, I think it would probably make more sense to cache the /result/ of stateless pages. Regards, Erik. Joel Halbert wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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: Page pooling (for stateless pages)
On Sun, May 18, 2008 at 11:04 PM, James Carman [EMAIL PROTECTED] wrote: stateless != static, though If you cache the results of a stateless page, you could show stale information from the database, correct? True, so it depends on your use case. And obviously it wouldn't work for form processing either. But for - say - a catalogue site where hourly updates are good enough (in which case you would invalidate the cache every hour), it might be an option. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
In our use case all the pages are stateless, but they are by no means static. We have in fact designed the entire site to use stateless pages, again for scalability; but every single page is also dynamic. I would like to produce and share some metrics from the JVM around object allocation and collection for a wicket application that is under sustained load using JMeter, and will do so as and when these become available. If anyone has any concise testing strategies along these lines please share them Joel -- From: Eelco Hillenius [EMAIL PROTECTED] Sent: Monday, May 19, 2008 7:18 AM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) On Sun, May 18, 2008 at 11:04 PM, James Carman [EMAIL PROTECTED] wrote: stateless != static, though If you cache the results of a stateless page, you could show stale information from the database, correct? True, so it depends on your use case. And obviously it wouldn't work for form processing either. But for - say - a catalogue site where hourly updates are good enough (in which case you would invalidate the cache every hour), it might be an option. Eelco - 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]
Page pooling (for stateless pages)
Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel
Re: Page pooling (for stateless pages)
Hi, first of all, I don't really think it's worth pooling pages. I can't imagine that page instance creation would have that much overhead. Also stateless pages doesn't mean they don't contain any state. The page is stateless because it's not kept between requests, but during request there's lot going on with the page. So you can't just reuse the instances. -Matej On Sun, May 18, 2008 at 1:10 PM, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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: Page pooling (for stateless pages)
The overhead incurred would of course depend on the number or requests the app was receiving, the amount of available memory and the efficiency of the chosen GC algorithm. I agree that object creation and collection is relatively efficient these days, but pooling still makes sense where it can be implemented. I noted that Tapestry 5 has chosen to implement stateless pages and pooling of these by default. -- From: Matej Knopp [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:25 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) Hi, first of all, I don't really think it's worth pooling pages. I can't imagine that page instance creation would have that much overhead. Also stateless pages doesn't mean they don't contain any state. The page is stateless because it's not kept between requests, but during request there's lot going on with the page. So you can't just reuse the instances. -Matej On Sun, May 18, 2008 at 1:10 PM, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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: Page pooling (for stateless pages)
We are not tapestry 5. :D Seriously: page pooling is not good for scalabity. You need to apply locks to prevent multiple threads to access the same instance, etc. There is a whole lot of additional stuff you need to make this work, adding complexity for little or quite possibly no gain at all. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I would agree it's not always going to give much mileage. Given that there is no heavy weight initialization going on with pages I would tend to agree. The JVM should be able to cope with many 10's of thousands of objects created destroyed per sec, more or less system dependent, so long as they are all young gen objects. And with parallel gc this should result in minimal effect on an application. -- From: Martijn Dashorst [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:42 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) We are not tapestry 5. :D Seriously: page pooling is not good for scalabity. You need to apply locks to prevent multiple threads to access the same instance, etc. There is a whole lot of additional stuff you need to make this work, adding complexity for little or quite possibly no gain at all. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - 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: Page pooling (for stateless pages)
I agree with Johan. Stateless in Wicket sense means that we don't keep the page in memory but recreate it from scratch. This means that we don't roll back state. Pooling requires us (the framework or the users) to rollback any state that was accumulated during rendering. This is really not an avenue I want to pursue. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
If you were to add in pooling, you'd have to either provide a new hook (new lifecycle method) or a warning to the user (as you mentioned) that they have to rollback the state themselves after rendering using onAfterRender() or something. On Sun, May 18, 2008 at 8:23 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: I agree with Johan. Stateless in Wicket sense means that we don't keep the page in memory but recreate it from scratch. This means that we don't roll back state. Pooling requires us (the framework or the users) to rollback any state that was accumulated during rendering. This is really not an avenue I want to pursue. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - 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: Page pooling (for stateless pages)
do you have a benchmark that shows that pooling is indeed faster? servlets are pooled because they may require heavy initialization. wicket pages are much more lightweight in comparison. -igor On Sun, May 18, 2008 at 4:36 AM, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - 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: Page pooling (for stateless pages)
On Sun, May 18, 2008 at 9:47 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: do you have a benchmark that shows that pooling is indeed faster? servlets are pooled because they may require heavy initialization. wicket pages are much more lightweight in comparison. And, the more heavyweight you make your page, the more likely that it isn't stateless anymore anyway. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? I think you can just implement the pooling mechanism yourself, and provide a custom version of IPageFactory (which is to be set in session settings). Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. Like other team members, I doubt this :-) Like any advantages you might have will be lost by the need to synchronize. And if your page is really heavy to construct, that is probably a sign that you should move your 'heavy code' (probably database access?) to the rendering phase (like using lazy initialized models and algorithms for components such as overriding isVisible rather than setting it). But nothing beats real numbers, and it may be worth it for your case. Let us know if it made a difference for you. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
Yes. That's what I would do. Build your application (or better yet build a quick prototype to test your scalability) simply and then profile it. If there are any hotspots, look at them then. Ayodeji Aladejebi wrote: Why do ppl really like doing extra work trying to help Wicket? For me, short of making proper use of Models and Bookmarkable Pages and buying extra hardware where possible, I dont really crack my head too much on certain things. I kind of trust the highly skillful wicket team to do their job when it comes to evolving a high performant framework. just my thots On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Thanks all for the feedback. Given that there is no heavy initialisation going on in any of our pages I would tend to agree that page construction, should be fairly cheap, and would certainly be cheaper than any constant contended synchronisation. I however keep an eye on it and let you know of any metrics that we produce. Thx, Joel -- From: Eelco Hillenius [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 5:58 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? I think you can just implement the pooling mechanism yourself, and provide a custom version of IPageFactory (which is to be set in session settings). Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. Like other team members, I doubt this :-) Like any advantages you might have will be lost by the need to synchronize. And if your page is really heavy to construct, that is probably a sign that you should move your 'heavy code' (probably database access?) to the rendering phase (like using lazy initialized models and algorithms for components such as overriding isVisible rather than setting it). But nothing beats real numbers, and it may be worth it for your case. Let us know if it made a difference for you. Eelco - 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/Page-pooling-%28for-stateless-pages%29-tp17301659p17307591.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: Page pooling (for stateless pages)
Hello, I think it would probably make more sense to cache the /result/ of stateless pages. Regards, Erik. Joel Halbert wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I think it would probably make more sense to cache the /result/ of stateless pages. Yeah, that might make quite the difference. The best place for that would be a filter, probably defined before the Wicket filter. Tons of different options as well though. And definitively something I would only investigate if I was either experience scaling problems or would have a scale that I would know upfront it might save a bunch of servers. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stateless pages and performance
Jonathan Locke schrieb: hi Jonathan Until you've got a handle on your scaling problem (and it probably is that and not a performance problem) and you know what needs to be tuned, the best policy is probably to just build something simply and quickly in order to discover if you even have a problem that requires this solution. talking about scalability, you posted a CachedPanel on your blog once. unfortunately it seems to be gone. is this still floating around anywhere? thx uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stateless pages and performance
Hi guys, In the release notes, I read: stateless pages and components for those parts of your application that needs to scale to extremely large numbers of users. Does somebody use this feature or is it somewhere documented? What do I have to do and what are the differences from a 'normal' wicket app? Regards, -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29
Re: Stateless pages and performance
On Jan 19, 2008 5:18 AM, Martijn Lindhout [EMAIL PROTECTED] wrote: Hi guys, In the release notes, I read: stateless pages and components for those parts of your application that needs to scale to extremely large numbers of users. Does somebody use this feature or is it somewhere documented? What do I have to do and what are the differences from a 'normal' wicket app? Stateless pages can be a good option for things like public home pages etc; pages where you don't have a crazy amount of functionality, but that get hit hard. More interesting imho than the scalability argument is that such stateless pages are always bookmarkable. This makes them very useful for e.g. login pages, where you can expect clients to directly go to, or maybe have in the background for an extended time before actually using it. Read about it here: http://cwiki.apache.org/WICKET/stateless-pages.html and take a look at org.apache.wicket.examples.stateless in wicket-examples. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stateless pages and performance
As always, the caveat is that you should avoid premature optimization like the plague. Until you've got a handle on your scaling problem (and it probably is that and not a performance problem) and you know what needs to be tuned, the best policy is probably to just build something simply and quickly in order to discover if you even have a problem that requires this solution. Martijn Lindhout wrote: Hi guys, In the release notes, I read: stateless pages and components for those parts of your application that needs to scale to extremely large numbers of users. Does somebody use this feature or is it somewhere documented? What do I have to do and what are the differences from a 'normal' wicket app? Regards, -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29 -- View this message in context: http://www.nabble.com/Stateless-pages-and-performance-tp14970238p14975570.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]
Ajax History Back support on Stateless pages
Hi I have a stateless page which holds product datas. And it has a tab component which uses Ajax. I know a way to do it with Page Bookmarks (#tabName). But i wonder is there any other solution or any pattern to implement this issue better? Thanks fatih -- View this message in context: http://www.nabble.com/Ajax-History-Back-support-on-Stateless-pages-tp14556855p14556855.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: Ajax History Back support on Stateless pages
As far as I understand your page will not be stateless anymore once you use ajax. Am 31.12.2007 um 12:59 schrieb based: Hi I have a stateless page which holds product datas. And it has a tab component which uses Ajax. I know a way to do it with Page Bookmarks (#tabName). But i wonder is there any other solution or any pattern to implement this issue better? Thanks fatih -- View this message in context: http://www.nabble.com/Ajax-History-Back-support-on-Stateless-pages-tp14556855p14556855.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]
