Re: UTF-8 not working
Please provide a small quickstart showcasing the problem to get more help because based on these information it should work. Attila 2011/10/15 Mathias Nilsson wicket.program...@gmail.com Oh, And I've also tried putting org.springframework.web.filter.CharacterEncodingFilter as the first filter -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/UTF-8-not-working-tp3906237p3907047.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
Strange issue in RequestCycle
Hi, In 1.5, the request cycle (indirectly) contains a stack of request handlers. According to the Java docs, it seems the purpose is to allow a request handler to execute another request handler in its respond() method by calling the execute() method in the request cycle. However: a) There seems to be no code in Wicket doing that and I don't see why one would want to do that. What's the use case? b) There is no execute() method in the RequestCycle class at all. So there is actually no way for a request handler to call execute() on invoke another. Does it mean that there is inconsistency here? c) Even if there were a way to execute another request handle inline, there is only one scheduledAfterCurrent in the request cycle. This would cause problems of the inlined request handle schedule another handler, right? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Efficiency of 1.5 MountMapper weighted/matching algorithm
I'll try to get some time to build a test to get some timings. -Original Message- From: Jeremy Thomerson [mailto:jer...@wickettraining.com] Sent: Sunday, 16 October 2011 11:55 AM To: users@wicket.apache.org Subject: Re: Efficiency of 1.5 MountMapper weighted/matching algorithm On Sat, Oct 15, 2011 at 8:28 PM, Chris Colman chr...@stepaheadsoftware.comwrote: Obviously this isn't a problem during debug with a single user but when 1000s of pages need to be rendered each minute the time spent performing the above operations may become significant. I haven't done any benchmark testing but from experience, the frequenct allocation and compiling of collections and sorting can get CPU expensive and switching to a caching alternative usually leads to significant performance improvements. It'd definitely be worth optimizing if we can prove it's a bottle-neck. But we try to avoid premature optimization. Can you put together some numbers to see what kind of processing load we're talking about? I'd be interested in seeing % of overall processing time under load. Something like with X clients browsing Y pages per minute, each page render took an average R milliseconds, and Z milliseconds of this was in creating link URLs. Or something like that. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to handle errors in RequestCycle.onEndRequest
Sorry, took a while until I got time to test the changes. WIth the current trunk revision I now can use restart exceptons within onRequestHandlerExecuted to force a redirect to an error page and even adding feedback messages seems to work properly. Thank you very much for this fix! :-) The Sanity Resort http://sanityresort.blogspot.com/ Am 12.10.2011 08:31, schrieb Igor Vaynberg: ive just checked in a couple of tweaks, give it a go... -igor On Sat, Oct 1, 2011 at 10:38 AM, Christian Huberhub...@butterbrot.org wrote: Hi Igor, I just saw you answered to my JIRA issue. I had tried your suggestion about throwing an exception before but to no avail (see also my comment on the issue): I had tried adding throw new RestartResponseException(ErrorPage.class); to the onrequesthandlerexecuted() callback while ErrorPage is just an empty page with empty markup and mounted at error (calling that page did work when the exception was not thrown) but that caused the following error: ERROR - DefaultExceptionMapper - Unexpected error occurred org.apache.wicket.RestartResponseException ERROR - DefaultExceptionMapper - Unexpected error occurred java.lang.IllegalStateException: Header was already written to response! throwing the exception directly in the homepage constuctor got me redirected to the error page as expected. would you need a new quickstart for this? The Sanity Resorthttp://sanityresort.blogspot.com/ Am 01.10.2011 17:54, schrieb Christian Huber: quickstart created and added to https://issues.apache.org/jira/browse/WICKET-4103 this quickstart does not behave exactly like my application but the primary problem about messages not being displayed is reproducable. please let me know if i can provide any further information and thank you for your assitance. The Sanity Resorthttp://sanityresort.blogspot.com/ Am 01.10.2011 16:47, schrieb Igor Vaynberg: that sounds like a bug, please create a quickstart and attach it to jira. -igor On Sat, Oct 1, 2011 at 7:29 AM, Christian Huberhub...@butterbrot.org wrote: Hi again, unfortunately my problem still persists. After migrating to 1.5.1 and putting my commit code into onRequestHandlerExecuted() the error messages generated there are still not propagated to the rendered response page. But instead I now get the following error message: ERROR - DefaultExceptionMapper - Unexpected error occurred java.lang.IllegalStateException: Header was already written to response! So it seems that at this it is still to late to anything to the current response. As before the error messages do get displayed after the following request. At the moment I am totally stumped. Does anyone have a clue what I am doing wrong here? Thanks, Chris The Sanity Resorthttp://sanityresort.blogspot.com/ Am 24.09.2011 17:18, schrieb Igor Vaynberg: use the onRequestHandlerExecuted() to commit the transaction and onException() to roll it back. these are both in IRequestCycleListener. -igor On Mon, Sep 19, 2011 at 10:50 AM, Christian Huberhub...@butterbrot.org wrote: Hi all, I just noticed that exceptions occuring in onEndRequest of a RequestCycle somehow do not reflect on the respone page. I am using an AjaxFallbackButton and the OSIV pattern and thus commit my database changes in onEndRequest, now if an exception occurs here I do get a log entry but I cannot get my application to display the corresponding error to the user. Adding a message to the feedback panel does not help as the message gets displayed on the following request but not the current one. I also tried using various AbortExceptions like RedirectToUrlException, RestartResponseException or AbortWithWebErrorCodeException. This did improve the situation as far as the request did get aborted but there is still no visual display of the error. Setting the ResponsePage directly and/or setting redirect to true did not change anything. This sounds like a common problem and so I guess there is an easy solution to it, but I just don't get it right now, so any pointers are welcome. Thanks, Chris -- The Sanity Resorthttp://sanityresort.blogspot.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange issue in RequestCycle
On Sun, Oct 16, 2011 at 1:51 AM, Kent Tong k...@cpttm.org.mo wrote: Hi, In 1.5, the request cycle (indirectly) contains a stack of request handlers. According to the Java docs, it seems the purpose is to allow a request handler to execute another request handler in its respond() method by calling the execute() method in the request cycle. However: a) There seems to be no code in Wicket doing that and I don't see why one would want to do that. What's the use case? the usecase is simple, one requesthandler handing work off to another one. an easy example is a request handler that handles a callback (such as a link being clicked) scheduling the handler that renders the page after it handled the click. b) There is no execute() method in the RequestCycle class at all. So there is actually no way for a request handler to call execute() on invoke another. Does it mean that there is inconsistency here? yep, just fixed the javadoc. there is no execute(), only scheduleafter() and replaceall() c) Even if there were a way to execute another request handle inline, there is only one scheduledAfterCurrent in the request cycle. This would cause problems of the inlined request handle schedule another handler, right? all scheduled handlers go into a queue and are executed in order. usually there are only two handlers scheduled - event handler and page renderer. -igor - 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: Strange issue in RequestCycle
Hi Igor, Thanks for the reply! the usecase is simple, one requesthandler handing work off to another one. an easy example is a request handler that handles a callback (such as a link being clicked) scheduling the handler that renders the page after it handled the click. Yes, it is very common for one request handler *scheduling* another to be executed after its own execution. However, I am referring to one request handling *executing* another during its own execution. all scheduled handlers go into a queue and are executed in order. usually there are only two handlers scheduled - event handler and page renderer. The code shows that the scheduled handler is stored into the single scheduledAfterCurrent field in RequestHandlerStack, while the requestHandlers linked-list is not really used. The only location a request handler is added to the linked-list is in the execute() method, but it is immediately removed after its execution. -- Kent Tong Useful news for CIO's at http://www2.cpttm.org.mo/cyberlab/cio-news - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
