Re: Wicket and tomcat cluster
Dan, thanks for you answer. As you said, with the default implementation of DiskDataStore only the most recent page is kept in the session state and available on all servers. So are using non-sticky sessions and having a stateful page open a modal window with a new stateful page will not work. Correct? On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff dretzl...@gmail.com wrote: Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
Re: Wicket and tomcat cluster
If you go non-sticky you'll need to experiment with RenderStrategy. Each has it's pros and cons, and I don't have experience to advise you further. Yes if you want the user to interact with more than one page at a time you'll need to make sure they're all available. You'll also need to replicate synchronously to all nodes. Since Wicket is a stateful framework, it's simply not well-suited to nonsticky deployment IMO, and you should just enable stickiness. In the off chance of a server failure user loses some page history, but at least they stay logged in and don't lose their current activity. I've wondered at possibility of replication listener on failover nodes that maintains complete local disk page store. Not sure if/which containers provide such hooks. Dan On Mar 29, 2013 1:06 AM, Marios Skounakis msc...@gmail.com wrote: Dan, thanks for you answer. As you said, with the default implementation of DiskDataStore only the most recent page is kept in the session state and available on all servers. So are using non-sticky sessions and having a stateful page open a modal window with a new stateful page will not work. Correct? On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff dretzl...@gmail.com wrote: Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
IE8 error in wicket-date.js when used in a modalwindow
Using the DatePicker in a ModalWindow, I get the error below after using the calendar widget and closing the modal. The widget works fine for me; it's simply throwing a JS error in IE8 (displayed in the lower lefthand corner of the browser). I don't see the error in other browsers. The problematic line in wicket-date.js is this one: YAHOO.wicket[cfg.dpJs].hide(); I can avoid the error simply by adding a condition to the if-statement that is wrapped around the hide method to check that YAHOO.wicket[cfg.dpJs] is not null: if (... YAHOO.wicket[cfg.dpJs]) ... I'm guessing that this is related to the bug fix for https://issues.apache.org/jira/browse/WICKET-4975 -- perhaps the widget is getting destroyed in IE before it can be hidden? Thanks Andrew Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Timestamp: Fri, 29 Mar 2013 17:54:46 UTC Message: 'YAHOO.wicket[...]' is null or not an object Line: 308 Char: 6 Code: 0 URI: http://127.0.0.1:8080/test/wicket/resource/org.apache.wicket.extensions.yui.calendar.DatePicker/wicket-date-ver-1359131272000.js - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicket 1.4.20 ajax download link
In wicket 1.4.20 is it possible to download and do an ajaxupdate , I have a modal window , this has some links each of this link is for download so they are Link and not AjaxLink. I want to close the modal window after users clicks on the download link, I saw this link https://cwiki.apache.org/WICKET/ajax-update-and-file-download-in-one-blow.html, but its for wicket 1.5 is rther anything for wicket 1.4 ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-20-ajax-download-link-tp4657649.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: wicket 1.4.20 ajax download link
Original solution was for 1.4.x... See document history for a 1.4.x solution. On Fri, Mar 29, 2013 at 8:31 PM, fachhoch fachh...@gmail.com wrote: In wicket 1.4.20 is it possible to download and do an ajaxupdate , I have a modal window , this has some links each of this link is for download so they are Link and not AjaxLink. I want to close the modal window after users clicks on the download link, I saw this link https://cwiki.apache.org/WICKET/ajax-update-and-file-download-in-one-blow.html , but its for wicket 1.5 is rther anything for wicket 1.4 ? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-20-ajax-download-link-tp4657649.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 -- Regards - Ernesto Reinaldo Barreiro
Re: IE8 error in wicket-date.js when used in a modalwindow
Please report this in a new issue so that proper action can be taken. On Fri, Mar 29, 2013 at 7:06 PM, Andrew Geery andrew.ge...@gmail.comwrote: Using the DatePicker in a ModalWindow, I get the error below after using the calendar widget and closing the modal. The widget works fine for me; it's simply throwing a JS error in IE8 (displayed in the lower lefthand corner of the browser). I don't see the error in other browsers. The problematic line in wicket-date.js is this one: YAHOO.wicket[cfg.dpJs].hide(); I can avoid the error simply by adding a condition to the if-statement that is wrapped around the hide method to check that YAHOO.wicket[cfg.dpJs] is not null: if (... YAHOO.wicket[cfg.dpJs]) ... I'm guessing that this is related to the bug fix for https://issues.apache.org/jira/browse/WICKET-4975 -- perhaps the widget is getting destroyed in IE before it can be hidden? Thanks Andrew Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Timestamp: Fri, 29 Mar 2013 17:54:46 UTC Message: 'YAHOO.wicket[...]' is null or not an object Line: 308 Char: 6 Code: 0 URI: http://127.0.0.1:8080/test/wicket/resource/org.apache.wicket.extensions.yui.calendar.DatePicker/wicket-date-ver-1359131272000.js - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro
Re: IE8 error in wicket-date.js when used in a modalwindow
Done -- https://issues.apache.org/jira/browse/WICKET-5125 Andrew On Fri, Mar 29, 2013 at 6:13 PM, Ernesto Reinaldo Barreiro reier...@gmail.com wrote: Please report this in a new issue so that proper action can be taken. On Fri, Mar 29, 2013 at 7:06 PM, Andrew Geery andrew.ge...@gmail.comwrote: Using the DatePicker in a ModalWindow, I get the error below after using the calendar widget and closing the modal. The widget works fine for me; it's simply throwing a JS error in IE8 (displayed in the lower lefthand corner of the browser). I don't see the error in other browsers. The problematic line in wicket-date.js is this one: YAHOO.wicket[cfg.dpJs].hide(); I can avoid the error simply by adding a condition to the if-statement that is wrapped around the hide method to check that YAHOO.wicket[cfg.dpJs] is not null: if (... YAHOO.wicket[cfg.dpJs]) ... I'm guessing that this is related to the bug fix for https://issues.apache.org/jira/browse/WICKET-4975 -- perhaps the widget is getting destroyed in IE before it can be hidden? Thanks Andrew Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Timestamp: Fri, 29 Mar 2013 17:54:46 UTC Message: 'YAHOO.wicket[...]' is null or not an object Line: 308 Char: 6 Code: 0 URI: http://127.0.0.1:8080/test/wicket/resource/org.apache.wicket.extensions.yui.calendar.DatePicker/wicket-date-ver-1359131272000.js - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Regards - Ernesto Reinaldo Barreiro - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and tomcat cluster
Thanks, things are a lot clearer for me now. On Fri, Mar 29, 2013 at 4:28 PM, Dan Retzlaff dretzl...@gmail.com wrote: If you go non-sticky you'll need to experiment with RenderStrategy. Each has it's pros and cons, and I don't have experience to advise you further. Yes if you want the user to interact with more than one page at a time you'll need to make sure they're all available. You'll also need to replicate synchronously to all nodes. Since Wicket is a stateful framework, it's simply not well-suited to nonsticky deployment IMO, and you should just enable stickiness. In the off chance of a server failure user loses some page history, but at least they stay logged in and don't lose their current activity. I've wondered at possibility of replication listener on failover nodes that maintains complete local disk page store. Not sure if/which containers provide such hooks. Dan On Mar 29, 2013 1:06 AM, Marios Skounakis msc...@gmail.com wrote: Dan, thanks for you answer. As you said, with the default implementation of DiskDataStore only the most recent page is kept in the session state and available on all servers. So are using non-sticky sessions and having a stateful page open a modal window with a new stateful page will not work. Correct? On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff dretzl...@gmail.com wrote: Sorry I mistyped: default is REDIRECT_TO_BUFFER. On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff dretzl...@gmail.com wrote: Hi Marios, This behavior is determined by IDataStore interface. DiskDataStore is used by default, so only the most recent page is kept in the session (and available for failover). It puts page history into a directory specified in javax.servlet.context.tempdir servlet attribute (under work directory in Tomcat). If you want more page history available on failover, specify a IPageManagerProvider in your Application#init() that constructs HttpSessionDataStore instead. Note HttpSessionDataStore's IDataStoreEvictionStrategy dependency which keeps session usage under control. If Wicket clustering is new to you, also note that Wicket uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details, but in short: you should configure your load balancer for sticky sessions. Dan On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis msc...@gmail.com wrote: Hi all, I 'm planning to setup a terracotta tomcat cluster. The wicket site claims that all Wicket applications will work on a cluster automatically and without additional work . I understand that basically since session state is kept in serializable objects within the http session, it mostly works. But is it true that NO changes are needed? Do I need to change any settings? What does the page store do once it has to push a page from memory to disk? T hanks in advance Marios
