Re: Wicket in JBoss cluster
Thanks guys, I think I understand now what's going on. Does anyone know which configuration settings are needed for JBoss 4.2 to make things work? 2009/10/23 Randy S. > Oh I see. Thanks for the explanation. > > I can't comment on JBoss's session replication. I'm familiar with websphere > with a DB-backed session which does not deserialize until it has to re-load > from the DB, either because you bounced nodes or had the session expunged > from memory due to the limit of in-memory sessions. > > On Oct 22, 2009 5:41 PM, "Matej Knopp" wrote: > > Not quite. On every request when page is changed and the session with > page is replicated on cluster the receiving nodes should store the > page to diskpagestore. This way every state of page should be saved. > But this will only work if the container deserializes sessions > immediately after replication. > > -Matej > > On Fri, Oct 23, 2009 at 12:00 AM, Randy S. wrote: > > Are you saying that beca... > > - To > unsubscribe, e-mail: users-... >
Wicket in JBoss cluster
Dear all, would you be so kind and share your experience about whether it is reasonable to use Wicket for app development in the following situation: We are planning to develop an application that will be deployed in our customer's portlet environment (JBoss Portal). There will be two clustered JBoss instances with JBoss's own session replication mechanism enabled. The main reason for the clustering is to have failover that should be transparent for logged in users, and this has to work really reliably. I don't know what the exact configuration of the load balancer and the JBoss servers will be, and how much influence we will have on it. Is it safe to use wicket in such a situation, or should we rather go for a more stateless framework? I did some tests to run a very simple Wicket app in two clustered JBoss instances, and after I shut down the instance with the active session, the session continues to be available on the other cluster node, and the links in the pages still work. So far, so good. But when I hit the browser's back button, I receive a Page Expired Error. This probably means that the content of the page store is not correctly replicated to the other cluster node? Is this a known limitation, or caused by some wrong configuration? Thanks for any feedback on these topics, please let me know what your experiences and opinions are. Kind regards, Jan
Re: ModalWindow - Address Is Not Valid
Hi Alexander, this one here looks like your problem: https://issues.apache.org/jira/browse/WICKET-2207 But the issue is marked as fixed in JIRA, since end of April. Do you use the latest Wicket version? 2009/9/27 Alexander Shindler > > Hi Jeremy, > > > > Bychance, I found out that it must be some sort of compatibility problem > with Internet Explorer 8. Even though strangely when I run it from the host > computer even with IE8 it runs fine, but for some reason other computers on > the network using IE8 cannot open the modal windows and get the error I > mentioned below. When I tried using IE7 from the computers on the network, > everything runs smoothly. > > > > I can't think of reason why - any suggestions? > > > > The strangest thing is that I have no problem using IE8 from the host > computer. I'm guessing it must be some new security feature on IE8...but > I've no idea what the workaround could be for this apart from using a > different browser/version... > > > > > > Date: Sat, 26 Sep 2009 18:34:44 -0500 > > Subject: Re: ModalWindow - Address Is Not Valid > > From: jer...@wickettraining.com > > To: users@wicket.apache.org > > > > Can you show some code? > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > > > > > > > On Thu, Sep 24, 2009 at 1:41 AM, Alexander Shindler < > > alexshind...@hotmail.com> wrote: > > > > > > > > Hi, > > > > > > > > > > > > I have been using wicket to develop an intranet web application. I have > > > tabbedpanels with AjaxLinks which when clicked open up ModalWindows. I > am > > > running tomcat on my computer and my application works fine. When I > access > > > my application from another networked computer, when I click the links, > the > > > modalwindows are not opened and all I get is a message saying that the > > > address is not valid (http:///) - can anyone exalin why this happens? > > > > > > > > > > > > Alex > > > > > > _ > > > Get the best of MSN on your mobile > > > http://clk.atdmt.com/UKM/go/147991039/direct/01/ > > > > > _ > Get the best of MSN on your mobile > http://clk.atdmt.com/UKM/go/147991039/direct/01/ >
Re: Datepicker popup when textfield is selected
Hi Cem, I don't know how this can be done with the wicket datepicker, but the JQuery datepicker has that already built in, without the need to write any additional JavaScript (only one line to init the datepicker and attach it to a text field). Maybe you could just add that one to a normal Wicket TextField, instead of using the wicket datepicker? See here: http://jqueryui.com/demos/datepicker/ Am 14.08.2009 um 12:20 schrieb copenhag copenhagen: Hi, Would it be possible to make the datepicker popup whenever a textfield is selected? Thereby the textfield will be no editable, but only the datepicker will modify the textfield value. Here is an example on the behaviour i am looking for with the wicket datepicker object: http://blog.davglass.com/files/yui/cal2/ Best Regards Cem... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AutoComplete results disappear when using scrollbar in IE
Hi Igor, my specific use case does not allow to limit the number of results, but I found another solution that seems to work so far. I modified the wicket-autocomplete.js to the following behaviour: If the browser is IE and not running in Quirks mode, an event handler function is added to the document that registers each click, and checks which html element was clicked. The onblur handler of the autocomplete field is modified in a way that the result list is not hidden immediately on blur, but with a short delay of 200 ms. If the click listener observes a click outside of the document body (i.e. tag name of the clicked element is "HTML") during that delay - which happens when the user clicks the scroll bar - the result list will not be hidden, but the input field be re-focused instead. This works for my case, but I don't know if it will be suitable as a general fix for others, and I have only tested it with IE 7 and Firefox. Should I still provide a patch or quickstart with the modification? Jan Am 20.05.2009 um 17:57 schrieb Igor Vaynberg: sounds like we either need to build paging into the list, or you need to limit the number of results you show. -igor On Tue, May 19, 2009 at 2:13 AM, Jan Grathwohl wrote: Hi list, I am using Wicket's AutoCompleteTextField in my application, and the result list that is shown to the user by the autocomplete can be quite long in some situations, so that it does not fit into the browser window anymore, and the complete result list is only visible by scrolling down in the browser window. The problem with IE is now, if users try to use the browser's scrollbar to get to the end of the result list, the list immediately disappears. It looks like the click on the scrollbar in IE fires an onblur event, which hides the autocomplete's result list. As a result of this, the autocomplete can only be used in IE by scrolling down the page with the mouse's scroll wheel, but IE users without a mouse are in trouble... Funny thing is that this only happens if I use a HTML doctype declaration in the HTML page. If I remove the declaration from the HTML, IE runs in Quirks mode and does not fire onblur any more when clicking the scroll bar, and everything works. But removing the doctype declaration from my HTML then again breaks all the existing CSS, so this is not really a solution. Is this a known issue (or an issue at all)? Did anyone on this list have the same problem, and found a way to fix it or work around it? I know I could make the result list itself scrollable, by setting a height for div.wicket-aa, so users would scroll the div instead of the whole browser window. But if there is a possibility to keep the current behaviour of the autocomplete, only fix the problem with the click on the scrollbar, I would prefer that. BTW, the objectautocomplete component from wicket-stuff shows the same problem. Just add http://www.w3.org/TR/html4/loose.dtd";> to the example HTML page, and the autocomplete's result list disappears when you click on the scrollbar. Regards, Jan - 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
AutoComplete results disappear when using scrollbar in IE
Hi list, I am using Wicket's AutoCompleteTextField in my application, and the result list that is shown to the user by the autocomplete can be quite long in some situations, so that it does not fit into the browser window anymore, and the complete result list is only visible by scrolling down in the browser window. The problem with IE is now, if users try to use the browser's scrollbar to get to the end of the result list, the list immediately disappears. It looks like the click on the scrollbar in IE fires an onblur event, which hides the autocomplete's result list. As a result of this, the autocomplete can only be used in IE by scrolling down the page with the mouse's scroll wheel, but IE users without a mouse are in trouble... Funny thing is that this only happens if I use a HTML doctype declaration in the HTML page. If I remove the declaration from the HTML, IE runs in Quirks mode and does not fire onblur any more when clicking the scroll bar, and everything works. But removing the doctype declaration from my HTML then again breaks all the existing CSS, so this is not really a solution. Is this a known issue (or an issue at all)? Did anyone on this list have the same problem, and found a way to fix it or work around it? I know I could make the result list itself scrollable, by setting a height for div.wicket-aa, so users would scroll the div instead of the whole browser window. But if there is a possibility to keep the current behaviour of the autocomplete, only fix the problem with the click on the scrollbar, I would prefer that. BTW, the objectautocomplete component from wicket-stuff shows the same problem. Just add http://www.w3.org/TR/html4/loose.dtd";> to the example HTML page, and the autocomplete's result list disappears when you click on the scrollbar. Regards, Jan
Sending HTML email from Wicket app
Hi, what is the preferred way to send HTML email messages from a Wicket application? I could not find anything related to sending email in the Javadocs, and no examples on the web. My idea was to create a Wicket page for the content of the email, render this page into a String, and then send the email with the Jakarta Commons mail client. But I could not figure out how to do that either. Is this possible, to instantiate a new WebPage object, set the necessary fields, and then render it into a String variable instead of writing it to the HTTP response? If yes, could somebody tell me what I have to do? BR and Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
