[jira] [Commented] (WICKET-5071) 404 Error on Nested ModalWindows in IE7 and IE8
[ https://issues.apache.org/jira/browse/WICKET-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697634#comment-13697634 ] Hudson commented on WICKET-5071: Integrated in Syncope-1_1_X #74 (See [https://builds.apache.org/job/Syncope-1_1_X/74/]) [SYNCOPE-370] Upgrade to Wicket 6.9.0 (that contains WICKET-5071) (Revision 1498805) Result = SUCCESS ilgrosso : Files : * /syncope/branches/1_1_X/pom.xml > 404 Error on Nested ModalWindows in IE7 and IE8 > --- > > Key: WICKET-5071 > URL: https://issues.apache.org/jira/browse/WICKET-5071 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.5.8, 6.6.0 > Environment: Internet Explorer 8.0.7601.17514 > Internet Explorer 7.0.5730.13 > Jetty 7 (multiple versions replicate the problem) > Tomcat 6 >Reporter: Jered Myers >Assignee: Martin Grigorov > Fix For: 6.9.0, 7.0.0 > > Attachments: fix-WICKET-5071.patch, NestedModals.zip > > > When opening a ModalWindow inside a ModalWindow, the inner ModalWindow > generates a 404 error. Both windows use a PageCreator for content. > To replicate, you must use an actual IE 7 or IE 8 browser, as this does not > replicate using developer tools and setting the document and brower to IE 7. > The problem can be seen at > http://www.wicket-library.com/wicket-examples/ajax/modal-window. I will > attach a Quickstart as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-5029) Palette does not allow to turn off localization
[ https://issues.apache.org/jira/browse/WICKET-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13574471#comment-13574471 ] Hudson commented on WICKET-5029: Integrated in Syncope-1_0_X #133 (See [https://builds.apache.org/job/Syncope-1_0_X/133/]) [SYNCOPE-310] Workaround waiting for WICKET-5029 availability (Revision 1443945) Result = SUCCESS ilgrosso : Files : * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/panels/PolicyBeanPanel.java * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/wicket/markup/html/form/AjaxPalettePanel.java * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/wicket/markup/html/form/NonI18nPalette.java * /syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/wicket/markup/html/form/SingleColumnPalette.java * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/SyncopeApplication.properties * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/SyncopeApplication_it.properties * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/pages/PolicyModalPage.html * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/pages/panels/PolicyBeanPanel.html * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/wicket/markup/html/form/AjaxPalettePanel.html * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/wicket/markup/html/form/NonI18nPalette.html * /syncope/branches/1_0_X/console/src/main/resources/org/apache/syncope/console/wicket/markup/html/form/SingleColumnPalette.html * /syncope/branches/1_0_X/console/src/main/webapp/img/left-icon.png * /syncope/branches/1_0_X/console/src/main/webapp/img/right-icon.png * /syncope/branches/1_0_X/console/src/test/java/org/apache/syncope/console/ConfigurationTestITCase.java * /syncope/branches/1_0_X/console/src/test/java/org/apache/syncope/console/EditProfileTestITCase.java > Palette does not allow to turn off localization > --- > > Key: WICKET-5029 > URL: https://issues.apache.org/jira/browse/WICKET-5029 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.5.9, 6.5.0 >Reporter: Francesco Chicchiriccò >Assignee: Sven Meier >Priority: Minor > Fix For: 1.5.10, 6.6.0 > > Attachments: WICKET-5029.patch > > > WICKET-1982 introduced value localization in the Palette. > However, localization cannot be disabled; this was also reported in user ML > [1]. > [1] > http://apache-wicket.1842946.n4.nabble.com/Palette-and-localization-td4495234.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3457) Add methods to IBehavior to listen for configuration events
[ https://issues.apache.org/jira/browse/WICKET-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997246#comment-12997246 ] Hudson commented on WICKET-3457: Integrated in Apache Wicket 1.4.x #454 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/454/]) > Add methods to IBehavior to listen for configuration events > --- > > Key: WICKET-3457 > URL: https://issues.apache.org/jira/browse/WICKET-3457 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.15 >Reporter: Jeremy Thomerson >Assignee: Jeremy Thomerson >Priority: Minor > Fix For: 1.4.16, 1.5-RC2 > > > I would like for behaviors to be able to contribute to the configuration of a > component (i.e. calling setVisible / setEnabled). Now that we have > onConfigure, it would be nice to have components notify their behaviors > during the configuration process. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3418) Incorrect setting of AjaxSubmitLink's request parameter in BaseWicketTester.submitAjaxFormSubmitBehavior
[
https://issues.apache.org/jira/browse/WICKET-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997247#comment-12997247
]
Hudson commented on WICKET-3418:
Integrated in Apache Wicket 1.4.x #454 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/454/])
> Incorrect setting of AjaxSubmitLink's request parameter in
> BaseWicketTester.submitAjaxFormSubmitBehavior
>
>
> Key: WICKET-3418
> URL: https://issues.apache.org/jira/browse/WICKET-3418
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
>Reporter: Szádeczky-Kardoss Szabolcs
>Assignee: Pedro Santos
>Priority: Minor
> Fix For: 1.4.16
>
> Attachments: WICKET-3418.patch
>
>
> In BaseWicketTester.submitAjaxFormSubmitBehavior() the AjaxSubmitLink's name
> is set in the request parameters as follows:
> (1) Map requestParams = getParametersForNextRequest();
> requestParams.put(inputName, new String[] { "x" });
> However, as far as I could check
> MockWebApplication's.parametersForNextRequest is only put into the actual
> request when setupRequestAndResponse() is called. Since in clickLink()
> (2) WebRequestCycle requestCycle = setupRequestAndResponse(true);
> submitAjaxFormSubmitBehavior(linkComponent, ajaxFormSubmitBehavior);
> setupRequestAndResponse() precedes the submitAjaxFormSubmitBehavior() this
> won't happen in the current request any more and the Ajax submit is not
> processed correctly in the current request and also causes side effects for
> the next form submit (ajax or normal).
> To solve it either replace (1) with:
> getServletRequest().setParameter(inputName, new String[] { "x" });
> or change the order of the two lines in (2).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3455) onremove() in RefreshingView.onPopulate
[ https://issues.apache.org/jira/browse/WICKET-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996850#comment-12996850 ] Hudson commented on WICKET-3455: Integrated in Apache Wicket 1.4.x #450 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/450/]) Issue: WICKET-3455 > onremove() in RefreshingView.onPopulate > --- > > Key: WICKET-3455 > URL: https://issues.apache.org/jira/browse/WICKET-3455 > Project: Wicket > Issue Type: Bug > Components: wicket >Reporter: Benedikt Rothe >Assignee: Igor Vaynberg > Fix For: 1.4.16, 1.5-RC2 > > > file a bug with a quickstart. onremove() should be called on all > removed components. > -igor > On Fri, Feb 18, 2011 at 5:38 AM, Benedikt Rothe > wrote: > > > Hi > > > > > > Are the existing children of a RepeatingView/RefreshingView being > > > informed, > > > when > > > the View is newly populated (RefreshingView.onPopulate). > > > > > > I'd like to clean some internal references in this case. > > > I tried: > > > - aChild.onRemove is not called in this situation > > > - aChild.setParent(null) is called. I treid to override setParent it. But > > > setParent is private. > > > > > > Any suggestions? > > > Benedikt -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3420) javascript with a less than character ("<") fails to execute when added through a header contribution in ajax response
[
https://issues.apache.org/jira/browse/WICKET-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996322#comment-12996322
]
Hudson commented on WICKET-3420:
Integrated in Apache Wicket 1.4.x #448 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/448/])
WICKET-3420 javascript with a less than character ("<") fails to execute
when added through a header contribution in ajax response
Add logging for the cases when there is an error in the parsing of XML with
DOMParser
> javascript with a less than character ("<") fails to execute when added
> through a header contribution in ajax response
> --
>
> Key: WICKET-3420
> URL: https://issues.apache.org/jira/browse/WICKET-3420
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
> Environment: Validated this bug on my dev environment: Windows 7 64
> bit using Firefox 4.0beta10 and Chrome 8.
>Reporter: Randy Schnedler
>Assignee: Martin Grigorov
>Priority: Minor
> Labels: ajax, header-contribution, javascript, wicket-ajax.js
>
> This is adapted from a wicket users post I made (links are to the same thread
> in two archive systems):
> http://markmail.org/search/?q=wicket%20users%20wicket-ajax.js#query:wicket%20users%20wicket-ajax.js+page:1+mid:rfts3ar3upffhbbt+state:results
> http://mail-archives.apache.org/mod_mbox/wicket-users/201102.mbox/%3CAANLkTi=ekmta0rna+gyje-cqwmkcxrlsjp+z8jwv-...@mail.gmail.com%3E
> The problem: I have a panel with this:
>
>
> if (someVariable < 0) {
> someVariable = 0;
> }
>
>
> This script fails to execute when the panel is loaded by ajax. If I replace
> the less than character "<" with equals "==", then it executes (but of
> course, this is not what I need).
> I tested this in Firefox 4.0b10 and Chrome 8.
> After some debugging, it seems to me that this needs to be corrected in
> wicket-ajax.js. The header contribution is sent to the browser inside of a
> CDATA section so the "<" character arrives to javascript intact. However, in
> parsing the script tag, the "<" seems to signal the beginning of an HTML tag
> that then is considered malformed.
> Possible workarounds for apps:
> - Invert the logic so a greater-than is used. In my example, this would be:
> "if (0 > someVariable) {"
> - Put the code into a separate JS file (the downside is it requires another
> network hop from the browser)
> - Embed the script in rather than (the
> disadvantage is the script will be re-sent with the panel content when the
> panel is re-used on the same page)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3438) 2xStatelessForm growing url when there is error validation
[
https://issues.apache.org/jira/browse/WICKET-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996230#comment-12996230
]
Hudson commented on WICKET-3438:
Integrated in Apache Wicket 1.4.x #447 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/447/])
- preventing the submit link input name from being encoded in form action
- removing duplicated code in AbstractSubmitLink
- hidden input name changed to be root form relative
Issue: WICKET-3438
> 2xStatelessForm growing url when there is error validation
> ---
>
> Key: WICKET-3438
> URL: https://issues.apache.org/jira/browse/WICKET-3438
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
>Reporter: Olivier Dutrieux
>Assignee: Igor Vaynberg
> Fix For: 1.4.16
>
> Attachments: WICKET-3438-nested-forms.patch, WICKET-3438.patch,
> WICKET-3438.zip, Wicket-test.rar
>
>
> Hello,
> I have a strange problem with 2xStatelessForm :
> I would like a stateless application with 2 StatelessForm and with somes
> required validators on form :
> public class HomePage extends WebPage {
> private static final long serialVersionUID = 1L;
> public HomePage(final PageParameters parameters) {
> super(parameters);
> setVersioned(false);
> Form form1 = new StatelessForm("form1") {
> @Override
> protected void onSubmit() {
> setResponsePage(ResultPage.class);
> }
> };
> form1.add(new TextField("input1").setRequired(true));
> add(form1);
> Form form2 = new StatelessForm("form2") {
> @Override
> protected void onSubmit() {
> setResponsePage(ResultPage.class);
> }
> };
> form2.add(new TextField("input1").setRequired(true));
> add(form2);
> }
> }
> The problem is when I submit alternatively each form (I don't fill the
> Textfield required intentionally), the url growing like this :
> 1st submit :
> http://localhost:8080/Wicket-Test/HomePage.html?wicket:interface=:0:form2::IFormSubmitListener::
> 2nd submit :
> http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=&wicket:interface=:0:form1::IFormSubmitListener::
> 3th submit :
> http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=&form12_hf_0=&wicket:interface=:0:form2::IFormSubmitListener::
> 4th submit :
> http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=&form22_hf_0=&form12_hf_0=&wicket:interface=:0:form1::IFormSubmitListener::
> ...
> Is there a solution to solve this problem ?
> Best regards
> Duto
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-2056) Modal CSS Overflow Auto Bug
[ https://issues.apache.org/jira/browse/WICKET-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996161#comment-12996161 ] Hudson commented on WICKET-2056: Integrated in Apache Wicket 1.4.x #446 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/446/]) > Modal CSS Overflow Auto Bug > --- > > Key: WICKET-2056 > URL: https://issues.apache.org/jira/browse/WICKET-2056 > Project: Wicket > Issue Type: Bug > Components: wicket > Environment: Internet Explorer 6 and 7 >Reporter: Zach Leatherman >Assignee: Igor Vaynberg >Priority: Trivial > Fix For: 1.4.16, 1.5-RC2 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > To duplicate the issue, create a panel wicket modal with the following > content that has enough content to trigger an overflow: > (etc.) > Relative > Then try scrolling in IE6 or IE7. The relative div will remain in a fixed > position. > See the following for a description of the bug. > http://rowanw.com/bugs/overflow_relative.htm > On the first child div below div.w_content, there should be a style > declaration assigned to the child div that contains "position: relative;" > For example, > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3416) CheckGroupSelector does not inherit "disabled" property from parent form
[ https://issues.apache.org/jira/browse/WICKET-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996160#comment-12996160 ] Hudson commented on WICKET-3416: Integrated in Apache Wicket 1.4.x #446 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/446/]) > CheckGroupSelector does not inherit "disabled" property from parent form > > > Key: WICKET-3416 > URL: https://issues.apache.org/jira/browse/WICKET-3416 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15 > Environment: not relevant >Reporter: Roman Gubarev >Assignee: Igor Vaynberg >Priority: Minor > Labels: checkgroup, form, > Fix For: 1.4.16, 1.5-RC2 > > Original Estimate: 1h > Remaining Estimate: 1h > > component CheckGroupSelector does not inherit "disabled" property from parent > component (form or CheckGroup) as it inherits from > LabeledWebMarkupContainer. To resolve this issue CheckGroupSelector should > inherit from FormComponent -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-1886) WicketTester Cookie handling
[ https://issues.apache.org/jira/browse/WICKET-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996162#comment-12996162 ] Hudson commented on WICKET-1886: Integrated in Apache Wicket 1.4.x #446 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/446/]) > WicketTester Cookie handling > > > Key: WICKET-1886 > URL: https://issues.apache.org/jira/browse/WICKET-1886 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.5, 1.4-RC1 >Reporter: Jörn Zaefferer >Assignee: Pedro Santos > Fix For: 1.3.6, 1.4-RC2, 1.4.16 > > Attachments: CookieTest.java, WICKET-1886-test-fix.patch, > WICKET-1886.patch, WICKET-1886__SecureForm_and_failing_test.patch, > patch-WICKET-1886.diff > > > While trying to test my SecureForm implementation > (https://issues.apache.org/jira/browse/WICKET-1885) with WicketTester I ran > into this issue: A cookie set in the response never shows up in the "next" > request, because both have their own lists of cookies that aren't shared. > Afaik both should share the same List instance to handle cookies. That way > its possible to set a cookie in the response and read it from the request. > A simple testcase is attached. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3318) AjaxLazyLoadPanel doesn't render correctly after form submit
[ https://issues.apache.org/jira/browse/WICKET-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995430#comment-12995430 ] Hudson commented on WICKET-3318: Integrated in Apache Wicket 1.4.x #443 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/443/]) > AjaxLazyLoadPanel doesn't render correctly after form submit > > > Key: WICKET-3318 > URL: https://issues.apache.org/jira/browse/WICKET-3318 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.4.15 > Environment: Windows >Reporter: Flavius >Assignee: Igor Vaynberg > Fix For: 1.4.16, 1.5-RC2 > > Attachments: AjaxLazyLoadPanel.zip, WICKET-3318.patch > > > This occurs on a page with an AjaxLazyLoadPanel and a form. > If the form is submitted and the back button is used, the initial > page will not load the results of the AjaxLazyLoadPanel, but rather > display the busy indicator indefinitely. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3448) MarkupException: close tag not found - after ajax update
[ https://issues.apache.org/jira/browse/WICKET-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995429#comment-12995429 ] Hudson commented on WICKET-3448: Integrated in Apache Wicket 1.4.x #443 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/443/]) Issue: WICKET-3448 > MarkupException: close tag not found - after ajax update > > > Key: WICKET-3448 > URL: https://issues.apache.org/jira/browse/WICKET-3448 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15 > Environment: Win7_x64, JDK 1.6u23_x64 >Reporter: Alexander Morozov >Assignee: Igor Vaynberg > Attachments: wicket-1.4.15-quickstart.7z > > > I found very odd Wicket behavior in case then user tries to update by Ajax a > panel "wrapped" by not trivial border component (see quickstart - > HomePage.html). > There are no troubles with Ajax update with no border and with BoxBorder > (check HomePageTest#testAjaxPanelRefresh_NoBorder, > HomePageTest#testAjaxPanelRefresh_BoxBorder). > But if I create more complex border component like this: > > > > > > > > > > > > , I got the exception "MarkupException: close tag not found" (see > HomePageTest#testAjaxPanelRefresh_MyBorder1). > If I remove one nested block "" from the > markup and Java - test passed (see > HomePageTest#testAjaxPanelRefresh_MyBorder2). > For now, I haven't found the cause of the issue, hence I can't provider a > patch. > Thank you -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3444) ChangeHandler fires in IE on POS1 and END
[
https://issues.apache.org/jira/browse/WICKET-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994468#comment-12994468
]
Hudson commented on WICKET-3444:
Integrated in Apache Wicket 1.4.x #439 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/439/])
WICKET-3444 ChangeHandler fires in IE on POS1 and END
Do not fire event when HOME/END keys are pressed.
> ChangeHandler fires in IE on POS1 and END
> -
>
> Key: WICKET-3444
> URL: https://issues.apache.org/jira/browse/WICKET-3444
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
> Environment: IE 8
>Reporter: count negative
>Assignee: Martin Grigorov
>Priority: Minor
> Labels: ajax
> Fix For: 1.4.16, 1.5-RC2
>
>
> In wicket-ajax.js the Wicket.ChangeHandler fires in IE an event on Textfields
> even if the KEY_POS1 and the KEY_END is pressed.
> Please add
> obj.onkeyup = function(event) {
> switch (wicketKeyCode(Wicket.fixEvent(event))) {
> case KEY_ENTER:
> case KEY_UP:
> case KEY_DOWN:
> case KEY_ESC:
> case KEY_TAB:
> case KEY_RIGHT:
> case KEY_LEFT:
> case KEY_SHIFT:
> case KEY_ALT:
> case KEY_CTRL:
> return Wicket.stopEvent(event);
> break;
> default:
> if (typeof objonchange ==
> "function")objonchange();
> }
> return null;
> }
> case KEY_POS1 and KEY_END to the first case so that these two keys don't fall
> in the default case.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3403) Cannot convert 'this.content' to object in Opera
[
https://issues.apache.org/jira/browse/WICKET-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994452#comment-12994452
]
Hudson commented on WICKET-3403:
Integrated in Apache Wicket 1.4.x #438 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/438/])
WICKET-3403 Cannot convert 'this.content' to object in Opera
First set the onload handler and then update the iframe's location.
Additionally bind onload to this so it is possible to get a reference to
this.content (the iframe).
> Cannot convert 'this.content' to object in Opera
>
>
> Key: WICKET-3403
> URL: https://issues.apache.org/jira/browse/WICKET-3403
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.13
> Environment: Opera 11.01, Windows XP SP3 (client side)
>Reporter: Karel Behounek
>Assignee: Martin Grigorov
>Priority: Minor
> Fix For: 1.4.16, 1.5-RC2
>
>
> I get the error "Uncaught exception: TypeError: Cannot convert 'this.content'
> to object" in Opera every time I try to open some modal window, the
> problematic code seems to be the following part of modal.js script:
> if (Wicket.Browser.isOpera()) {
> this.content.onload = function() {
> this.content.contentWindow.name = this.settings.iframeName;
> }
> } else {
> this.content.contentWindow.name = this.settings.iframeName;
> }
> I am just an end-user, the above information was reported by Opera Dragonfly
> (error found on line 422 of modal.js). Priority is minor - I cannot use Opera
> with our in-house wicked-based IS (it heavily depends on modal windows), but
> I can use alternate browsers like Firefox or Chrome which are not affected.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3383) Strange writeObjectMethodCache in SerializableChecker
[
https://issues.apache.org/jira/browse/WICKET-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994078#comment-12994078
]
Hudson commented on WICKET-3383:
Integrated in Apache Wicket 1.4.x #436 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/436/])
WICKET-3383 Strange writeObjectMethodCache in SerializableChecker
Add the found writeObject() method in the cache.
> Strange writeObjectMethodCache in SerializableChecker
> -
>
> Key: WICKET-3383
> URL: https://issues.apache.org/jira/browse/WICKET-3383
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
>Reporter: Emond Papegaaij
>Assignee: Martin Grigorov
>Priority: Minor
> Fix For: 1.4.16
>
> Attachments: wicket-3383.diff
>
>
> At Topicus, we maintain a customized SerializableChecker with some additional
> checks. I was trying to fix some generics-warnings and noticed a strange
> thing
> about the writeObjectMethodCache. This variable is used in only 4 places, one
> is a clear, one a get and 2 are puts. Both puts take a Boolean as value, but
> the get checks if the value returned is a Method, which obviously can never
> happen. I think the 'writeObjectMethod' should be put into the map after line
> 473:
> writeObjectMethod = cls.getDeclaredMethod("writeObject",
> new Class[] { java.io.ObjectOutputStream.class });
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3391) Extensibility of the Wizard component
[ https://issues.apache.org/jira/browse/WICKET-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994077#comment-12994077 ] Hudson commented on WICKET-3391: Integrated in Apache Wicket 1.4.x #436 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/436/]) WICKET-3391 Extensibility of the Wizard component Make Wizard components more extensible > Extensibility of the Wizard component > - > > Key: WICKET-3391 > URL: https://issues.apache.org/jira/browse/WICKET-3391 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.4.15 > Environment: All >Reporter: Victor Ionescu >Assignee: Martin Grigorov > Fix For: 1.4.16, 1.5-RC2 > > Original Estimate: 2h > Remaining Estimate: 2h > > The Wizard component org.apache.wicket.extensions.wizard is hard to utilize > due to the following issues: > - the signature of the method > protected FeedbackPanel newFeedbackPanel(String id) > is too restricive. It could be modified into > protected Component newFeedbackPanel(String id) > This way programmers could plug in their own custom feedback panels (as in my > case). > - the constructor of the class > org.apache.wicket.extensions.wizard.WizardButtonBar: > public WizardButtonBar(String id, Wizard wizard) > should be refactored into > public WizardButtonBar(String id, IWizard wizard) > for obvious design reasons. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3413) FLAG_INHERITABLE_MODEL and default model change
[
https://issues.apache.org/jira/browse/WICKET-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994079#comment-12994079
]
Hudson commented on WICKET-3413:
Integrated in Apache Wicket 1.4.x #436 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/436/])
WICKET-3413 FLAG_INHERITABLE_MODEL and default model change
reset 'inherited model' flag if model changed and a new one is not
IComponentInheritedModel
> FLAG_INHERITABLE_MODEL and default model change
> ---
>
> Key: WICKET-3413
> URL: https://issues.apache.org/jira/browse/WICKET-3413
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
> Environment: Ubuntu 10.10/md64 JDK 1.6u23 x64
>Reporter: Alexander Morozov
>Assignee: Martin Grigorov
> Fix For: 1.4.16, 1.5-RC2
>
> Attachments: fix-WICKET-3413.patch, test-WICKET-3413.patch
>
>
> The issue is about correctness of Component#setDefaultModel
> (Component#setModelImpl) method behavior. I expect that the flag
> FLAG_INHERITABLE_MODEL should be checked there and turned off in case if new
> model is not a IComponentInheritedModel.
> Let check the next code:
> public MyPanel(String id) {
> super(id);
> ...
> form.setModel(new CompoundPropertyModel(this));
> DropDownChoice ddc = new DropDownChoice("variant", Arrays.ofList(...)) {
> // p1
> @Override
> protected void onInitialize() {
>super.onInitialize();
>setModel(new DefaultingWrapModel(getModel(), Model.of("default
> value"));// p2
> }
> };
> ddc.setNullValid(false);
> ddc.setRequired(true);
> form.add(ddc);
> ...
> }
> In the (p1) the DDC will initialize with CompoundPropertyModel and the
> FLAG_INHERITABLE_MODEL will be turned on soon by the first invocation of
> FormComponent#getModel().
> In the (p2) we wrap the DDC model with the model which provide the default
> value (DefaultingWrapModel implements IWrapModel). So we change the model,
> but the FLAG_INHERITABLE_MODEL is still turned on. On the Component#detach()
> event, the method Component#setModelImpl(null) will be invoked for the ddc
> and the DefaultingWrapModel instance will be lost:
> // reset the model to null when the current model is a
> IWrapModel and
> // the model that created it/wrapped in it is a
> IComponentInheritedModel
> // The model will be created next time.
> if (getFlag(FLAG_INHERITABLE_MODEL))
> {
> setModelImpl(null);
> setFlag(FLAG_INHERITABLE_MODEL, false);
> }
> I think that such behavior is unexpected.
> http://apache-wicket.1842946.n4.nabble.com/1-4-15-FLAG-INHERITABLE-MODEL-and-default-model-change-td3252093.html
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3361) Validation Error on AjaxEditableLabel causes ajax calls in loop on Chrome Browser
[ https://issues.apache.org/jira/browse/WICKET-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994073#comment-12994073 ] Hudson commented on WICKET-3361: Integrated in Apache Wicket 1.4.x #435 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/435/]) WICKET-3361 Validation Error on AjaxEditableLabel causes ajax calls in loop on Chrome Browser Do not re-render the AjaxEditableLabel's editor upon error. Just select and focus on it. > Validation Error on AjaxEditableLabel causes ajax calls in loop on Chrome > Browser > - > > Key: WICKET-3361 > URL: https://issues.apache.org/jira/browse/WICKET-3361 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.15, 1.5-M3 > Environment: Windows 7 - Chrome 8 >Reporter: Manuel Boillod >Assignee: Martin Grigorov > Fix For: 1.4.16, 1.5-RC2 > > Attachments: test-ajax.zip > > > On Chrome, the component AjaxEditableLabel causes an infinite ajax call's > loop if there is an validation error on the input. > The attached project shows this bug (Enter "false" to reproduce the bug, and > tape any key to stop it). > On Firefox, everithing is OK. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3351) Add class for span with text in wicket-extensions\treetable
[ https://issues.apache.org/jira/browse/WICKET-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994055#comment-12994055 ] Hudson commented on WICKET-3351: Integrated in Apache Wicket 1.4.x #434 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/434/]) WICKET-3351 Add class for span with text in wicket-extensions\treetable Add CSS class "text" to the label (just like it is in TreeTable$TreeFragment.html) > Add class for span with text in wicket-extensions\treetable > --- > > Key: WICKET-3351 > URL: https://issues.apache.org/jira/browse/WICKET-3351 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.4.14 >Reporter: Mishelle Bonq >Assignee: Martin Grigorov >Priority: Minor > Fix For: 1.4.16, 1.5-RC2 > > > Could you, please, add class "text" for a span with wicket:id="label" to > markup in > wicket-extensions\org\apache\wicket\extensions\markup\html\tree\table\TreeTable.html > as it is done in > wicket-extension\org\apache\wicket\extensions\markup\html\tree\table\TreeTable$TreeFragment.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3323) TreeTable should call attachUpdate javascript on domready event.
[ https://issues.apache.org/jira/browse/WICKET-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993591#comment-12993591 ] Hudson commented on WICKET-3323: Integrated in Apache Wicket 1.4.x #430 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/430/]) WICKET-3323 TreeTable should call attachUpdate javascript on domready event. Render 'Wicket.TreeTable.attachUpdate()' when DOM is ready, because otherwise wicket-ajax.js could not be available yet > TreeTable should call attachUpdate javascript on domready event. > > > Key: WICKET-3323 > URL: https://issues.apache.org/jira/browse/WICKET-3323 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.15 >Reporter: Alexander Morozov >Assignee: Martin Grigorov >Priority: Minor > Fix For: 1.4.16, 1.5-RC2 > > Attachments: fix-WICKET-1.4-3323.patch > > > Since Wicket-1.4.15 it is possible to filter javascript resources > (JavascriptFilteredIntoFooterHeaderResponse) and place them to the tail of > HTML document. It means that some embedded javascript can be broken because > of too early evaluation and missing dependencies. > I have faced with this problem in TreeTable component. But probably there are > other places in the framework, affected by this issue. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3414) Add break after finding Method in AutoComponentResolver invokeSetter
[
https://issues.apache.org/jira/browse/WICKET-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993590#comment-12993590
]
Hudson commented on WICKET-3414:
Integrated in Apache Wicket 1.4.x #430 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/430/])
WICKET-3414 Add break after finding Method in AutoComponentResolver
invokeSetter
Add a 'break' after finding the match. A little perf improvement.
> Add break after finding Method in AutoComponentResolver invokeSetter
>
>
> Key: WICKET-3414
> URL: https://issues.apache.org/jira/browse/WICKET-3414
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-RC1
> Environment: all
>Reporter: Richard Emberson
>Assignee: Martin Grigorov
>Priority: Minor
> Fix For: 1.4.16, 1.5-RC2
>
>
> org/apache/
> wicket/markup/resolver/AutoComponentResolver.java invokeSetter method
> change from:
> Method method = null;
> for (Method methodTested : methods)
> {
> if (methodTested.getName().equalsIgnoreCase(methodName))
> {
> method = methodTested;
> }
> }
> to:Method method = null;
> for (Method methodTested : methods)
> {
> if (methodTested.getName().equalsIgnoreCase(methodName))
> {
> method = methodTested;
> break;
> }
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3436) OnChangeAjaxBehavior can render javascript before wicket-ajax.js is loaded
[ https://issues.apache.org/jira/browse/WICKET-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993559#comment-12993559 ] Hudson commented on WICKET-3436: Integrated in Apache Wicket 1.4.x #429 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/429/]) WICKET-3436 OnChangeAjaxBehavior can render javascript before wicket-ajax.js is loaded Update the test expectation > OnChangeAjaxBehavior can render javascript before wicket-ajax.js is loaded > -- > > Key: WICKET-3436 > URL: https://issues.apache.org/jira/browse/WICKET-3436 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15 >Reporter: Alexander Morozov >Assignee: Martin Grigorov >Priority: Minor > Labels: javascript > Fix For: 1.4.16, 1.5-RC2 > > Attachments: fix-WICKET-3436.patch > > > In the current OnChangeAjaxBehavior implementation, the behavior renders > javascript (Wicket.ChangeHandler) > within the onComponentRendered() method directly to the response. Its okay in > case, when wicket-ajax.js is rendered in the head of the page, but if we move > javascript to the footer of the page, the inlined javascript will be broken. > I think, the javascript have to be evaluated after the DOM is built. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3436) OnChangeAjaxBehavior can render javascript before wicket-ajax.js is loaded
[ https://issues.apache.org/jira/browse/WICKET-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993436#comment-12993436 ] Hudson commented on WICKET-3436: Integrated in Apache Wicket 1.4.x #428 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/428/]) WICKET-3436 OnChangeAjaxBehavior can render javascript before wicket-ajax.js is loaded register Wicket.ChangeHandler when 'domready' event is fired. This way the registration doesn't depend on already loaded wicket-ajax.js > OnChangeAjaxBehavior can render javascript before wicket-ajax.js is loaded > -- > > Key: WICKET-3436 > URL: https://issues.apache.org/jira/browse/WICKET-3436 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15 >Reporter: Alexander Morozov >Assignee: Martin Grigorov >Priority: Minor > Labels: javascript > Fix For: 1.4.16, 1.5-RC2 > > Attachments: fix-WICKET-3436.patch > > > In the current OnChangeAjaxBehavior implementation, the behavior renders > javascript (Wicket.ChangeHandler) > within the onComponentRendered() method directly to the response. Its okay in > case, when wicket-ajax.js is rendered in the head of the page, but if we move > javascript to the footer of the page, the inlined javascript will be broken. > I think, the javascript have to be evaluated after the DOM is built. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3437) onselect script is not called for AutoCompleteTextField
[ https://issues.apache.org/jira/browse/WICKET-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993385#comment-12993385 ] Hudson commented on WICKET-3437: Integrated in Apache Wicket 1.4.x #427 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/427/]) Issue: WICKET-3437 > onselect script is not called for AutoCompleteTextField > --- > > Key: WICKET-3437 > URL: https://issues.apache.org/jira/browse/WICKET-3437 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.15 >Reporter: Wojciech Roczniak >Assignee: Igor Vaynberg > Labels: wicket > Fix For: 1.4.16, 1.5-RC2 > > Attachments: patch.patch, wicketAutocompletBug-1.0.war, > wicketAutocompletBug.zip > > > Each autcomplete result displayed by AutoCompleteTextField can have > 'onselect' script which > is called when result is selected. > This method is not called when results are rendered as table. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3438) 2xStatelessForm growing url when there is error validation
[
https://issues.apache.org/jira/browse/WICKET-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993280#comment-12993280
]
Hudson commented on WICKET-3438:
Integrated in Apache Wicket 1.4.x #426 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/426/])
> 2xStatelessForm growing url when there is error validation
> ---
>
> Key: WICKET-3438
> URL: https://issues.apache.org/jira/browse/WICKET-3438
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.15
>Reporter: Olivier Dutrieux
>Assignee: Igor Vaynberg
> Fix For: 1.4.16
>
> Attachments: WICKET-3438.patch, Wicket-test.rar
>
>
> Hello,
> I have a strange problem with 2xStatelessForm :
> I would like a stateless application with 2 StatelessForm and with somes
> required validators on form :
> public class HomePage extends WebPage {
> private static final long serialVersionUID = 1L;
> public HomePage(final PageParameters parameters) {
> super(parameters);
> setVersioned(false);
> Form form1 = new StatelessForm("form1") {
> @Override
> protected void onSubmit() {
> setResponsePage(ResultPage.class);
> }
> };
> form1.add(new TextField("input1").setRequired(true));
> add(form1);
> Form form2 = new StatelessForm("form2") {
> @Override
> protected void onSubmit() {
> setResponsePage(ResultPage.class);
> }
> };
> form2.add(new TextField("input1").setRequired(true));
> add(form2);
> }
> }
> The problem is when I submit alternatively each form (I don't fill the
> Textfield required intentionally), the url growing like this :
> 1st submit :
> http://localhost:8080/Wicket-Test/HomePage.html?wicket:interface=:0:form2::IFormSubmitListener::
> 2nd submit :
> http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=&wicket:interface=:0:form1::IFormSubmitListener::
> 3th submit :
> http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=&form12_hf_0=&wicket:interface=:0:form2::IFormSubmitListener::
> 4th submit :
> http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=&form22_hf_0=&form12_hf_0=&wicket:interface=:0:form1::IFormSubmitListener::
> ...
> Is there a solution to solve this problem ?
> Best regards
> Duto
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3276) CLONE -How to set custom HTTP response header in Wicket's Ajax responses?
[ https://issues.apache.org/jira/browse/WICKET-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992835#comment-12992835 ] Hudson commented on WICKET-3276: Integrated in Apache Wicket 1.4.x #424 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/424/]) added javadoc warnings Issue: WICKET-3276 > CLONE -How to set custom HTTP response header in Wicket's Ajax responses? > - > > Key: WICKET-3276 > URL: https://issues.apache.org/jira/browse/WICKET-3276 > Project: Wicket > Issue Type: Bug >Reporter: Martin Funk >Assignee: Igor Vaynberg > > http://stackoverflow.com/questions/4397211/how-to-set-custom-http-response-header-in-wickets-ajax-responses/4399434#4399434 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3109) Using PopupSettings creates page maps early
[ https://issues.apache.org/jira/browse/WICKET-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987732#action_12987732 ] Hudson commented on WICKET-3109: Integrated in Apache Wicket 1.4.x #409 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/409/]) restoring the PopupSettings(IPageMap pageMapName, final int displayFlags) constructor as deprecated Issue: WICKET-3109 > Using PopupSettings creates page maps early > --- > > Key: WICKET-3109 > URL: https://issues.apache.org/jira/browse/WICKET-3109 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.12 >Reporter: Jeremy Thomerson >Assignee: Pedro Santos >Priority: Minor > Fix For: 1.4.16 > > Attachments: WICKET-3109.patch > > > See WICKET-3108 for a description of the background (and a quickstart to > demonstrate) > The issue here is that whenever you create a link and add PopupSettings to > it, it creates a page map. The page map shouldn't be created until someone > actually clicks the link, though. The page map name will need to go in the > URL, but the page map can be lazy-created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3109) Using PopupSettings creates page maps early
[ https://issues.apache.org/jira/browse/WICKET-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987694#action_12987694 ] Hudson commented on WICKET-3109: Integrated in Apache Wicket 1.4.x #407 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/407/]) avoiding early page maps creation when link has an popup setting Issue: WICKET-3109 > Using PopupSettings creates page maps early > --- > > Key: WICKET-3109 > URL: https://issues.apache.org/jira/browse/WICKET-3109 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.12 >Reporter: Jeremy Thomerson >Assignee: Pedro Santos >Priority: Minor > Fix For: 1.4.16 > > Attachments: WICKET-3109.patch > > > See WICKET-3108 for a description of the background (and a quickstart to > demonstrate) > The issue here is that whenever you create a link and add PopupSettings to > it, it creates a page map. The page map shouldn't be created until someone > actually clicks the link, though. The page map name will need to go in the > URL, but the page map can be lazy-created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3398) EnclosureContainer: configure() should be called on the child component before calling isVisible on it
[ https://issues.apache.org/jira/browse/WICKET-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987657#action_12987657 ] Hudson commented on WICKET-3398: Integrated in Apache Wicket 1.4.x #406 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/406/]) Issue: WICKET-3398 > EnclosureContainer: configure() should be called on the child component > before calling isVisible on it > -- > > Key: WICKET-3398 > URL: https://issues.apache.org/jira/browse/WICKET-3398 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15, 1.5-RC1 >Reporter: Ulrike M >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.16, 1.5-RC2 > > > As advised by the javadoc for Component#onConfigure, we switched to this > mechanism instead of overriding isVisible/isEnabled when they contain > extensive logic. > Now if we do that for a child component that will control the visibility of > the EnclosureContainer, EnclosureContainer#isVisible directly calls through > to #isVisible on the child component, and this may happen before #onConfigure > on the child ever gets called. In our situation where we set the visibility > in #onConfigure, the result of #isVisible may change during the request > cycle, which may lead to undesirable and confusing results. > The javadoc for Component#configure states that for linked components, > #configure should be called on the 'other' component. Applied to > EnclosureContainer, I think the correct way to handle this is that > EnclosureContainer#onConfigure must be overridden in order to call > child.configure(). This way, any call to #isVisible will only occur after > #onConfigure has been called, the sequence is correct again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1802) Propertyresolver could be more informative
[ https://issues.apache.org/jira/browse/WICKET-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987518#action_12987518 ] Hudson commented on WICKET-1802: Integrated in Apache Wicket 1.4.x #405 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/405/]) merging message improvement on PropertyResolver from trunk Issue: WICKET-1802 > Propertyresolver could be more informative > -- > > Key: WICKET-1802 > URL: https://issues.apache.org/jira/browse/WICKET-1802 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M3 >Reporter: Martin Makundi >Assignee: Johan Compagner > Fix For: 1.4.16, 1.5-RC2 > > Original Estimate: 1h > Remaining Estimate: 1h > > WicketMessage: no set method defined for value: true on object: ... > at > org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.setValue(PropertyResolver.java:1107) > In case there is a getter method defined, it would significantly help > debugging to display the get method name in the exception. > I suggest fixing the problem with: > - " on object: " + object); > + " on object: " + object + " while > respective getMethod being " + getMethod.getName()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3346) Wicket examples still show a Graduated logo
[ https://issues.apache.org/jira/browse/WICKET-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987309#action_12987309 ] Hudson commented on WICKET-3346: Integrated in Apache Wicket 1.4.x #404 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/404/]) > Wicket examples still show a Graduated logo > --- > > Key: WICKET-3346 > URL: https://issues.apache.org/jira/browse/WICKET-3346 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.4.15, 1.5-M3 >Reporter: Martijn Dashorst >Assignee: Peter Ertl >Priority: Blocker > Fix For: 1.4.16, 1.5-RC2 > > > The wicket examples still feature a Wicket has graduated logo. While nice 3 > years ago when we were just graduated, it has now no meaning for us. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3354) Improve SerializableChecker message
[ https://issues.apache.org/jira/browse/WICKET-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985819#action_12985819 ] Hudson commented on WICKET-3354: Integrated in Apache Wicket 1.4.x #399 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/399/]) changing the SerializableChecker to catch runtime exceptions while scanning fields Issue: WICKET-3354 > Improve SerializableChecker message > --- > > Key: WICKET-3354 > URL: https://issues.apache.org/jira/browse/WICKET-3354 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.4.15, 1.5-M3 >Reporter: Pedro Santos >Assignee: Pedro Santos >Priority: Minor > Fix For: 1.4.16, 1.5-RC2 > > Attachments: WICKET-3354-2.patch, WICKET-3354-3.patch, > WICKET-3354.patch > > > Currently if the object has an problematic implementation of equals method, > the serializable checker will stop its work with an runtime exception. The > best would be just log an warn explaining the the problem on console and > continue the checks until the non serializable source of the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3358) Wicket-Guice integration fails - can't find application attached to current thread
[ https://issues.apache.org/jira/browse/WICKET-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985472#action_12985472 ] Hudson commented on WICKET-3358: Integrated in Apache Wicket 1.4.x #398 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/398/]) > Wicket-Guice integration fails - can't find application attached to current > thread > -- > > Key: WICKET-3358 > URL: https://issues.apache.org/jira/browse/WICKET-3358 > Project: Wicket > Issue Type: Bug > Components: wicket-guice >Affects Versions: 1.4.8 > Environment: Windows 7, JSDK 1.6.21, Maven 3.0.3 >Reporter: Marek Zganiacz >Assignee: Igor Vaynberg > Fix For: 1.4.16 > > Attachments: wicketBugDemo.rar > > > Simply by starting new project from wicket archetype, then adding a > dependency to guice 2.0 and wicket-guice 1.4.8 and providing the guice module > through web.xml to GuiceComponentInjector one can get the exception when > starting jetty: > org.apache.wicket.WicketRuntimeException: There is no application attached to > current thread main > at org.apache.wicket.Application.get(Application.java:179) > at > org.apache.wicket.injection.web.InjectorHolder.setInjector(InjectorHolder.java:88) > at > org.apache.wicket.guice.GuiceComponentInjector.(GuiceComponentInjector.java:102) > at > org.apache.wicket.guice.GuiceWebApplicationFactory.createApplication(GuiceWebApplicationFactory.java:177) > at > org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:701) > at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) > at > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3135) Improve JavaScriptPackageResource#toString() to show filename instead of default Object#toString()
[ https://issues.apache.org/jira/browse/WICKET-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985471#action_12985471 ] Hudson commented on WICKET-3135: Integrated in Apache Wicket 1.4.x #398 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/398/]) > Improve JavaScriptPackageResource#toString() to show filename instead of > default Object#toString() > -- > > Key: WICKET-3135 > URL: https://issues.apache.org/jira/browse/WICKET-3135 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13 >Reporter: Martijn Dashorst >Assignee: Igor Vaynberg > Fix For: 1.4.16 > > Attachments: fix-WICKET-3135.patch, test-WICKET-3135.patch > > > For seeing the difference between normal page requests (and ajax requests) > and resource request, the requestlogger needs to output the actual filename > of the resource. This allows for a top 10 most requested resources... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3307) UploadProgressbar doesn't work when nested in ModalWindow (using IE 8.0.7600)
[ https://issues.apache.org/jira/browse/WICKET-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982657#action_12982657 ] Hudson commented on WICKET-3307: Integrated in Apache Wicket 1.4.x #389 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/389/]) Detecting if there is an ModalWindow in the hierarchy to bind the JavaScript to the correct form. Issue: WICKET-3307 > UploadProgressbar doesn't work when nested in ModalWindow (using IE 8.0.7600) > - > > Key: WICKET-3307 > URL: https://issues.apache.org/jira/browse/WICKET-3307 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.15 > Environment: Window 7, 32 Bit, IE 8 >Reporter: Paul >Assignee: Pedro Santos > Fix For: 1.4.16, 1.5-RC2 > > Attachments: myproject.rar, WICKET-3307.patch > > > When a UploadProgressbar is nested in a ModalWindow you cannot upload > anything, due to a JavaScript Problem while using IE 8. Firefox, Chrome, > etc. are fine. > IE says: Unknown Runtimeerror > In Debugmode I can narrow it down to progressbar.js, Line 31 > For reproduction I attached a quickstart. > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3321) Ajax submit link does not show busy indicator under IE
[ https://issues.apache.org/jira/browse/WICKET-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980459#action_12980459 ] Hudson commented on WICKET-3321: Integrated in Apache Wicket 1.4.x #383 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/383/]) > Ajax submit link does not show busy indicator under IE > > > Key: WICKET-3321 > URL: https://issues.apache.org/jira/browse/WICKET-3321 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15 >Reporter: Wojciech Roczniak >Assignee: Martin Grigorov > Attachments: ajaxIndicatorBugIE.tar.gz > > > When form is sumbitted via link inside form then busy indicator is not shown > under IE. > The problem occurs only when form was earlier refreshed via ajax. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3315) PackagedTextTemplate should set lastModifiedTime
[ https://issues.apache.org/jira/browse/WICKET-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980460#action_12980460 ] Hudson commented on WICKET-3315: Integrated in Apache Wicket 1.4.x #383 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/383/]) > PackagedTextTemplate should set lastModifiedTime > > > Key: WICKET-3315 > URL: https://issues.apache.org/jira/browse/WICKET-3315 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.15 >Reporter: Guillaume Smet >Assignee: Peter Ertl >Priority: Minor > Fix For: 1.4.16, 1.5-M4 > > Attachments: WICKET-3315.patch > > > Hi, > When using TextTemplateResourceReference in a > setAddLastModifiedTimeToResourceReferenceUrl(true) configuration, the w:lm > parameter isn't added to the URL of the resource as > PackagedTextTemplate.lastModifiedTime() (called in > TextTemplateResourceReference.lastModifiedTime()) always returns null. > IMHO, PackagedTextTemplate should set lastModifiedTime when accessing the > resource. > AFAICS, the cache code at the top of PackagedTextTemplate isn't used at all > so I think we can simply set it in the constructor when we access the stream. > This is what the attached patch does. > Any comment? > -- > Guillaume -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3319) AjaxEditableMultilineLabel generates invalid HTML
[ https://issues.apache.org/jira/browse/WICKET-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979742#action_12979742 ] Hudson commented on WICKET-3319: Integrated in Apache Wicket 1.4.x #379 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/379/]) WICKET-3319 AjaxEditableMultilineLabel generates invalid HTML Replace with for AjaxEditableMultilineLabel's MultiLineLabel merge r1057326 from trunk > AjaxEditableMultilineLabel generates invalid HTML > - > > Key: WICKET-3319 > URL: https://issues.apache.org/jira/browse/WICKET-3319 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.14 >Reporter: Peter Parson >Assignee: Martin Grigorov > Fix For: 1.4.16, 1.5-M4 > > > When using an AjaxEditableMultilineLabel, the generated markup looks like: > > 1st paragraph > 2nd paragraph > > This is invalid according to HTML spec (block elements (p) are not allowed > within inline elements (span)). > AjaxEditableMultilineLabel should be using a element instead of the > . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3308) Turn the FormComponent#getConvertedInput method to protected
[ https://issues.apache.org/jira/browse/WICKET-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979031#action_12979031 ] Hudson commented on WICKET-3308: Integrated in Apache Wicket 1.4.x #376 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/376/]) > Turn the FormComponent#getConvertedInput method to protected > > > Key: WICKET-3308 > URL: https://issues.apache.org/jira/browse/WICKET-3308 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.5-M3 >Reporter: Pedro Santos >Assignee: Igor Vaynberg >Priority: Trivial > > Pasting a message from the irc: > "whats the "right" way of retreiving values from a simple formcomponent such > as textfield: youve got getModel, getValue, getInput, > getConvertedValue, ..." > getConvertedInput is mainly used by updateModel and FormComponent subclasses, > an protected access modifier would make the API clearer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3309) unable to add nodes to an empty rootless Tree (e.g. LinkTree)
[ https://issues.apache.org/jira/browse/WICKET-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979030#action_12979030 ] Hudson commented on WICKET-3309: Integrated in Apache Wicket 1.4.x #376 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/376/]) > unable to add nodes to an empty rootless Tree (e.g. LinkTree) > - > > Key: WICKET-3309 > URL: https://issues.apache.org/jira/browse/WICKET-3309 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13, 1.4.14, 1.4.15 >Reporter: Gabriel Bucher >Assignee: Pedro Santos > Fix For: 1.4.16, 1.5-M4 > > Attachments: quickstart.tar.gz, WICKET-3309.patch > > > 2 scenarios which adding new nodes (via ajax) to a rootless Tree is not > working as expected. > the node is getting added to the treemodel but non is displayed. > 1) adding a node to the rootnode. the newly added node is not displayed. > 2) the rootless tree already has a node. if you add additional nodes to the > root node, they will be displayed (compare to 1), if you add an additional > node to one of the added nodes, the complete tree will disappear. > see attached quickstart -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3307) UploadProgressbar doesn't work when nested in ModalWindow (using IE 8.0.7600)
[ https://issues.apache.org/jira/browse/WICKET-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978592#action_12978592 ] Hudson commented on WICKET-3307: Integrated in Apache Wicket 1.4.x #373 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/373/]) > UploadProgressbar doesn't work when nested in ModalWindow (using IE 8.0.7600) > - > > Key: WICKET-3307 > URL: https://issues.apache.org/jira/browse/WICKET-3307 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.15 > Environment: Window 7, 32 Bit, IE 8 >Reporter: Paul >Assignee: Pedro Santos > Fix For: 1.4.16, 1.5-M4 > > Attachments: myproject.rar > > > When a UploadProgressbar is nested in a ModalWindow you cannot upload > anything, due to a JavaScript Problem while using IE 8. Firefox, Chrome, > etc. are fine. > IE says: Unknown Runtimeerror > In Debugmode I can narrow it down to progressbar.js, Line 31 > For reproduction I attached a quickstart. > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3294) Use Apache Nexus to stage releases for voting and for release into maven central
[ https://issues.apache.org/jira/browse/WICKET-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978591#action_12978591 ] Hudson commented on WICKET-3294: Integrated in Apache Wicket 1.4.x #373 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/373/]) > Use Apache Nexus to stage releases for voting and for release into maven > central > > > Key: WICKET-3294 > URL: https://issues.apache.org/jira/browse/WICKET-3294 > Project: Wicket > Issue Type: Improvement > Components: site, wicket >Reporter: Michael O'Cleirigh > Attachments: wicket-1.4.x-pom.xml.diff, wicket-1.5.x-pom.xml.diff > > > This issue from June 2010 was about deploying the 1.4.x-SNAPSHOT and > 1.5-SNAPSHOT releases into the Apache Nexus Maven Repository: > https://issues.apache.org/jira/browse/WICKET-2918 > This issue is about switching from the current release method to use the > staging facilities provided through https://repository.apache.org > There is an issue with the metadata contained in the maven central repository > being out of date that this issue will hopefully resolve as a side effect: > https://issues.sonatype.org/browse/MVNCENTRAL-28 > This is the apache documentation for publishing maven artifacts through > repository.apache.org: > http://www.apache.org/dev/publishing-maven-artifacts.html > According to it that page the distribution management section in the parent > org.apache:apache:8 pom contains the details for staging. So what needs to > happen is that the parent pom.xml is upgraded from version 7 to version 8 and > that the release profiles are adjusted so that only the entry is > contained in the distribution management sections. > There are some settings mentioned that need to go into the deployers local > ~/.m2/settings.xml but I am assuming that it is going to be close to what is > used for the current release process. > Then when the deploy part the release is run the jar, javadoc and source > artifacts will be signed and uploaded into a staging repository. You login > to the repository.apache.org page and on the left hand side you should be > able to see a 'Staging Repository' link and clicking it will show a table > listing the staged repositories. > The url associated with each staged repository doesn't work for reading until > it has been closed. So if you encounter a bug in the deployment part you can > fix it and continue with any old artifacts just overwriting what was > previously uploaded. Then within the nexus interface you right click on the > row (not on the url part) and select 'close' from the options. > Once closed the url can be used for the release vote. If the vote fails the > staged repository can be dropped. If the vote succeeds then the staged > repository can be promoted into a real release. At least in oss.sonatype.org > within 1 hour of the promotion the artifact will be synced into the central > maven repository. > It should be possible to test out this improvement ahead of the next release > by just deploying into a staged repository and then dropping it if everything > is added properly. > I will attach the modified /trunk/pom.xml and /branches/wicket-1.4.x/pom.xml > versions that should let this work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3306) OrderByBoder MArkup problem
[ https://issues.apache.org/jira/browse/WICKET-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977356#action_12977356 ] Hudson commented on WICKET-3306: Integrated in Apache Wicket 1.4.x #367 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/367/]) Issue: WICKET-3306 > OrderByBoder MArkup problem > --- > > Key: WICKET-3306 > URL: https://issues.apache.org/jira/browse/WICKET-3306 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.15 > Environment: Windows 7, Tomcat 6.x, Eclipse Helios >Reporter: Peter Diefenthäler >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.16, 1.5-M4 > > Attachments: QuickStart.war > > > I'm using the OrderByBorder feature and it works well for rows > without stylesheet classes. > Unfortunately it fails if the already has a stylesheet class: > > > > Wicket replaces the class="NameField"with the > class="wicket_orderUp" and my field width properties will be lost. > It would be better, if Wicket would add his style class instead of > replacing it ( class="NameField,wicket_orderUp") > public static class CssModifier extends AttributeModifier > This seems to be the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3275) Log a warn or throw an exception when an AjaxFormComponentUpdatingBehavior is added to an choice component
[
https://issues.apache.org/jira/browse/WICKET-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977357#action_12977357
]
Hudson commented on WICKET-3275:
Integrated in Apache Wicket 1.4.x #367 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/367/])
> Log a warn or throw an exception when an AjaxFormComponentUpdatingBehavior is
> added to an choice component
> --
>
> Key: WICKET-3275
> URL: https://issues.apache.org/jira/browse/WICKET-3275
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4.14, 1.5-M3
>Reporter: Pedro Santos
>Assignee: Pedro Santos
>Priority: Trivial
> Fix For: 1.4.16, 1.5-M4
>
>
> I was thinking about warn on console:
> String.format("AjaxFormComponentUpdatingBehavior is not suposed to be add in
> the form component %s. AjaxFormChoiceComponentUpdatingBehavior is meant for
> choices/groups that are not one component in the html but many",
> getComponent().getPageRelativePath())
> at AjaxFormComponentUpdatingBehavior#bind when we detect that the component
> is an instance of: RadioChoice, CheckBoxMultipleChoice, RadioGroup, CheckGroup
> Just don't know if it is better throw an exception instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3302) Endless recursion if LoadableDetachableModel.load throws exception
[
https://issues.apache.org/jira/browse/WICKET-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977355#action_12977355
]
Hudson commented on WICKET-3302:
Integrated in Apache Wicket 1.4.x #367 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/367/])
Issue: WICKET-3302
> Endless recursion if LoadableDetachableModel.load throws exception
> --
>
> Key: WICKET-3302
> URL: https://issues.apache.org/jira/browse/WICKET-3302
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5-M3
>Reporter: Willis Blackburn
>Assignee: Igor Vaynberg
> Fix For: 1.4.16, 1.5-M4
>
>
> I don't know if there's any easy fix for this, but here's what happens:
> 1. Component subclass overrides isVisible with a new implementation that
> depends on the current model state.
> 2. The model is a LoadableDetachableModel.
> 3. On the initial render, the load method of the LoadableDetachableModel
> throws a RuntimeException for whatever reason. (In my case I was trying to
> throw a AbortWithHttpErrorCodeException.)
> 4. This gets caught in Component.getDefaultModelObject:
> log.error("Error while getting default model object for Component: " +
> this.toString(true));
> 5. The toString method that's invoked from the exception handler prints the
> component's state, including its visibility.
> 6. In order to resolve the visibility state, toString has to call
> isVisible--the same method that initially caused the exception.
> 7. The isVisible method again throws an exception, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer
[ https://issues.apache.org/jira/browse/WICKET-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976372#action_12976372 ] Hudson commented on WICKET-1973: Integrated in Apache Wicket 1.4.x #362 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/362/]) > Messages lost upon session failover with redirect_to_buffer > --- > > Key: WICKET-1973 > URL: https://issues.apache.org/jira/browse/WICKET-1973 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC1 >Reporter: Erik van Oosten >Assignee: Martin Grigorov > Fix For: 1.4.16, 1.5-M4 > > > Using the redirect_to_buffer render strategy, messages in the session get > cleared after the render. > If the redirected request comes in at another node, the buffer is not found > and the page is re-rendered. In this case the messages are no longer > available. > See the javadoc of WebApplication#popBufferedResponse(String,String). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3277) CLONE -AbstractMarkupParser doesn't remove Comments correctly
[ https://issues.apache.org/jira/browse/WICKET-3277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974154#action_12974154 ] Hudson commented on WICKET-3277: Integrated in Apache Wicket 1.4.x #351 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/351/]) fixed CLONE -AbstractMarkupParser doesn't remove Comments correctly. Issue: WICKET-3277 > CLONE -AbstractMarkupParser doesn't remove Comments correctly > - > > Key: WICKET-3277 > URL: https://issues.apache.org/jira/browse/WICKET-3277 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.5-M3 >Reporter: Martin Funk >Assignee: Juergen Donnerstag > Fix For: 1.4.15 > > > AbstractMarkupParser removeComment(...) doesn't remove Comments correctly > if two html comments stand to close together > foo will be removed but not bar. > see: > https://github.com/mafulafunk/wicketComments > g...@github.com:mafulafunk/wicketComments.git -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3275) Log a warn or throw an exception when an AjaxFormComponentUpdatingBehavior is added to an choice component
[
https://issues.apache.org/jira/browse/WICKET-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973287#action_12973287
]
Hudson commented on WICKET-3275:
Integrated in Apache Wicket 1.4.x #346 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/346/])
Log a warn when an AjaxFormComponentUpdatingBehavior is added to an choice
component
Issue: WICKET-3275
> Log a warn or throw an exception when an AjaxFormComponentUpdatingBehavior is
> added to an choice component
> --
>
> Key: WICKET-3275
> URL: https://issues.apache.org/jira/browse/WICKET-3275
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4.14, 1.5-M3
>Reporter: Pedro Santos
>Priority: Trivial
>
> I was thinking about warn on console:
> String.format("AjaxFormComponentUpdatingBehavior is not suposed to be add in
> the form component %s. AjaxFormChoiceComponentUpdatingBehavior is meant for
> choices/groups that are not one component in the html but many",
> getComponent().getPageRelativePath())
> at AjaxFormComponentUpdatingBehavior#bind when we detect that the component
> is an instance of: RadioChoice, CheckBoxMultipleChoice, RadioGroup, CheckGroup
> Just don't know if it is better throw an exception instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3264) MetaDataEntry set method traverses metaData even after key is found and data set/cleared
[
https://issues.apache.org/jira/browse/WICKET-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972740#action_12972740
]
Hudson commented on WICKET-3264:
Integrated in Apache Wicket 1.4.x #342 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/342/])
> MetaDataEntry set method traverses metaData even after key is found and data
> set/cleared
>
>
> Key: WICKET-3264
> URL: https://issues.apache.org/jira/browse/WICKET-3264
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: all
>Reporter: Richard Emberson
>Priority: Trivial
>
> The for-loop in the MetaDataKey set method has a break statement that is only
> called if metaData is set to null. The break statement should be after the
> set = true;
> statement.
> Why? from what I can tell, per-key, data can only be entered into the
> MetaDataEntry
> array once. The data is added only if isSet == false, and this happens only
> if the
> key is not found in the array.
> Also, he get method only returns the first entry found for a given key so
> it makes no sense to actually have more than one entry.
> So, change from:
> else
> {
> metaData = null;
> break;
> }
> }
> set = true;
> }
> to:
> else
> {
> metaData = null;
> }
> }
> set = true;
> break;
> }
> I've made the change on my copy and all of the tests pass.
> If a user is directly playing with the data Object,
> Object data = null;
> in Component rather than using the given methods, then all bets are off
> anyway.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3265) Component data_remove returns Object which is never used
[ https://issues.apache.org/jira/browse/WICKET-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972731#action_12972731 ] Hudson commented on WICKET-3265: Integrated in Apache Wicket 1.4.x #340 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/340/]) fixes WICKET-3265 for 1.4.x branch > Component data_remove returns Object which is never used > > > Key: WICKET-3265 > URL: https://issues.apache.org/jira/browse/WICKET-3265 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M3 > Environment: All >Reporter: Richard Emberson >Assignee: Jeremy Thomerson >Priority: Trivial > Fix For: 1.4.15, 1.5-M4 > > > The Component method data_remove has the signature: > private Object data_remove(int position) > It returns an Object and it is private. > Only three places call data_remove in Component and none of them use > the return value. > Simplify the code in data_remove so that it does not return the data > being removed. > At some future time, one can always call data_get if one really needs the > value prior to removing it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3258) Allow for non-relative redirects for buggy servlet containers
[
https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972309#action_12972309
]
Hudson commented on WICKET-3258:
Integrated in Apache Wicket 1.4.x #336 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/336/])
> Allow for non-relative redirects for buggy servlet containers
> -
>
> Key: WICKET-3258
> URL: https://issues.apache.org/jira/browse/WICKET-3258
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4.14, 1.5-M3
> Environment: Websphere
>Reporter: Jeremy Thomerson
>Assignee: Jeremy Thomerson
>Priority: Minor
> Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs. The
> servlet spec
> (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260
> specifies the behavior for relative URLs, which Wicket uses, but WebSphere
> appears to ignore. If we send a relative URL like "../../Something.html" to
> HttpServletResponse#sendRedirect, the relative path should be relative *to
> the requested URI* (the page I was requesting that resulted in the redirect).
> WebSphere isn't implementing this behavior correctly. Instead, it appears
> to interpret it as relative *to the app context and servlet mapping*.
>
> More details:
>
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>
> That page results in an error, and Wicket tries to redirect to an unmounted
> bookmarkable page by doing
> sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage"). This is correct
> according to the servlet spec, because the url passed to sendRedirect should
> be relative *to the requested URI* (<--- this is the key). So, we expect the
> container to redirect to
> http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage
> . Jetty does (and Tomcat and others). But, WebSphere does not.
>
> Although I cannot look at the Websphere code, I suspect that it is
> interpreting this relative URL as being relative to the root of the servlet
> mapping. It is then removing two folders, which takes us back to the server
> root (instead of the servlet mapping, like it should), removing the app
> context and servlet mapping (i.e.
> http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is
> obviously incorrect.
>
> We have tried this compatibility setting (true and false), but it didn't
> work:
> https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users
> of these servlet containers to redirect to an absolute URL rather than a
> relative URL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3259) Filter path is occasionally null when forwarding a request
[ https://issues.apache.org/jira/browse/WICKET-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972308#action_12972308 ] Hudson commented on WICKET-3259: Integrated in Apache Wicket 1.4.x #336 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/336/]) fixes WICKET-3259 for wicket-1.4.x branch > Filter path is occasionally null when forwarding a request > -- > > Key: WICKET-3259 > URL: https://issues.apache.org/jira/browse/WICKET-3259 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14, 1.5-M3 >Reporter: Jeremy Thomerson >Assignee: Jeremy Thomerson >Priority: Minor > Attachments: relativeurlproblem.tar.gz > > > If you have a 404 specified in your web.xml that points to some wicket page, > and that page throws a RestartResponseAtInterceptPage exception, you end up > with a NullPointerException when trying to create the URL for the page. The > NPE is because forwardUrl is not null, but filterPath is (in > ServletWebRequest#getRelativePathPrefixToWicketHandler()) > See the attached quickstart and go to > http://localhost:8080/app-context-path/mounted-pattern/akdslfjasdklfj (which > doesn't exist) to see the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3202) Form with UploadProgressBar and AjaxButton doesn't submit
[ https://issues.apache.org/jira/browse/WICKET-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971523#action_12971523 ] Hudson commented on WICKET-3202: Integrated in Apache Wicket 1.4.x #328 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/328/]) using an iframe to do the asynchronous progress bar update Issue: WICKET-3202 > Form with UploadProgressBar and AjaxButton doesn't submit > - > > Key: WICKET-3202 > URL: https://issues.apache.org/jira/browse/WICKET-3202 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.5-M3 > Environment: Windows 7, java 1.6 >Reporter: Ivan Vasilev >Assignee: Pedro Santos > Fix For: 1.4.15, 1.5-M4 > > Attachments: quickstart.rar, WICKET-3202-using-iframe.patch, > WICKET-3202-using-wicket-ajax.patch, WICKET-3202.patch > > > There is a Form and a FIleUploadField and UploadProgressBar in it. The form > is submitted via AjaxButton. If the user tries to upload a file, nothing > happens (at least nothing on the server side). If the UploadProgressBar is > removed from the form everything works fine. This behavior can be observed in > the attached quickstart. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3254) Add file name to the exception in case of an error during temp file creation for upload
[ https://issues.apache.org/jira/browse/WICKET-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971274#action_12971274 ] Hudson commented on WICKET-3254: Integrated in Apache Wicket 1.4.x #326 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/326/]) WICKET-3254 Add file name to the exception in case of an error during temp file creation for upload Print the name of the temporary file when its creation fails for some I/O reason. > Add file name to the exception in case of an error during temp file creation > for upload > --- > > Key: WICKET-3254 > URL: https://issues.apache.org/jira/browse/WICKET-3254 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.14 >Reporter: Kariem Hussein >Assignee: Martin Grigorov > Fix For: 1.4.15, 1.5-M4 > > Attachments: wicket-3254-add-filename-to-exception.diff > > > The default error output of File.createNewFile() does not contain the file > being created. Please add the file being created to the generated runtime > exception in org.apache.wicket.util.upload.DiskFileItem. > One-line patch will be attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3253) NPE with nested property models
[ https://issues.apache.org/jira/browse/WICKET-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970804#action_12970804 ] Hudson commented on WICKET-3253: Integrated in Apache Wicket 1.4.x #324 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/324/]) - Preventing the attempt to resolve the property class for a null target at AbstractPropertyModel - Test asserting that there is no problem in working with an AbstractPropertyModel targeting an IObjectClassAwareModel not initialized with an known class. Issue: WICKET-3253 > NPE with nested property models > --- > > Key: WICKET-3253 > URL: https://issues.apache.org/jira/browse/WICKET-3253 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.14 >Reporter: Tobias Bergman >Assignee: Pedro Santos > Fix For: 1.4.15, 1.5-M4 > > Attachments: wicket-property-model-bug.zip > > > After updated from 1.4.8 to 1.4.14 I got this bug. > The problem is with nested property models where the "top" model has a null > model object that is bound to a TextField. You get a NPE when the page is > rendered. There is a quick workaround by overriding getOjbectClass() on the > property model. > I provide a running example of the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3229) Removing Child in IVisitor affects traversal
[
https://issues.apache.org/jira/browse/WICKET-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970673#action_12970673
]
Hudson commented on WICKET-3229:
Integrated in Apache Wicket 1.4.x #322 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/322/])
> Removing Child in IVisitor affects traversal
>
>
> Key: WICKET-3229
> URL: https://issues.apache.org/jira/browse/WICKET-3229
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.12
>Reporter: Jacob Brookover
>Priority: Minor
> Fix For: 1.4.15, 1.5-M4
>
> Attachments: WICKET-3229.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Created a Panel that provides it's own dynamically created markup stream,
> scans that stream for wicket:ids, and adds different components based on the
> id. Recently, I've been wanting to redraw this panel via AJAX, changing the
> markup and adding and removing child components accordingly.
> I tried to remove multiple stale components (e.g. a component that was
> generated from the previous markup but doesn't exist in the new markup) using
> an IVisitor..
> visitChildren(new IVisitor() {
> public Object component(Component component) {
> if (/* component is stale */)
> component.remove();
> return CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER;
> }
> The IVisitor just does a simple run through an array and removing the
> component adjusted the size/count of the array, messing up the traversal and
> preventing other components from being removed.
> Potential Solutions:
> 1. Throw an exception if the hierarchy is modified in an IVisitor.
> 2. Use another means of traversing the children that allows addition/removal
> and still ensures visiting all the children.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3237) Exception when calling setOutputMarkupId/PlaceholderTag on wicket:container
[ https://issues.apache.org/jira/browse/WICKET-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970672#action_12970672 ] Hudson commented on WICKET-3237: Integrated in Apache Wicket 1.4.x #322 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/322/]) Testing the ignore attribute modifier set on Component in order to avoid warn to 'output markup id' and 'place holder tag' flags set on panels and borders rendering the tag wicket:panel and wicket:border Issue: WICKET-3237 > Exception when calling setOutputMarkupId/PlaceholderTag on wicket:container > --- > > Key: WICKET-3237 > URL: https://issues.apache.org/jira/browse/WICKET-3237 > Project: Wicket > Issue Type: Wish > Components: wicket >Reporter: Peter Parson >Assignee: Pedro Santos >Priority: Minor > Fix For: 1.4.15, 1.5-M4 > > Attachments: WICKET-3237.patch > > > Is it possible to throw an exception when using setOutputMarkupId or > setOutputPlaceholderTag on a wicket:container element? > Doing so is a common pitfall (especially for beginners), because one does not > always have the markup in mind when working on the java part. Throwing an > exception would make the problem easier to find for the developer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3244) libxml2 splits large CData section. This breaks the processEvaluate js
[ https://issues.apache.org/jira/browse/WICKET-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970443#action_12970443 ] Hudson commented on WICKET-3244: Integrated in Apache Wicket 1.4.x #319 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/319/]) WICKET-3244 libxml2 splits large CData section. This breaks the processEvaluate js Read text/cdata by iterating over all child nodes Uses a "static" Wicket._readTextNode() because Wicket.Ajax.Call and Wicket.Head.Contributor don't have common parent. merge r1044616 from 1.5 > libxml2 splits large CData section. This breaks the processEvaluate js > --- > > Key: WICKET-3244 > URL: https://issues.apache.org/jira/browse/WICKET-3244 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13 >Reporter: Damien Hollis >Assignee: Martin Grigorov >Priority: Critical > Fix For: 1.4.15, 1.5-M4 > > Attachments: wicket-ajax.js.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is exactly the same problem as WICKET-2759 but the processEvaluate code > did not have the same fix applied. > I will attach a patch file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3235) AutoCompleteBehavior overwrites base class AbstractAutoCompleteBehavior settings variable
[ https://issues.apache.org/jira/browse/WICKET-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968513#action_12968513 ] Hudson commented on WICKET-3235: Integrated in Apache Wicket 1.4.x #312 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/312/]) - code cleanup - deprecating the preselect variable that was no longer used and start to consider its value (it is protected, we can't just remove it ) Issue: WICKET-3235 > AutoCompleteBehavior overwrites base class AbstractAutoCompleteBehavior > settings variable > - > > Key: WICKET-3235 > URL: https://issues.apache.org/jira/browse/WICKET-3235 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5-M3 > Environment: all >Reporter: Richard Emberson >Assignee: Pedro Santos >Priority: Trivial > Fix For: 1.4.15, 1.5-M4 > > > AutoCompleteBehavior's base class AbstractAutoCompleteBehavior creates the > settings > instance variable: > protected AutoCompleteSettings settings = new AutoCompleteSettings(); > So, this.settings has default value. > In AutoCompleteBehavior constructor, a new AutoCompleteSettings is created if > the > settings constructor parameter is null and is used to re-set the settings > instance variable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3226) NavigationToolbar has table instance variable but so does base-class AbstractToolbar
[ https://issues.apache.org/jira/browse/WICKET-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967053#action_12967053 ] Hudson commented on WICKET-3226: Integrated in Apache Wicket 1.4.x #311 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/311/]) > NavigationToolbar has table instance variable but so does base-class > AbstractToolbar > > > Key: WICKET-3226 > URL: https://issues.apache.org/jira/browse/WICKET-3226 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5-M3 > Environment: all >Reporter: Richard Emberson >Assignee: Pedro Santos >Priority: Trivial > Fix For: 1.4.15, 1.5-M4 > > > The class NavigationToolbar has > DataTable[_] table > as instance variable but also passes the same table to the base-class > AbstractToolbar > which has a protected method > getTable which returns the same table. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2279) Losing focus on Autocomplete field if DropDownChoice is updated using Ajax.
[ https://issues.apache.org/jira/browse/WICKET-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966750#action_12966750 ] Hudson commented on WICKET-2279: Integrated in Apache Wicket 1.4.x #308 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/308/]) > Losing focus on Autocomplete field if DropDownChoice is updated using Ajax. > --- > > Key: WICKET-2279 > URL: https://issues.apache.org/jira/browse/WICKET-2279 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4-RC2, 1.4-RC4 > Environment: Error exposed in IE 6, 7, 8. > Works in Firefox, Chrome. >Reporter: Aslak Knutsen >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.11 > > Attachments: AutoCompleteFocusIssuePage.html, > AutoCompleteFocusIssuePage.java > > > It seems that if a DropDownChoice is updated with ajax, the next AutoComplete > field will lose focus when triggered if the > updated DropDownChoice have had focus inbetween beeing updated and > AutoComplete is triggered. > But only if focus on the DropDownChoice is gained/lost using KEY_TAB. > More description in the attached example.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3215) AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8
[ https://issues.apache.org/jira/browse/WICKET-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966749#action_12966749 ] Hudson commented on WICKET-3215: Integrated in Apache Wicket 1.4.x #308 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/308/]) > AutoCompleteTextField does not work in an iframe under IE 6, 7 or 8 > --- > > Key: WICKET-3215 > URL: https://issues.apache.org/jira/browse/WICKET-3215 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.11, 1.4.12, 1.4.13, 1.4.14 > Environment: Windows Server 2003 >Reporter: Robert Csok >Assignee: Pedro Santos > Fix For: 1.4.15, 1.5-M4 > > Attachments: HomePage.html, HomePage.java, iframe.html > > > The code that has been integrated in version > 1.4.11 to fix issue WICKET-2279 forces the cursor of an > AutoCompleteTextField to do a "carriage return" after each typed in char when > the application runs in an iframe and IE 6, 7 or 8 is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3196) UrlValidator failes to validate urls that containt multiple dots in path
[ https://issues.apache.org/jira/browse/WICKET-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964613#action_12964613 ] Hudson commented on WICKET-3196: Integrated in Apache Wicket 1.4.x #299 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/299/]) > UrlValidator failes to validate urls that containt multiple dots in path > > > Key: WICKET-3196 > URL: https://issues.apache.org/jira/browse/WICKET-3196 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.9 > Environment: Linux, Tomcat >Reporter: Ivan Zinchenko >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.15, 1.5-M4 > > > refer to UrlValidator.java:466 (isValidPath). > if we have an url, that contains more than two consequent dots, for example > "http://www.somedomain.com/this_one_is_tricky...but...still.valid";, > validator will fail. > btw, the other side effect is that countTokens actually counts '...' a two > 2dots. > One possible workaround is not just count '..' tokens, but count them along > with slash, like '../'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3154) test for undefined in the same manner throughtout the code.
[ https://issues.apache.org/jira/browse/WICKET-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964532#action_12964532 ] Hudson commented on WICKET-3154: Integrated in Apache Wicket 1.4.x #297 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/297/]) WICKET-3154 test for undefined in the same manner throughtout the code. Always use 'typeof(xyz) "undefined"'. It is more safe then using 'xyz undefined' because window.undefined can be overwritten by buggy/malicious code. > test for undefined in the same manner throughtout the code. > > > Key: WICKET-3154 > URL: https://issues.apache.org/jira/browse/WICKET-3154 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.4.13 >Reporter: Rodolfo Hansen >Priority: Trivial > Fix For: 1.4.15, 1.5-M4 > > Attachments: modal-undefined.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > testing whether a variable is undefined should be done in a similar manner > throughout a file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3184) Make method getContentId of ModalWindow static
[ https://issues.apache.org/jira/browse/WICKET-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964533#action_12964533 ] Hudson commented on WICKET-3184: Integrated in Apache Wicket 1.4.x #297 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/297/]) WICKET-3184 Make method getContentId of ModalWindow static Introduce ModalWindow#CONTENT_ID public constant which is used as default id for the content component > Make method getContentId of ModalWindow static > -- > > Key: WICKET-3184 > URL: https://issues.apache.org/jira/browse/WICKET-3184 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Reporter: Vitaly Tsaplin >Assignee: Martin Grigorov >Priority: Minor > Fix For: 1.4.15, 1.5-M4 > > > My proposal is to make the method getContentId of the class ModalWindow > STATIC to simplify a creation of the panel class that would serve as a base > class for content components. It's always necessary to specify a content ID > when we create a component which can be added as a window component. This > content ID can be obtained only from an instance of the modal window which > often is not convenient neither neccesary since it's just a constant kept in > sync with the id in the window markup. Also there is no obvious reason to > override this method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3181) UploadProgressBar does not show up on nested forms
[ https://issues.apache.org/jira/browse/WICKET-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964474#action_12964474 ] Hudson commented on WICKET-3181: Integrated in Apache Wicket 1.4.x #295 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/295/]) > UploadProgressBar does not show up on nested forms > -- > > Key: WICKET-3181 > URL: https://issues.apache.org/jira/browse/WICKET-3181 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13 > Environment: Java 6, Tomcat 6 >Reporter: Alec Swan >Assignee: Igor Vaynberg > Fix For: 1.4.14, 1.5-M4 > > Attachments: wicket.zip > > > UploadProgressBar implementation adds onsubmit event handler on the form the > bar is associated with. However, if the form is nested in another form, then > Wicket replaces the inner form with a . A DIV does not support onsubmit > event handler which prevents the progress bar from showing up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3136) JVM 1.6 crash caused by WicketObjectOutputStream, ClassStreamHandler, and Page.writePageObject
[ https://issues.apache.org/jira/browse/WICKET-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964473#action_12964473 ] Hudson commented on WICKET-3136: Integrated in Apache Wicket 1.4.x #295 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/295/]) > JVM 1.6 crash caused by WicketObjectOutputStream, ClassStreamHandler, and > Page.writePageObject > --- > > Key: WICKET-3136 > URL: https://issues.apache.org/jira/browse/WICKET-3136 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.12 > Environment: JVM 1.6.0_22, CentOS release 5.3 (Final) and Mac OS > 10.6.4 >Reporter: Roland Groen >Assignee: Johan Compagner > Fix For: 1.4.14 > > Attachments: fix-test-WICKET-3136.patch, hs_err_pid3145.log, > test-WICKET-3136.patch > > > The JVM 6u22 (1.6.0_22) crashes while clicking on a page in the wicket > application. This is always the same page, but there are pages that function. > When serializing a Page object with the pageMapName field set, a JVM 1.6 > crashes on a segmentation fault. The error message is: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xf44a859e, pid=3145, tid=2969234320 > # > # JRE version: 6.0_22-b04 > # Java VM: Java HotSpot(TM) Server VM (17.1-b03 mixed mode linux-x86 ) > # Problematic frame: > # J > org.apache.wicket.util.io.WicketObjectOutputStream$HandleTable.hash(Ljava/lang/Object;)I > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > What goes on (and it took some time to find it): > The WicketObjectOutputStream has a field wich is called classHandler. This > classHandler is suppose to match the class of the curObject. > When Page.writePageObject is called AND the field Page.pageMapName is set, > the method Page.writePageObject will call writeObject(pageMapName). This > call will change the value of WicketObjectOutputStream.classHandler into the > classHandler of java.lang.String somewhere in > WicketObjectOutputStream.writeObjectOverride. What happens next is a true > disaster. Though some abstractions (PageSerializer), the method > WicketObjectOutputStream.defaultWriteObject will is called. This method > states: > classHandler.writeFields(this, curObject); > and due to fact that classHandler is a class handler of java.lang.String and > not the one of the curObject, an instance of FieldAndIndex belonging to > String.value will be called with another object. This ends up at calling > unsafe.getObject(object, index) (a native method) with the wrong object > reference, something which is not a good idea with sun.misc.Unsafe. Every > operation on the returned object will crash the JVM. Unfortunately the next > in line to operate on the object is WicketObjectOutputStream.HandleTable.hash > which also calls a native method called System.identityHashCode. This method > is known for some JVM crashes, and has been attributed for the JVM crash for > a while during the investigation into this JVM crash. > The solutions: > 1) Do not use the WicketObjectOutputStream/WicketObjectStreamFactory. Works. > 2) The method org.apache.wicket.Page.writePageObject(ObjectOutputStream) > should not do a s.writeObject(pageMapName), but a s.writeUTF(pageMapName) > instead. This way, the WicketObjectOutputStream.classHandler will not get the > wrong value. org.apache.wicket.Page.readPageObject(ObjectInputStream) should > be matched, of course. > 3) WicketObjectOutputStream.defaultWriteObject() should update/get the right > classHandler reference, just as > WicketObjectOutputStream.writeObjectOverride(Object) does. You might even > consider dropping the field entirely. > The last option seems the best to me, because calling a writeObject from > writePageObject is not semantically incorrect, furthermore, there might be > other instances of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3156) Submitting button of a multiple-button form is not resolved correctly
[ https://issues.apache.org/jira/browse/WICKET-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964472#action_12964472 ] Hudson commented on WICKET-3156: Integrated in Apache Wicket 1.4.x #295 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/295/]) > Submitting button of a multiple-button form is not resolved correctly > - > > Key: WICKET-3156 > URL: https://issues.apache.org/jira/browse/WICKET-3156 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Ivan Vasilev >Assignee: Igor Vaynberg > Attachments: test-WICKET-3156.patch > > > This bug affects Form.findSubmittingButton(). > Inside it all the form submitting children of the page are visited. A check > is made whether the current form submitting component is a child of the > current form. > If so another check is performed: > if ((!parameters.getParameterValue(name).isNull()) || > !parameters.getParameterValue(name + ".x").isNull()) > I saw that in case of a button the condition > !parameters.getParameterValue(name).isNull()) is true (returns the "value" > attribute of the button), so the button can be considered the submitting > component of the form. > However if there are multiple buttons in the form in this case the first > visited button will be returned, which is not necessary the one that actually > submitted the form. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3169) Parametrize IFilterStateLocator
[ https://issues.apache.org/jira/browse/WICKET-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934334#action_12934334 ] Hudson commented on WICKET-3169: Integrated in Apache Wicket 1.4.x #283 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/283/]) WICKET-3169 Parametrize IFilterStateLocator Add generics to o.a.w.extensions.markup.html.repeater.data.table.filter merge r1037520 from 1.5.x > Parametrize IFilterStateLocator > --- > > Key: WICKET-3169 > URL: https://issues.apache.org/jira/browse/WICKET-3169 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.4.13 >Reporter: Marek Šabo >Assignee: Martin Grigorov >Priority: Minor > Fix For: 1.4.14, 1.5-M4 > > Attachments: IFilterStateLocator.java, WICKET-3169.patch > > > Interface > org.apache.wicket.extensions.markup.html.repeater.data.table.filter.IFilterStateLocator > contains methods which work with Object types. It may be a good improvement > to parametrize this interface with type much like the IModel interface > in order to introduce type-safety and avoid casting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3152) Wicket tester should allow testing for enabled/disabled status and for fields being required.
[ https://issues.apache.org/jira/browse/WICKET-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934261#action_12934261 ] Hudson commented on WICKET-3152: Integrated in Apache Wicket 1.4.x #282 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/282/]) WICKET-3152 Wicket tester should allow testing for enabled/disabled status and for fields being required. Add assertions for enabled/disabled component and required form component merge r1037420 from trunk (1.5.x) > Wicket tester should allow testing for enabled/disabled status and for fields > being required. > - > > Key: WICKET-3152 > URL: https://issues.apache.org/jira/browse/WICKET-3152 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.12, 1.4.13 >Reporter: Michiel Leegwater >Assignee: Martin Grigorov >Priority: Minor > Fix For: 1.4.14, 1.5-M4 > > Attachments: patch.txt > > > assertVisible is present, but assertEnabled is not. Likewise for > assertDisabled and assertRequired. Refer to patch which will be attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3164) executeAjaxEvent in WicketTester works although Component is not enabled
[ https://issues.apache.org/jira/browse/WICKET-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934254#action_12934254 ] Hudson commented on WICKET-3164: Integrated in Apache Wicket 1.5.x #539 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/539/]) WICKET-3164 executeAjaxEvent in WicketTester works although Component is not enabled Add additional checks for 'enabled' and 'visible' component before executing WicketTester's #executeAllTimerBehaviors() and #submitAjaxFormSubmitBehavior() merge r1037409 from 1.4.x > executeAjaxEvent in WicketTester works although Component is not enabled > > > Key: WICKET-3164 > URL: https://issues.apache.org/jira/browse/WICKET-3164 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.10 >Reporter: Frank Klein Koerkamp >Assignee: Martin Grigorov > Fix For: 1.4.14, 1.5-M4 > > > When Component is disabled the executeAjaxEvent still works. Because it's not > checking if Component is enabled. > But the event attribute is not rendered to the component if it's disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3164) executeAjaxEvent in WicketTester works although Component is not enabled
[ https://issues.apache.org/jira/browse/WICKET-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934252#action_12934252 ] Hudson commented on WICKET-3164: Integrated in Apache Wicket 1.4.x #281 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/281/]) WICKET-3164 executeAjaxEvent in WicketTester works although Component is not enabled Add additional checks for 'enabled' and 'visible' component before executing WicketTester's #executeAllTimerBehaviors() and #submitAjaxFormSubmitBehavior() > executeAjaxEvent in WicketTester works although Component is not enabled > > > Key: WICKET-3164 > URL: https://issues.apache.org/jira/browse/WICKET-3164 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.10 >Reporter: Frank Klein Koerkamp >Assignee: Martin Grigorov > Fix For: 1.4.14, 1.5-M4 > > > When Component is disabled the executeAjaxEvent still works. Because it's not > checking if Component is enabled. > But the event attribute is not rendered to the component if it's disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3167) Strange IResourceStream type hierarchy
[ https://issues.apache.org/jira/browse/WICKET-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934212#action_12934212 ] Hudson commented on WICKET-3167: Integrated in Apache Wicket 1.4.x #280 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/280/]) > Strange IResourceStream type hierarchy > -- > > Key: WICKET-3167 > URL: https://issues.apache.org/jira/browse/WICKET-3167 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Juergen Donnerstag >Assignee: Peter Ertl >Priority: Minor > > Current type hierarchy looks like > IResourceStream > IStringResourceStream > AbstractResourceStream > AbstractStringResourceStream > It propobly should rather be > IResourceStream > AbstractResourceStream > IStringResourceStream > AbstractStringResourceStream -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1945) make wicket's configuration type an enum
[
https://issues.apache.org/jira/browse/WICKET-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934173#action_12934173
]
Hudson commented on WICKET-1945:
Integrated in Apache Wicket 1.5.x #536 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/536/])
fixed WICKET-1945 make wicket's configuration type an enum
Issue: WICKET-1945
> make wicket's configuration type an enum
>
>
> Key: WICKET-1945
> URL: https://issues.apache.org/jira/browse/WICKET-1945
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Reporter: Peter Ertl
>Assignee: Juergen Donnerstag
> Fix For: 1.5-M4
>
> Attachments: RuntimeConfigurationTypesEnum.patch
>
>
> I would suggest that (starting with wicket 1.5.x) the wicket configuration
> type should be converted to an enum.
> current:
> String org.apache.wicket.Application.getConfigurationType()
> future:
> ConfigurationType org.apache.wicket.Application.getConfigurationType()
>
> package org.apache.wicket;
> public enum ConfigurationType
> {
> DEVELOPMENT, DEPLOYMENT
> }
> enum have a lot of benefits, e.g. cover all cases in a case block or having
> no upper- or lower-case inconsistencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934164#action_12934164 ] Hudson commented on WICKET-1358: Integrated in Apache Wicket 1.5.x #535 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/535/]) fixed WICKET-1358 Make Application Class More Bean-ish Issue: WICKET-1358 > Make Application Class More Bean-ish > > > Key: WICKET-1358 > URL: https://issues.apache.org/jira/browse/WICKET-1358 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.1 >Reporter: James Carman >Assignee: Juergen Donnerstag > Fix For: 1.5-M4 > > Attachments: WICKET-1358.patch > > > The Application class has getters for properties like applicationSettings and > securitySettings. Couldn't we make those properties writable also? I > realize that the internal implementation might have to change a bit. > Currently, the Settings class implements all of those interfaces and it uses > a single instance of Settings by default. The reason that I want this is so > that I can set up my Application object in Spring and access it via > wicket-spring. The current implementation of Application doesn't facilitate > the "set up" part very well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3168) No Application in the thread when the web server destroys WicketFilter
[ https://issues.apache.org/jira/browse/WICKET-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934154#action_12934154 ] Hudson commented on WICKET-3168: Integrated in Apache Wicket 1.5.x #534 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/534/]) WICKET-3168 No Application in the thread when the web server destroys WicketFilter Set the current Application in the ThreadContext local during WicketFilter#destroy() call. This way all destroyable objects can use the application if they need it. > No Application in the thread when the web server destroys WicketFilter > -- > > Key: WICKET-3168 > URL: https://issues.apache.org/jira/browse/WICKET-3168 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Martin Grigorov >Assignee: Martin Grigorov > Fix For: 1.5-M4 > > Attachments: WICKET-3168.patch > > > Playing with Wicket 1.5 + Google AppEngine I saw this exception after > modifying appengine-web.xml: > WARNING: EXCEPTION > org.apache.wicket.WicketRuntimeException: There is no application attached to > current thread Timer-2 > at org.apache.wicket.Application.get(Application.java:250) > at org.apache.wicket.Session.get(Session.java:154) > at > org.apache.wicket.page.DefaultPageManagerContext.getSessionAttribute(DefaultPageManagerContext.java:63) > at > org.apache.wicket.pageStore.memory.HttpSessionDataStore.getPageTable(HttpSessionDataStore.java:130) > at > org.apache.wicket.pageStore.memory.HttpSessionDataStore.destroy(HttpSessionDataStore.java:116) > at > org.apache.wicket.pageStore.DefaultPageStore.destroy(DefaultPageStore.java:66) > at > org.apache.wicket.page.PersistentPageManager.destroy(PersistentPageManager.java:374) > at > org.apache.wicket.page.PageManagerDecorator.destroy(PageManagerDecorator.java:86) > at org.apache.wicket.Application.internalDestroy(Application.java:839) > at > org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:440) > at > org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:437) > at > org.mortbay.jetty.servlet.FilterHolder.destroyInstance(FilterHolder.java:127) > > I.e. the asynchronous thread that destroys WicketFilter has no ThreadContext > thread local and thus this exception. > I see two problems/solutions: > 1) HttpSessionDataStore should have noop #destroy() - the Application is > being destroyed, so all its http sessions will be deleted and there is no > need to clean the special attribute which stores session's pages > 2) WicketFilter#destroy() can set/unset the application in ThreadContext, so > other functionality in all #destroy() methods will have access to the > Application via Application.get() > Any objections ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3178) Correctness of tests is order dependent, ThreadContext.detach not always called
[
https://issues.apache.org/jira/browse/WICKET-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933641#action_12933641
]
Hudson commented on WICKET-3178:
Integrated in Apache Wicket 1.5.x #527 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/527/])
detach
Issue: WICKET-3178
> Correctness of tests is order dependent, ThreadContext.detach not always
> called
> ---
>
> Key: WICKET-3178
> URL: https://issues.apache.org/jira/browse/WICKET-3178
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: My own build env which uses Ant.
>Reporter: Richard Emberson
>Assignee: Igor Vaynberg
> Fix For: 1.5-M4
>
>
> I have my own build/test env for Wicket and the order in which tests are
> executed are not necessarily the same as the order that Maven drives
> the tests in the standard test env.
> If you can manage to run only the tests
> org.apache.wicket.request.cycle.RequestCycleListenerTest testBasicOperations
> followed by test
> org.apache.wicket.request.mapper.BasicResourceReferenceMapperTest testDecode1
> the BasicResourceReferenceMapperTest test will fail because it
> requires that the ThreadContext have NO application, but the
> RequestCycleListenerTest does not have a tearDown method
> that calls ThreadContext.detach (nor does it use the BaseWicketTester
> with its tearDown method) so it leaves an application in the ThreadContext.
> Also, BasicResourceReferenceMapperTest does not use the
> BaseWicketTester which calls detach in its constructor.
> The solution is to add the following to BasicResourceReferenceMapperTest
> protected void setUp() { org.apache.wicket.ThreadContext.detach(); }
> In my test env it is simply two lines in a property file to have only the
> above
> two tests execute (and in the order specified). Don't know how to do that in
> Maven.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3167) Strange IResourceStream type hierarchy
[ https://issues.apache.org/jira/browse/WICKET-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932820#action_12932820 ] Hudson commented on WICKET-3167: Integrated in Apache Wicket 1.5.x #524 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/524/]) > Strange IResourceStream type hierarchy > -- > > Key: WICKET-3167 > URL: https://issues.apache.org/jira/browse/WICKET-3167 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M3 >Reporter: Juergen Donnerstag >Assignee: Peter Ertl >Priority: Minor > > Current type hierarchy looks like > IResourceStream > IStringResourceStream > AbstractResourceStream > AbstractStringResourceStream > It propobly should rather be > IResourceStream > AbstractResourceStream > IStringResourceStream > AbstractStringResourceStream -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3068) remove application settings which are no longer needed
[ https://issues.apache.org/jira/browse/WICKET-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932821#action_12932821 ] Hudson commented on WICKET-3068: Integrated in Apache Wicket 1.5.x #524 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/524/]) > remove application settings which are no longer needed > -- > > Key: WICKET-3068 > URL: https://issues.apache.org/jira/browse/WICKET-3068 > Project: Wicket > Issue Type: Task >Affects Versions: 1.5-M2.1 >Reporter: Peter Ertl > > Remove all properties from org.apache.wicket.settings.Settings which are no > longer needed. Remove the methods in wicket-jmx as well. > Feel free to list obsolete properties here... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3173) Fix for WICKET-2903 causes NPE when HttpsConfig is intentionally null
[ https://issues.apache.org/jira/browse/WICKET-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932617#action_12932617 ] Hudson commented on WICKET-3173: Integrated in Apache Wicket 1.4.x #273 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/273/]) > Fix for WICKET-2903 causes NPE when HttpsConfig is intentionally null > - > > Key: WICKET-3173 > URL: https://issues.apache.org/jira/browse/WICKET-3173 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13, 1.5-M3 >Reporter: Brian Topping >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.14 > > Attachments: test-WICKET-3173.patch, WICKET-3173.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > The patch in WICKET-2903 is not as robust as it needs to be. Throughout the > code in HttpsRequestCycleProcessor.java, there are a number of conditionals > on whether portConfig is null, clearly making the null state an acceptable > value. But HttpsRequestCycleProcessor.resolve() now calls > portConfig.isPreferStateful() without first checking to see if the portConfig > is null. > For the interested, my application leaves portConfig set to null when I would > like to avoid a redirect to https, for instance in development on a machine > that does not have SSL set up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3174) SmartLinkLabel failing to process email with +
[ https://issues.apache.org/jira/browse/WICKET-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932616#action_12932616 ] Hudson commented on WICKET-3174: Integrated in Apache Wicket 1.4.x #273 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/273/]) > SmartLinkLabel failing to process email with + > -- > > Key: WICKET-3174 > URL: https://issues.apache.org/jira/browse/WICKET-3174 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.0 > Environment: Java 6, Tomcat 6 >Reporter: Brill Pappin >Assignee: Igor Vaynberg > Fix For: 1.4.14, 1.5-M4 > > Attachments: DefaultLinkParserEmailPlusTest.java > > Original Estimate: 1h > Remaining Estimate: 1h > > Using SmartLinkLabel with an email address that includes a "+" generates a > link only on the right-most part of the address. > Example: > - my+t...@example.com > Will generate a link like: > - my+mailto:t...@example.com";>t...@example.com@pappin.ca > THe addition of the "+" char is a valid email address format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3174) SmartLinkLabel failing to process email with +
[ https://issues.apache.org/jira/browse/WICKET-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932554#action_12932554 ] Hudson commented on WICKET-3174: Integrated in Apache Wicket 1.5.x #519 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/519/]) Issue: WICKET-3174 > SmartLinkLabel failing to process email with + > -- > > Key: WICKET-3174 > URL: https://issues.apache.org/jira/browse/WICKET-3174 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.0 > Environment: Java 6, Tomcat 6 >Reporter: Brill Pappin >Assignee: Igor Vaynberg > Fix For: 1.4.14, 1.5-M4 > > Attachments: DefaultLinkParserEmailPlusTest.java > > Original Estimate: 1h > Remaining Estimate: 1h > > Using SmartLinkLabel with an email address that includes a "+" generates a > link only on the right-most part of the address. > Example: > - my+t...@example.com > Will generate a link like: > - my+mailto:t...@example.com";>t...@example.com@pappin.ca > THe addition of the "+" char is a valid email address format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3170) ModalWindow moved event (besides resize)
[ https://issues.apache.org/jira/browse/WICKET-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932225#action_12932225 ] Hudson commented on WICKET-3170: Integrated in Apache Wicket 1.4.x #269 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/269/]) > ModalWindow moved event (besides resize) > > > Key: WICKET-3170 > URL: https://issues.apache.org/jira/browse/WICKET-3170 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.4.13, 1.5-M3 >Reporter: Johan Compagner > Fix For: 1.4.14 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3173) Fix for WICKET-2903 causes NPE when HttpsConfig is intentionally null
[ https://issues.apache.org/jira/browse/WICKET-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932224#action_12932224 ] Hudson commented on WICKET-3173: Integrated in Apache Wicket 1.4.x #269 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/269/]) Issue: WICKET-3173 > Fix for WICKET-2903 causes NPE when HttpsConfig is intentionally null > - > > Key: WICKET-3173 > URL: https://issues.apache.org/jira/browse/WICKET-3173 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.13 >Reporter: Brian Topping >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.14 > > Attachments: WICKET-3173.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > The patch in WICKET-2903 is not as robust as it needs to be. Throughout the > code in HttpsRequestCycleProcessor.java, there are a number of conditionals > on whether portConfig is null, clearly making the null state an acceptable > value. But HttpsRequestCycleProcessor.resolve() now calls > portConfig.isPreferStateful() without first checking to see if the portConfig > is null. > For the interested, my application leaves portConfig set to null when I would > like to avoid a redirect to https, for instance in development on a machine > that does not have SSL set up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3166) isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?
[
https://issues.apache.org/jira/browse/WICKET-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931959#action_12931959
]
Hudson commented on WICKET-3166:
Integrated in Apache Wicket 1.5.x #517 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/517/])
meh. this caching will probably slow things down. and it can be difficult
to find all the places in code where caching should be invalidated. lets hold
off until it is a hotspot.
Issue: WICKET-3166
caching for isVisibleInHieararchy
Issue: WICKET-3166
> isVisibleInHierarchy() possibly unnecessarily checks children whose parents
> are invisible?
> --
>
> Key: WICKET-3166
> URL: https://issues.apache.org/jira/browse/WICKET-3166
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.4.13
>Reporter: Martin Makundi
>Assignee: Igor Vaynberg
> Fix For: 1.4.14, 1.5-M4
>
> Attachments: diff.txt, Wicket-Quickstart.zip
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Hi!
> See attached quickstart with junit test reproducing the bug. See also patch
> proposal.
> I have a page with two panels:
> page.form.add(panel1);
> page.form.add(panel2);
> in some situations panel1 is not visible.
> However, a form submit event will visit all formcomponents of panel1 via:
>at
> org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
>at
> org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
>at org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
>at
> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)
> This results in a crash because panel1 components are not prepared to
> be invoked via isvisible when the panel itself is not visible.
> I wonder if the component.isVisibleInHierarchy could be changed as
> follows, to first check parent visibility:
> public final boolean isVisibleInHierarchy()
> {
>Component component = this;
>while (component != null)
>{
> Component componentParent = component.getParent();
> if (((componentParent == null) ||
> componentParent.isVisibleInHierarchy()) &&
> component.determineVisibility())
> {
>component = componentParent;
> }
> else
> {
>return false;
> }
>}
>return true;
> }
> Similar change could/should maybe be possible also for isEnabledInHierarchy ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3166) isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?
[
https://issues.apache.org/jira/browse/WICKET-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931954#action_12931954
]
Hudson commented on WICKET-3166:
Integrated in Apache Wicket 1.4.x #267 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/267/])
meh. this caching will probably slow things down. and it can be difficult
to find all the places in code where caching should be invalidated. lets hold
off until it is a hotspot.
Issue: WICKET-3166
caching for isVisibleInHieararchy()
Issue: WICKET-3166
> isVisibleInHierarchy() possibly unnecessarily checks children whose parents
> are invisible?
> --
>
> Key: WICKET-3166
> URL: https://issues.apache.org/jira/browse/WICKET-3166
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.4.13
>Reporter: Martin Makundi
>Assignee: Igor Vaynberg
> Fix For: 1.4.14, 1.5-M4
>
> Attachments: diff.txt, Wicket-Quickstart.zip
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Hi!
> See attached quickstart with junit test reproducing the bug. See also patch
> proposal.
> I have a page with two panels:
> page.form.add(panel1);
> page.form.add(panel2);
> in some situations panel1 is not visible.
> However, a form submit event will visit all formcomponents of panel1 via:
>at
> org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
>at
> org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
>at org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
>at
> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)
> This results in a crash because panel1 components are not prepared to
> be invoked via isvisible when the panel itself is not visible.
> I wonder if the component.isVisibleInHierarchy could be changed as
> follows, to first check parent visibility:
> public final boolean isVisibleInHierarchy()
> {
>Component component = this;
>while (component != null)
>{
> Component componentParent = component.getParent();
> if (((componentParent == null) ||
> componentParent.isVisibleInHierarchy()) &&
> component.determineVisibility())
> {
>component = componentParent;
> }
> else
> {
>return false;
> }
>}
>return true;
> }
> Similar change could/should maybe be possible also for isEnabledInHierarchy ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1568) contribution for wicket 1.5 generics (IConverter)
[
https://issues.apache.org/jira/browse/WICKET-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931942#action_12931942
]
Hudson commented on WICKET-1568:
Integrated in Apache Wicket 1.5.x #516 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/516/])
> contribution for wicket 1.5 generics (IConverter)
> -
>
> Key: WICKET-1568
> URL: https://issues.apache.org/jira/browse/WICKET-1568
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4-M1, 1.5-M3
>Reporter: Peter Ertl
>Assignee: Martin Grigorov
> Fix For: 1.4-M2, 1.5-M4
>
> Attachments: converter.patch, WICKET-1568.patch
>
>
> I think it will be straightforward to let the converter of a component handle
> the same type that the component itself uses
> --
> public class MyMoneyTextField extends TextField
> {
> public MyMoneyTextField(final String id, final IModel model)
> {
> super(id, model);
> }
> // ...
>
> @Override
> public IConverter getConverter(final Class type)
> {
> // no ugly casts here anymore :-)
> //
> return new IConverter()
> {
> public BigDecimal convertToObject(final String value, final Locale
> locale)
> {
> // ...
> }
> public String convertToString(final BigDecimal value, final Locale
> locale)
> {
> // ...
> }
> };
> }
> }
> I attached a patch that implements this change and ask you to take a look at
> and integrate it if you consider it right and helpful.
> Best regards
> Peter
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3164) executeAjaxEvent in WicketTester works although Component is not enabled
[ https://issues.apache.org/jira/browse/WICKET-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931943#action_12931943 ] Hudson commented on WICKET-3164: Integrated in Apache Wicket 1.5.x #516 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/516/]) > executeAjaxEvent in WicketTester works although Component is not enabled > > > Key: WICKET-3164 > URL: https://issues.apache.org/jira/browse/WICKET-3164 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.10 >Reporter: Frank Klein Koerkamp >Assignee: Martin Grigorov > Fix For: 1.4.14, 1.5-M4 > > > When Component is disabled the executeAjaxEvent still works. Because it's not > checking if Component is enabled. > But the event attribute is not rendered to the component if it's disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3080) Automatic sizing modal window
[ https://issues.apache.org/jira/browse/WICKET-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931941#action_12931941 ] Hudson commented on WICKET-3080: Integrated in Apache Wicket 1.5.x #516 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/516/]) > Automatic sizing modal window > - > > Key: WICKET-3080 > URL: https://issues.apache.org/jira/browse/WICKET-3080 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Reporter: Andera Del Bene >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.5-M3 > > Attachments: FeatureQuickStart.zip, fix-WICKET-1.4.x.patch, > fix-WICKET-javadoc.patch > > > As default ModalWindow should automatically resizing itself in order to fit > content's width and height. This should avoid manual size tuning. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3108) Problems with page maps stored in session
[ https://issues.apache.org/jira/browse/WICKET-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931936#action_12931936 ] Hudson commented on WICKET-3108: Integrated in Apache Wicket 1.4.x #266 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/266/]) > Problems with page maps stored in session > - > > Key: WICKET-3108 > URL: https://issues.apache.org/jira/browse/WICKET-3108 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.12 >Reporter: Jeremy Thomerson >Assignee: Jeremy Thomerson >Priority: Minor > Fix For: 1.4.13 > > Attachments: fix-WICKET-3108-memory-leak.patch, > pagemapstuff-quickstart.tar.gz, patch.txt, patch.txt, problem-1.patch, > problem-2.patch, problem-3.patch, test.patch > > > A client engaged me to assist in fixing multiple problems they found while > writing a custom page map eviction strategy for page maps that have not been > accessed in a while. Digging into the first problem revealed a few others. > I'd like someone who is more familiar than me with the session and page map > stuff to review this before I commit it. The quick start attached > demonstrates the problems. I have yet to write test cases that can be added > to the suite to replicate these issues. > PROBLEM 1: > If you call IPageMap.remove(), the page map is not actually removed because > it's in the dirty objects list, which means that it gets set back on the > session in the requestDetached() method. The quickstart demonstrates this in > a link for ease of demonstration, but in reality, it applies even if someone > is doing custom page map eviction in their request cycle somewhere. > PROBLEM 2: > It seems to be a safe assumption that every page map that is used in the > session should also be in usedPageMaps, and that this map should always be > exactly in sync with what's actually in your session (as attributes). Right > now, they are not in sync. First, the default page map was not added to > usedPageMaps in the dirtyPageMap(IPageMap) method. Second, when page maps > are created, they are not dirtied (which means they are not in the > usedPageMaps collection), although they are set as attributes on the session > immediately. This causes a problem in the newPageMap(String) method with > actually adhering to the max number you set. > PROBLEM 3: > If you have a bunch of popup links on a page, they can create more page maps > than are allowed, and the number of page maps stored in the session grows > beyond the limit of what you've specified. The real unanswered question I > have is this: must we really create the page map when the link is first > rendered? Or could we wait until it is clicked? > NOTE: the fix for problems 2 and 3 relies on the fix for problem 1 being > committed, because the call to pm.remove() in newPageMap(IPageMap) will not > work without the fix for problem 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3164) executeAjaxEvent in WicketTester works although Component is not enabled
[ https://issues.apache.org/jira/browse/WICKET-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931935#action_12931935 ] Hudson commented on WICKET-3164: Integrated in Apache Wicket 1.4.x #266 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/266/]) > executeAjaxEvent in WicketTester works although Component is not enabled > > > Key: WICKET-3164 > URL: https://issues.apache.org/jira/browse/WICKET-3164 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.10 >Reporter: Frank Klein Koerkamp >Assignee: Martin Grigorov > Fix For: 1.4.14, 1.5-M4 > > > When Component is disabled the executeAjaxEvent still works. Because it's not > checking if Component is enabled. > But the event attribute is not rendered to the component if it's disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3166) isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?
[
https://issues.apache.org/jira/browse/WICKET-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931934#action_12931934
]
Hudson commented on WICKET-3166:
Integrated in Apache Wicket 1.4.x #266 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/266/])
> isVisibleInHierarchy() possibly unnecessarily checks children whose parents
> are invisible?
> --
>
> Key: WICKET-3166
> URL: https://issues.apache.org/jira/browse/WICKET-3166
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.4.13
>Reporter: Martin Makundi
>Assignee: Igor Vaynberg
> Fix For: 1.4.14, 1.5-M4
>
> Attachments: diff.txt, Wicket-Quickstart.zip
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Hi!
> See attached quickstart with junit test reproducing the bug. See also patch
> proposal.
> I have a page with two panels:
> page.form.add(panel1);
> page.form.add(panel2);
> in some situations panel1 is not visible.
> However, a form submit event will visit all formcomponents of panel1 via:
>at
> org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
>at
> org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
>at org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
>at
> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)
> This results in a crash because panel1 components are not prepared to
> be invoked via isvisible when the panel itself is not visible.
> I wonder if the component.isVisibleInHierarchy could be changed as
> follows, to first check parent visibility:
> public final boolean isVisibleInHierarchy()
> {
>Component component = this;
>while (component != null)
>{
> Component componentParent = component.getParent();
> if (((componentParent == null) ||
> componentParent.isVisibleInHierarchy()) &&
> component.determineVisibility())
> {
>component = componentParent;
> }
> else
> {
>return false;
> }
>}
>return true;
> }
> Similar change could/should maybe be possible also for isEnabledInHierarchy ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3155) Stateless forms don't work when using UrlCompressingWebRequestProcessor
[
https://issues.apache.org/jira/browse/WICKET-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931933#action_12931933
]
Hudson commented on WICKET-3155:
Integrated in Apache Wicket 1.4.x #266 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.4.x/266/])
> Stateless forms don't work when using UrlCompressingWebRequestProcessor
> ---
>
> Key: WICKET-3155
> URL: https://issues.apache.org/jira/browse/WICKET-3155
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.12
>Reporter: Arnout Engelen
>Assignee: Igor Vaynberg
> Attachments: fix-WICKET-3155.patch, test-WICKET-3155.patch
>
>
> When my Application has:
> @Override
> protected IRequestCycleProcessor newRequestCycleProcessor()
> {
> return new UrlCompressingWebRequestProcessor();
> }
> This breaks submitting a stateless form:
> WicketMessage: unable to find component with path 1 on stateless page [Page
> class = nl.topicuszorg.ksyos.txcs.web.TxcsUzipasLoginPage, id = 4, version =
> 0] it could be that the component is inside a repeater make your component
> return false in getStatelessHint()
> Root cause:
> org.apache.wicket.WicketRuntimeException: unable to find component with path
> 1 on stateless page [Page class =
> nl.topicuszorg.ksyos.txcs.web.TxcsUzipasLoginPage, id = 4, version = 0] it
> could be that the component is inside a repeater make your component return
> false in getStatelessHint()
> at
> org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:148)
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
> at
> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
> 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:727)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
> at
> org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
> at nl.topicuszorg.wicket.filter.CacheFilter.doFilter(CacheFilter.java:96)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
> at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3138) Wicket 1.5 and GAE
[ https://issues.apache.org/jira/browse/WICKET-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931814#action_12931814 ] Hudson commented on WICKET-3138: Integrated in Apache Wicket 1.5.x #513 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/513/]) WICKET-3138 Wicket 1.5 and GAE support PageNumberEvictionStrategy allows only positive number of pages > Wicket 1.5 and GAE > -- > > Key: WICKET-3138 > URL: https://issues.apache.org/jira/browse/WICKET-3138 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.5-M2.1 >Reporter: Alexandru Objelean >Assignee: Martin Grigorov > Fix For: 1.5-M4 > > > Create a http session based store to make wicket 1.5 work with GAE -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2713) Locate .properties files using the same convention as markup files
[ https://issues.apache.org/jira/browse/WICKET-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931805#action_12931805 ] Hudson commented on WICKET-2713: Integrated in Apache Wicket 1.5.x #511 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/511/]) fixed WICKET-2713 Locate .properties files using the same convention as markup files and some minor cleanup Issue: WICKET-2713 > Locate .properties files using the same convention as markup files > -- > > Key: WICKET-2713 > URL: https://issues.apache.org/jira/browse/WICKET-2713 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Peter Swulius >Assignee: Juergen Donnerstag >Priority: Minor > Fix For: 1.5-M4 > > > original inquiry on mailing list > http://www.mail-archive.com/us...@wicket.apache.org/msg47803.html > -- > I am curious. Why are .properties files not located in the same way as > .html? I've overridden: > [ResourceStreamLocator] > public IResourceStream locate( Class clazz, String aPath, String aStyle, > Locale aLocale, String anExtension ) > I notice that property file locating doesn't invoke this method, but only > invokes the lesser arg version with the style/variation/locale already > embedded in the path. This is an inconvenience for me because I'm trying to > inspect the style during location. Perhaps I shouldn't be doing what I'm > trying to do, but after reading the docs, I expected locating to work the way > it does for .html, but .properties threw me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3161) Can not create cookies
[
https://issues.apache.org/jira/browse/WICKET-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931804#action_12931804
]
Hudson commented on WICKET-3161:
Integrated in Apache Wicket 1.5.x #511 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/511/])
> Can not create cookies
> --
>
> Key: WICKET-3161
> URL: https://issues.apache.org/jira/browse/WICKET-3161
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: Windows 7, Intel i7
>Reporter: Ivaylo Stoykov
>Assignee: Peter Ertl
> Fix For: 1.5-M4
>
> Attachments: quickstart.zip
>
>
> Hi,
> I'm migrating to wicket 1.5-M3 and I've encountered a problem. I can not
> create cookies (I presume that I can't delete them either).
> I've looked through the source code and this is what I found:
> I add the cookie to the response and I end up with a nice
> HeaderBufferingWebResponse which contains BufferedWebResponse$AddCookieAction.
> But then redirectTo(Url, RequestCycle) from WebPageRenderer class is called.
> Here is the method:
>
>private void redirectTo(Url url, RequestCycle requestCycle)
> {
> WebResponse response = (WebResponse)requestCycle.getResponse();
> String relativeUrl =
> requestCycle.getUrlRenderer().renderUrl(url);
> response.reset();
> response.sendRedirect(relativeUrl);
> }
> response.reset(); - removes all actions from the request.
> So after this method my request has got only
> BufferedWebResponse$SendRedirectAction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3166) isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?
[
https://issues.apache.org/jira/browse/WICKET-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931803#action_12931803
]
Hudson commented on WICKET-3166:
Integrated in Apache Wicket 1.5.x #511 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/511/])
> isVisibleInHierarchy() possibly unnecessarily checks children whose parents
> are invisible?
> --
>
> Key: WICKET-3166
> URL: https://issues.apache.org/jira/browse/WICKET-3166
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.4.13
>Reporter: Martin Makundi
>Assignee: Igor Vaynberg
> Fix For: 1.4.14, 1.5-M4
>
> Attachments: diff.txt, Wicket-Quickstart.zip
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Hi!
> See attached quickstart with junit test reproducing the bug. See also patch
> proposal.
> I have a page with two panels:
> page.form.add(panel1);
> page.form.add(panel2);
> in some situations panel1 is not visible.
> However, a form submit event will visit all formcomponents of panel1 via:
>at
> org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
>at
> org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
>at org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
>at
> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)
> This results in a crash because panel1 components are not prepared to
> be invoked via isvisible when the panel itself is not visible.
> I wonder if the component.isVisibleInHierarchy could be changed as
> follows, to first check parent visibility:
> public final boolean isVisibleInHierarchy()
> {
>Component component = this;
>while (component != null)
>{
> Component componentParent = component.getParent();
> if (((componentParent == null) ||
> componentParent.isVisibleInHierarchy()) &&
> component.determineVisibility())
> {
>component = componentParent;
> }
> else
> {
>return false;
> }
>}
>return true;
> }
> Similar change could/should maybe be possible also for isEnabledInHierarchy ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3163) support building wicket offline by resolving DTD references locally
[
https://issues.apache.org/jira/browse/WICKET-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931682#action_12931682
]
Hudson commented on WICKET-3163:
Integrated in Apache Wicket 1.5.x #508 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/508/])
WICKET-3163: support offline builds of wicket (avoid hitting java.sun.com
for lookup of web.xml 2.3 DTD)
> support building wicket offline by resolving DTD references locally
> ---
>
> Key: WICKET-3163
> URL: https://issues.apache.org/jira/browse/WICKET-3163
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.5-M3
>Reporter: Peter Ertl
>Assignee: Peter Ertl
> Fix For: 1.5-M4
>
> Attachments: local-lookup.patch, LocalEntityResolver.java
>
>
> Wicket developers, please give me some comment on this:
> Some wicket test cases parse XML which refers to an external DTD.
> An example is org.apache.wicket.protocol.http.WicketFilterTest
> It refers to org.apache.wicket.util.file.WebXmlFile will will parse a custom
> web.xml.
> The web.xml will make the parser to look up
> http://java.sun.com/dtd/web-app_2_3.dtd
> When building wicket offline this will cause a network error and the test
> will fail.
> I would like to add
> org.apache.wicket.util.xml.LocalEntityResolver
> which may contain a set of local entitites to avoid hitting the network.
> As wicket 1.5 is getting close to final I would like to get some feedback
> first before putting that into trunk...
> By adding this like to WebXmlFile network lookup would be avoided.
>
> DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
> DocumentBuilder builder = factory.newDocumentBuilder();
> builder.setEntityResolver(LocalEntityResolver.getDefault()); // no more
> network lookups
> Document document = builder.parse(is);
>
> package org.apache.wicket.util.xml;
> import org.apache.wicket.util.lang.Args;
> import org.xml.sax.EntityResolver;
> import org.xml.sax.InputSource;
> import org.xml.sax.SAXException;
> import javax.servlet.Filter;
> import java.io.IOException;
> import java.io.InputStream;
> import java.util.HashMap;
> import java.util.Map;
> /**
> * entity resolver that tries to locate a document type definition (DTD)
> using a set of custom entity resolvers
> *
> * @author pete
> */
> public class LocalEntityResolver implements EntityResolver
> {
> private final Map entities = new
> HashMap(3);
> public static LocalEntityResolver getDefault()
> {
> LocalEntityResolver resolver = new LocalEntityResolver();
>
> //
> // look up servlet 2.3 web.xml DTD right from inside servlet-api.jar
> //
> resolver.put(new EntityKey("-//Sun Microsystems, Inc.//DTD Web
> Application 2.3//EN",
>
> "http://java.sun.com/dtd/web-app_2_3.dtd";),
>new ServletApiEntityLocator("web-app_2_3.dtd"));
> return resolver;
> }
> public void put(EntityKey key, EntityLocator locator)
> {
> Args.notNull(key, "key");
> Args.notNull(locator, "locator");
> entities.put(key, locator);
> }
> public InputSource resolveEntity(String id, String url) throws
> SAXException, IOException
> {
> for (Map.Entry entry :
> entities.entrySet())
> if (entry.getKey().id.equals(id) ||
> entry.getKey().url.equals(url))
> return entry.getValue().locateInputSource();
> return null;
> }
> public static class EntityKey
> {
> private final String id;
> private final String url;
> private EntityKey(String id, String url)
> {
> Args.notEmpty(id, "id");
> Args.notEmpty(url, "url");
> this.id = id;
> this.url = url;
> }
> @Override
> public boolean equals(Object o)
> {
> if (this == o)
> return true;
> if (!(o instanceof EntityKey))
> return false;
> EntityKey key = (EntityKey) o;
> if (!id.equals(key.id))
> return false;
> return url.equals(key.url);
> }
> @Override
> public int hashCode()
> {
> int result = id.hashCode();
> result = 31 * result + url.hashCode(
[jira] Commented: (WICKET-3161) Can not create cookies
[
https://issues.apache.org/jira/browse/WICKET-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931671#action_12931671
]
Hudson commented on WICKET-3161:
Integrated in Apache Wicket 1.5.x #507 (See
[https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/507/])
WICKET-3161: added missing apache license headers
WICKET-3161: improve naming
WICKET-3161: added test case
WICKET-3161: cookies that are set during a buffered web response will not be
transferred over redirecting.
The solution to this issue is not what I consider pretty so please take time to
review and feel free to improve it.
Sorry for the last commit message (I intended to create a path but was clicking
too fast)
The previous commit is part of WICKET-3161
> Can not create cookies
> --
>
> Key: WICKET-3161
> URL: https://issues.apache.org/jira/browse/WICKET-3161
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5-M3
> Environment: Windows 7, Intel i7
>Reporter: Ivaylo Stoykov
>Assignee: Peter Ertl
> Fix For: 1.5-M4
>
> Attachments: quickstart.zip
>
>
> Hi,
> I'm migrating to wicket 1.5-M3 and I've encountered a problem. I can not
> create cookies (I presume that I can't delete them either).
> I've looked through the source code and this is what I found:
> I add the cookie to the response and I end up with a nice
> HeaderBufferingWebResponse which contains BufferedWebResponse$AddCookieAction.
> But then redirectTo(Url, RequestCycle) from WebPageRenderer class is called.
> Here is the method:
>
>private void redirectTo(Url url, RequestCycle requestCycle)
> {
> WebResponse response = (WebResponse)requestCycle.getResponse();
> String relativeUrl =
> requestCycle.getUrlRenderer().renderUrl(url);
> response.reset();
> response.sendRedirect(relativeUrl);
> }
> response.reset(); - removes all actions from the request.
> So after this method my request has got only
> BufferedWebResponse$SendRedirectAction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3149) Merge DecoratingHeaderResponse to trunk
[ https://issues.apache.org/jira/browse/WICKET-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931669#action_12931669 ] Hudson commented on WICKET-3149: Integrated in Apache Wicket 1.5.x #507 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/507/]) > Merge DecoratingHeaderResponse to trunk > --- > > Key: WICKET-3149 > URL: https://issues.apache.org/jira/browse/WICKET-3149 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5-M2.1 >Reporter: Martin Grigorov >Assignee: Jeremy Thomerson > Fix For: 1.5-M4 > > > Merge changes about DecoratingHeaderResponse to trunk. > Related SVN commits: > 1030625 > 1031154 > 1031432 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
