[jira] Created: (WICKET-1758) Make DiskPageStore#getSessionFolder protected (rather than private)
Make DiskPageStore#getSessionFolder protected (rather than private) --- Key: WICKET-1758 URL: https://issues.apache.org/jira/browse/WICKET-1758 Project: Wicket Issue Type: Wish Components: wicket Affects Versions: 1.3.4 Reporter: Nick Johnson Priority: Minor Fix For: 1.3.5 So that people (like me!) can extend DiskPageStore and implement our directory / file hierarchy of choice, it would be nice if getSessionFolder were protected rather than private. To make sure people don't make silly mistakes it might be necessary to break this up into two methods (since this method determines the pathname AND creates it if it doesn't exist) and make the filename determination part the protected one. My use case is that I'd like to be able to introduce a directory hierarchy for reasons of performance and filesystem limitations so every pagestore directory isn't rooted off the same single directory. I'd probably add some code like this: long hashCode = sessionId.hashCode() 0xff00; String hexHashCode = String.format(%08x, hashCode); String path = hexHashCode.substring(0, 3) + File.pathSeparator + hexHashCode.substring(3, 6) + File.pathSeparator + sessionId.replaceAll(\\W, _); File sessionFolder = new File(storeFolder, path); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1657) AjaxFallbackDefaultDataTable gives misleading error when fragment markup cannot be found
AjaxFallbackDefaultDataTable gives misleading error when fragment markup cannot be found Key: WICKET-1657 URL: https://issues.apache.org/jira/browse/WICKET-1657 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 1.3.0-final Reporter: Nick Johnson Priority: Minor If you call cellItem.add(new Fragment(foo,bar, myPage, model), but the fragment markup for bar isn't found in the markup for myPage, AjaxFallbackDefaultDataTable complains, failed to add a component with id [cell] to the provided [cellItem] object. The error suggests making sure that cellItem.add was called. This error can be misleading, especially since cellItem.add was called. What really happened was the fragment with a given ID wasn't found, which should really have been an error in its own right. It would be nice if the error message gave a better description indicating the reason why the component failed to add (e.g., an error in handling the Fragment). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1628) WicketTester processRequestCycle fails to redirect from a mounted bookmarkable page if response is restarted at intercept page
WicketTester processRequestCycle fails to redirect from a mounted bookmarkable page if response is restarted at intercept page -- Key: WICKET-1628 URL: https://issues.apache.org/jira/browse/WICKET-1628 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-final Reporter: Nick Johnson If in the WebApplication's init method, you call mountBookmarkablePage(/foo, Foo.class), and in a unit test do something like this: tester.setupRequestAndResponse(); final WebRequestCycle cycle = tester.createRequestCycle(); final String url = cycle.urlFor(Foo.class, pageParameters).toString(); // set up and normalize a complete URL final URL oldUrl = new URL(tester.getServletRequest().getRequestURL().toString()); final URI newUrl = new URL(oldUrl.getProtocol(), oldUrl.getHost(), oldUrl.getPort(), oldUrl.getPath() + / + url).toURI().normalize(); tester.getServletRequest().setURL(newUrl.toASCIIString()); tester.processRequestCycle(); If Foo.class will throw a RestartResponseAtInterceptPageException (e.g., to force a login), then the following assertion will fail with page was null: tester.assertRenderedPage(Login.class); If the page isn't mounted in the WebApplication, it works as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1582) WicketTester executeAjaxEvent onclick generating non-AJAX response
WicketTester executeAjaxEvent onclick generating non-AJAX response -- Key: WICKET-1582 URL: https://issues.apache.org/jira/browse/WICKET-1582 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.4 Environment: Wicket 1.3-SNAPSHOT as of today Reporter: Nick Johnson Executing: tester.executeAjaxEvent(linky, onclick); tester.assertComponentOnAjaxResponse(component); throws an exception saying The Previous response was not an AJAX response. You need to execute an AJAX event, using clickLink, before using this assert although executeAjaxEvent should be resulting in an AJAX response (and prior to 1.3.3 it did). Executing tester.clickLink(linky), which probably should be equivalent to the above executeAjaxEvent, does work. I'll attach a simple testcase demonstrating this behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1582) WicketTester executeAjaxEvent onclick generating non-AJAX response
[ https://issues.apache.org/jira/browse/WICKET-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Johnson updated WICKET-1582: - Attachment: wicket1582.jar Simple test case showing nonequivalent behaviour between executeAjaxEvent(foo, onclick) and clickLink(foo). WicketTester executeAjaxEvent onclick generating non-AJAX response -- Key: WICKET-1582 URL: https://issues.apache.org/jira/browse/WICKET-1582 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.4 Environment: Wicket 1.3-SNAPSHOT as of today Reporter: Nick Johnson Attachments: wicket1582.jar Executing: tester.executeAjaxEvent(linky, onclick); tester.assertComponentOnAjaxResponse(component); throws an exception saying The Previous response was not an AJAX response. You need to execute an AJAX event, using clickLink, before using this assert although executeAjaxEvent should be resulting in an AJAX response (and prior to 1.3.3 it did). Executing tester.clickLink(linky), which probably should be equivalent to the above executeAjaxEvent, does work. I'll attach a simple testcase demonstrating this behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-876) Assigning Label to anchor tag in recursive ListView causes exponential performance decay
[ https://issues.apache.org/jira/browse/WICKET-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522294 ] Nick Johnson commented on WICKET-876: - As an aside, I was incorrect in identifying the rate of decay as exponential; it's actually polynomial, following the formula (n + n^2) / 2. (O(n^2)) Bad enough to be very noticeable, but very easy to correct. Thanks for the explanation! Assigning Label to anchor tag in recursive ListView causes exponential performance decay Key: WICKET-876 URL: https://issues.apache.org/jira/browse/WICKET-876 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.2.6 Reporter: Nick Johnson Assignee: Igor Vaynberg Priority: Trivial This isn't so much a bug as a curiosity, and I'm partially just documenting this in case someone else runs across the same problem later and searches the bug database for clues. It -would- be interesting to figure out why it happens. The workaround is trivial. If the markup for a recursive list view (like the recursive panel in the examples) contains a named anchor like this: a name=x wicket:id=anchor /a And the anchor is (inappropriately) associated with a Label like this: add(new Label(anchor).add(new SimpleAttributeModifier(name,foo))); Then as the levels of recursion deepen, performance during rendering decays exponentially. During this time, the Java process will also start consuming a tremendous amount of CPU. The solution is fairly simple: don't use a Label for situations like this; instead, use a WebMarkupContainer: add(new WebMarkupContainer(anchor).add(new SimpleAttributeModifier(name,foo))); With the component being WebMarkupContainer, performance does not degrade exponentially. With Label, it does. I'm afraid I don't know enough of the internal workings of Wicket to speculate as to why. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-876) Assigning Label to anchor tag in recursive ListView causes exponential performance decay
Assigning Label to anchor tag in recursive ListView causes exponential performance decay Key: WICKET-876 URL: https://issues.apache.org/jira/browse/WICKET-876 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.2.6 Reporter: Nick Johnson Priority: Trivial This isn't so much a bug as a curiosity, and I'm partially just documenting this in case someone else runs across the same problem later and searches the bug database for clues. It -would- be interesting to figure out why it happens. The workaround is trivial. If the markup for a recursive list view (like the recursive panel in the examples) contains a named anchor like this: a name=x wicket:id=anchor /a And the anchor is (inappropriately) associated with a Label like this: add(new Label(anchor).add(new SimpleAttributeModifier(name,foo))); Then as the levels of recursion deepen, performance during rendering decays exponentially. During this time, the Java process will also start consuming a tremendous amount of CPU. The solution is fairly simple: don't use a Label for situations like this; instead, use a WebMarkupContainer: add(new WebMarkupContainer(anchor).add(new SimpleAttributeModifier(name,foo))); With the component being WebMarkupContainer, performance does not degrade exponentially. With Label, it does. I'm afraid I don't know enough of the internal workings of Wicket to speculate as to why. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
