[jira] [Commented] (WICKET-4504) AjaxLazyLoadPanel not replaced within AjaxTabbedPanel
[ https://issues.apache.org/jira/browse/WICKET-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258340#comment-13258340 ] Martin Grigorov commented on WICKET-4504: - Thanks for the clarification! I just pushed a fix in 6.0-SNAPSHOT. Please test it and give feedback. Then I'll port it back to 1.5.x. > AjaxLazyLoadPanel not replaced within AjaxTabbedPanel > - > > Key: WICKET-4504 > URL: https://issues.apache.org/jira/browse/WICKET-4504 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 6.0.0-beta1 > Environment: JDK6 Linux x64 >Reporter: Timo Schmidt > Attachments: quickstart.zip > > > An AjaxLazyLoadPanel is not replaced when added as panel of an AbstractTab > within an AjaxTabbedPanel. > A set breakpoint in AjaxLazyLoadPanel constructor at > AbstractDefaultAjaxBehavior.respond method is never reached. > The attached quickstart will demonstrate the behavior. > This is reproducible with version 6.0.0-beta1 and 6.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4504) AjaxLazyLoadPanel not replaced within AjaxTabbedPanel
[ https://issues.apache.org/jira/browse/WICKET-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258314#comment-13258314 ] Martin Grigorov commented on WICKET-4504: - By using 6.0.0-beta1 all is fine even with Start.java (embedded Jetty). But even starting wicket-examples with StartExamples.java in 6.0-SNAPSHOT fails here. It could be something wrong in my IDE but could be another problem... > AjaxLazyLoadPanel not replaced within AjaxTabbedPanel > - > > Key: WICKET-4504 > URL: https://issues.apache.org/jira/browse/WICKET-4504 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 6.0.0-beta1 > Environment: JDK6 Linux x64 >Reporter: Timo Schmidt > Attachments: quickstart.zip > > > An AjaxLazyLoadPanel is not replaced when added as panel of an AbstractTab > within an AjaxTabbedPanel. > A set breakpoint in AjaxLazyLoadPanel constructor at > AbstractDefaultAjaxBehavior.respond method is never reached. > The attached quickstart will demonstrate the behavior. > This is reproducible with version 6.0.0-beta1 and 6.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4504) AjaxLazyLoadPanel not replaced within AjaxTabbedPanel
[ https://issues.apache.org/jira/browse/WICKET-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258305#comment-13258305 ] Martin Grigorov commented on WICKET-4504: - The app runs fine when run with 'mvn jetty:run' or deployed in web container. It fails only when started in embedded Jetty because Wicket Ajax resources (like wicket-ajax-jquery.js) cannot be found in the classpth for some reason. > AjaxLazyLoadPanel not replaced within AjaxTabbedPanel > - > > Key: WICKET-4504 > URL: https://issues.apache.org/jira/browse/WICKET-4504 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 6.0.0-beta1 > Environment: JDK6 Linux x64 >Reporter: Timo Schmidt > Attachments: quickstart.zip > > > An AjaxLazyLoadPanel is not replaced when added as panel of an AbstractTab > within an AjaxTabbedPanel. > A set breakpoint in AjaxLazyLoadPanel constructor at > AbstractDefaultAjaxBehavior.respond method is never reached. > The attached quickstart will demonstrate the behavior. > This is reproducible with version 6.0.0-beta1 and 6.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4506) Fix missing in 1.4.19, was fixed in 1.3.3: Discrepancy between Button implementation of getForm and the code in Form.findSubmittingButton()
[ https://issues.apache.org/jira/browse/WICKET-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258268#comment-13258268 ] Martin Grigorov commented on WICKET-4506: - Thanks for reporting this problem! 1.4.x is frozen and it receives only security related fixes. The fix will be committed only in 1.5.x and 6.x branches. > Fix missing in 1.4.19, was fixed in 1.3.3: Discrepancy between Button > implementation of getForm and the code in Form.findSubmittingButton() > > > Key: WICKET-4506 > URL: https://issues.apache.org/jira/browse/WICKET-4506 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.19 > Environment: Windows 7 > IE 8 > JDK 1.6 >Reporter: Irena Shaigorodsky > > There is a discrepancy between Button implementation of getForm (derived from > FromComponent) and the code in > org.apache.wicket.markup.html.form.Form.findSubmittingButton() > Last one assumes form can be null while > org.apache.wicket.markup.html.form.FormComponent.getForm() throws an > exception if it is so > This was fixed in 1.3.3 based on > https://issues.apache.org/jira/browse/WICKET-1414. Please migrate the fix to > 1.4 code line. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-2822) Small Bug in JavaDoc for SpringWebApplicationFactory
[ https://issues.apache.org/jira/browse/WICKET-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256481#comment-13256481 ] Martin Grigorov commented on WICKET-2822: - Fixed! Thanks! > Small Bug in JavaDoc for SpringWebApplicationFactory > > > Key: WICKET-2822 > URL: https://issues.apache.org/jira/browse/WICKET-2822 > Project: Wicket > Issue Type: Bug > Components: wicket-spring >Affects Versions: 1.4.7 >Reporter: count negative >Assignee: Igor Vaynberg >Priority: Minor > Fix For: 1.4.8 > > > Looking to the JavaDoc of SpringWebApplicationFactory in the filter config: > > applicationClassName > > org.apache.wicket.spring.SpringWebApplicationFactory > > It must be applicationFactoryClassName. When copy paste from the docu to > web.xml you'll se the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4502) Make it easier to produce a page with links with absolute urls
[ https://issues.apache.org/jira/browse/WICKET-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256407#comment-13256407 ] Martin Grigorov commented on WICKET-4502: - I don't like this approach because: 1) I'll have to find out how to implement "pageWithAbsoluteUrlsOnly()". Probably I'll need custom IRequestCycleListener to track the "target" page 2) IRequestMapper#mapHandler() is resposible to create the Urls. By using custom UrlRenderer I move this responsibility The simplest and cleanest solution for me is to remove 'final' from Url class. Then I can return my custom AbsoluteUrl in #mapHandler(). > Make it easier to produce a page with links with absolute urls > -- > > Key: WICKET-4502 > URL: https://issues.apache.org/jira/browse/WICKET-4502 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 >Reporter: Martin Grigorov > > We needed to create a page which links have absolute urls (protocol, host, > port included). So I created a simple extension of MountedMapper that makes > the relative url returned by super.mapHandler() to an absolute one. > So far so far but later Wicket uses > org.apache.wicket.request.UrlRenderer#shouldRenderAsFull() to decide whether > to actually render the url as full (i.e. as absolute) and since the protocol, > the host and the port matches with the current request's url attributes it > decides to render the url as relative. > Since Url class is final it is not possible to create a custom AbsoluteUrl > which #toString() delegates to #toString(StringMode.FULL). > I see two solutions: > 1) provide AbsoluteUrl class which is again final and uses StringMode.FULL > 2) add a boolean flag to Url that is used by UrlRenderer#shouldRenderAsFull() > so I can force full mode > Do you have other solutions ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-1175) IDataProvider-Overflow with size()
[ https://issues.apache.org/jira/browse/WICKET-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254779#comment-13254779 ] Martin Grigorov commented on WICKET-1175: - I meant Jesse's comment: https://issues.apache.org/jira/browse/WICKET-1175?focusedCommentId=13254549&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13254549 I'm not sure that I like the new noisier (more typing needed) approach better than the current need to down-cast from long to int. > IDataProvider-Overflow with size() > -- > > Key: WICKET-1175 > URL: https://issues.apache.org/jira/browse/WICKET-1175 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: any >Reporter: Jan Kriesten >Assignee: Igor Vaynberg > Fix For: 6.0.0-beta1 > > Attachments: 0001-Loop-should-not-use-long.patch > > > Hi, > I get an Integer-overflow with my Dataprovider (yeah, there are a couple of > entries in the database). Is there a reason why size() and iterator( first, > count ) are limited to Integer? > Regards, --- Jan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-1175) IDataProvider-Overflow with size()
[ https://issues.apache.org/jira/browse/WICKET-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254747#comment-13254747 ] Martin Grigorov commented on WICKET-1175: - Let me repeat Jesse: "O first" with "S size" where O is smaller than S is broken. How I can reach (O.max+1)th element ? It should be: iterator(S first, O count); S size(); > IDataProvider-Overflow with size() > -- > > Key: WICKET-1175 > URL: https://issues.apache.org/jira/browse/WICKET-1175 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: any >Reporter: Jan Kriesten >Assignee: Igor Vaynberg > Fix For: 6.0.0-beta1 > > Attachments: 0001-Loop-should-not-use-long.patch > > > Hi, > I get an Integer-overflow with my Dataprovider (yeah, there are a couple of > entries in the database). Is there a reason why size() and iterator( first, > count ) are limited to Integer? > Regards, --- Jan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4499) Pressing Enter in a Text Field invokes the default ( first) submit Button: Bug or Feature ?
[ https://issues.apache.org/jira/browse/WICKET-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254630#comment-13254630 ] Martin Grigorov commented on WICKET-4499: - With #setDefaultButton() you can set which button to be used as submitter if the user presses ENTER key in any text field. If you want to not submit at all when the user press ENTER then you need to add a JavaScript event listener (onkeydown, onkeyup) that checks the keyCode and do disables the default behavior when the key is ENTER (13). > Pressing Enter in a Text Field invokes the default ( first) submit Button: > Bug or Feature ? > > > Key: WICKET-4499 > URL: https://issues.apache.org/jira/browse/WICKET-4499 > Project: Wicket > Issue Type: Bug >Reporter: otto >Priority: Minor > Attachments: testCase1.zip > > > When entering a text in a Text field, the first found submit Listener is > executed. > This happens, when the form contains at least two Text Fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4499) Pressing Enter in a Text Field invokes the default ( first) submit Button: Bug or Feature ?
[ https://issues.apache.org/jira/browse/WICKET-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254612#comment-13254612 ] Martin Grigorov commented on WICKET-4499: - No problem! But you can use the users@ mailing lists or our IRC channel to ask questions and receive help faster. > Pressing Enter in a Text Field invokes the default ( first) submit Button: > Bug or Feature ? > > > Key: WICKET-4499 > URL: https://issues.apache.org/jira/browse/WICKET-4499 > Project: Wicket > Issue Type: Bug >Reporter: otto >Priority: Minor > Attachments: testCase1.zip > > > When entering a text in a Text field, the first found submit Listener is > executed. > This happens, when the form contains at least two Text Fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-1175) IDataProvider-Overflow with size()
[ https://issues.apache.org/jira/browse/WICKET-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254574#comment-13254574 ] Martin Grigorov commented on WICKET-1175: - Welcome to the Big Data era :-) I agree with Jesse - 'count' could be an 'int'. Another way is to change the API to: Iterator iterator(java.lang.Number first, java.lang.Number count); Number size(); This way we will leave the impl to decide whether to use an Int or a Long: first.longValue() , count.intValue(). Wicket core repeaters will use the 'long' view as they do now but custom components may use 'short' if they want. But this will be even more typing than the cast that you need to use now. > IDataProvider-Overflow with size() > -- > > Key: WICKET-1175 > URL: https://issues.apache.org/jira/browse/WICKET-1175 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-rc1 > Environment: any >Reporter: Jan Kriesten >Assignee: Igor Vaynberg > Fix For: 6.0.0-beta1 > > Attachments: 0001-Loop-should-not-use-long.patch > > > Hi, > I get an Integer-overflow with my Dataprovider (yeah, there are a couple of > entries in the database). Is there a reason why size() and iterator( first, > count ) are limited to Integer? > Regards, --- Jan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4492) some characters are not properly url encoded when used in page parameters
[ https://issues.apache.org/jira/browse/WICKET-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253322#comment-13253322 ] Martin Grigorov commented on WICKET-4492: - One reason why ";" is not encoded in the url path is because Servlet web containers encode jsessionid there when cookies are disabled: WICKET-4409 > some characters are not properly url encoded when used in page parameters > - > > Key: WICKET-4492 > URL: https://issues.apache.org/jira/browse/WICKET-4492 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: GlassFish Server 3.1.1 (netbeans) > Linux >Reporter: Sander Plas >Assignee: Martin Grigorov >Priority: Minor > Attachments: parameterencodingbug.zip > > > Wicket does not seem to correctly url-encode/decode some characters when used > in PageParameters with BookmarkablePageLink's: > The following (non-printable) values seem to be problematic in named > parameters (but work fine in indexed params): > 0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, > 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 > These (printable) values are problematic in indexed parameters (but work fine > in named params): > 46 (.), 59 (;) > I am not entirely sure whether this is a problem with wicket or glassfish; i > do know that at least the semicolon (;) problem is also occurring on tomcat. > Please see the attached quickstart. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4495) AjaxFallbackButton , onclick Behaviour ist registered per Default for onSubmit Functionlaity
[
https://issues.apache.org/jira/browse/WICKET-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253250#comment-13253250
]
Martin Grigorov commented on WICKET-4495:
-
Please provide a failing test case. The ones in WICKET-2783 do not expose the
problem.
> AjaxFallbackButton , onclick Behaviour ist registered per Default for
> onSubmit Functionlaity
>
>
> Key: WICKET-4495
> URL: https://issues.apache.org/jira/browse/WICKET-4495
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
>Reporter: otto
>Priority: Minor
> Labels: newbie
>
> Why does AjaxFallbackButton register per default an onclick Behaviour,
> and not an onsubmit behaviour ?
> With this, FormTester.submit , emulating a submit Behaviour, does not find
> the correct beaviour to execute in
> WicketTesterHelper.findAjaxEventBehavior(Component component, String event)
> Bug may be related to WICKET 2783 ?
> public AjaxFallbackButton(String id, IModel model, Form form)
> {
> super(id, model);
> mForm = form;
> add(new AjaxFormSubmitBehavior(form, "onclick")
> {
> private static final long serialVersionUID = 1L;
> @Override
> protected void onSubmit(AjaxRequestTarget target)
> {
> AjaxFallbackButton.this.onSubmit(target,
> AjaxFallbackButton.this.getForm());
> }
> @Override
> protected void onError(AjaxRequestTarget target)
> {
> AjaxFallbackButton.this.onError(target,
> AjaxFallbackButton.this.getForm());
> }
> @Override
> protected CharSequence getEventHandler()
> {
> return new
> AppendingStringBuffer(super.getEventHandler()).append("; return false;");
> }
> @Override
> protected IAjaxCallDecorator getAjaxCallDecorator()
> {
> return
> AjaxFallbackButton.this.getAjaxCallDecorator();
> }
> @Override
> protected AjaxChannel getChannel()
> {
> return AjaxFallbackButton.this.getChannel();
> }
> @Override
> public boolean getDefaultProcessing()
> {
> return
> AjaxFallbackButton.this.getDefaultFormProcessing();
> }
> });
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4441) PageProvider should create a new Page instance if PageParameters are changed, even if a stored page exists.
[
https://issues.apache.org/jira/browse/WICKET-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253211#comment-13253211
]
Martin Grigorov commented on WICKET-4441:
-
The suggestion will be implemented because it solves a problem with
bookmarkability: http://markmail.org/thread/q3ewso5dnf2wjsol
> PageProvider should create a new Page instance if PageParameters are changed,
> even if a stored page exists.
> ---
>
> Key: WICKET-4441
> URL: https://issues.apache.org/jira/browse/WICKET-4441
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: all platform.
>Reporter: Tsutomu YANO
>Assignee: Martin Grigorov
> Attachments: fix-WICKET-4441.patch, pagebug.tar.gz, pagebug2.tar.gz
>
>
> The 'getStoredPage(int)' method returns a stored page instance even if user
> changes parameter values encoded into URL, and the PageParameters object of
> the stored page instance is never changed. So same page is displayed always
> though user changes url on browser manually.
> ** HOW TO REPRODUCT **
> 1. unpack the attached sample project 'pagebug.tar.gz'.
> 2. mvn jetty:run
> 3. access to http://localhost:8080/user/user1
> You will see a form filled with information about user 1. The user's name is
> 'user 1', age is 30 and country is 'Japan'.
> The mount path of this page is '/user/${userId}'. so 'user1' in the accessed
> url is a parameter value.
> after accessing to the url, the url will be changed to
> http://localhost:8080/user/user1?0 . it contains the page id of the
> currently displayed page.
> 4. change some values and submit the form. page id will be changed on every
> submit.
> 5. change only parameter value in url to 'user2'. Never change page-id.
> for example, if you now access to http://localhost:8080/user/user1?5, change
> the url to http://localhost:8080/user/user2?5 .
> 6. This program must display information about user2, because the parameter
> value of url is changed. But you will see the information of user 1. Wicket
> always display the page of page-id = 5 (even though user changed url
> manually).
> In this sample program, I use LoadableDetachableModel for retrieving current
> parameter-value. But I don't get the new parameter-value because
> pageParameters object in a page instance is never changed after the
> construction. pageParameters is fixed in the constructor of Page class.
> I think that there are no easy way to retrieve parameter-values encoded into
> mount-path. Request.getRequestParameters() does not contain parameters
> encoded into mount-path. So there are no work-around for this issue.
> ** HOW TO FIX THIS ISSUE **
> We must return null from getStoredPage(int) method of PageProvider class, if
> current PageParameters is not same with the PageParameters of a stored page.
> In current code, getStoredPage(int) checks only if the class of both pages
> are same. We must check the PageParameters of both pages.
> ** PATCH **
> I attached a pache for PageProvider class. try it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4260) UrlRenderer renders invalid relative URLs if first segment contains colon
[ https://issues.apache.org/jira/browse/WICKET-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251581#comment-13251581 ] Martin Grigorov commented on WICKET-4260: - Filed a bug at Tomcat issue tracker for this problem: https://issues.apache.org/bugzilla/show_bug.cgi?id=53062 > UrlRenderer renders invalid relative URLs if first segment contains colon > - > > Key: WICKET-4260 > URL: https://issues.apache.org/jira/browse/WICKET-4260 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.3 >Reporter: Andreas Köhler >Assignee: Sven Meier > Fix For: 1.5.6, 6.0.0-RC1 > > Attachments: WICKET-4260.diff, WICKET-4260.path, ieDotSlashBug.zip, > wicket-4260.tar.bz2 > > > Seen on Wicket 1.5.3. > If a relative url of a link starts with a path segment containing a colon > then the whole uri will be regarded as absolute uri, so typically browsers > will complain that there is no handle for the protocol foo in foo:bar/dee/per. > See also the attached quickstart. The start page contains three links, one > relative with colon, one absolute and one to a mounted page without colon for > comparison. > The application also has a static switch to add an extended urlrenderer, > prepending "./" if needed. This fix is merely a quick shot and there might be > better alternatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-2732) Wicket redirects don't work with Apache JMeter
[ https://issues.apache.org/jira/browse/WICKET-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251580#comment-13251580 ] Martin Grigorov commented on WICKET-2732: - Filed a bug at Tomcat issue tracker for this problem: https://issues.apache.org/bugzilla/show_bug.cgi?id=53062 > Wicket redirects don't work with Apache JMeter > -- > > Key: WICKET-2732 > URL: https://issues.apache.org/jira/browse/WICKET-2732 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.6 > Environment: Glassfish >Reporter: Alexander Fisher >Assignee: Igor Vaynberg > Labels: jmeter, redirect > Fix For: 1.5-M1 > > > Unlike some browsers, JMeter does not fix up the broken URLs returned in the > Location header of 302 redirects generated by wicket. > For instance, after signing out of a wicket 1.4.6 app, the redirect might be > to Location: http://host/wicket-app/. > Some browsers and even some webservers will fix this up (removing the dot), > but JMeter will not and glassfish (and possibly other appservers) will return > a 404 error. > I've have discussed the issue with the JMeter developer and hence opened this > ticket. > http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-user/201002.mbox/browser > Many thanks, > Alex -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4490) Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails
[ https://issues.apache.org/jira/browse/WICKET-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250592#comment-13250592 ] Martin Grigorov commented on WICKET-4490: - Wicket works with relative urls because otherwise it wont work at all behind reverse proxies. 1.4.x branch will receive only security fixes so this issue will not be investigated for now. Please create a quickstart for 1.5.5 or 6.0.0-beta1 and we will reopen the ticket. > Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and > CryptedUrlWebRequestCodingStrategy fails > -- > > Key: WICKET-4490 > URL: https://issues.apache.org/jira/browse/WICKET-4490 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.20 > Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket > 1.4.20 >Reporter: Nick Johnson >Priority: Minor > Labels: ajax, cryptedurlwebrequestcodingstrategy, > iresourcelistener, safari > > In the case where we've seen this, we have a Form containing an AjaxButton. > In the onSubmit of the AjaxButton, a second component implementing > IResourceListener is made visible and is added to the page. This part works > as expected. > The second component generates its src URL using > urlFor(IResourceListener.INTERFACE); > This second component in turn contains a ByteArrayResource which would > normally be handled in onResourceRequested. The component is one which would > ordinarily be auto-fetched by the browser (in this case an embedded QuickTime > object) after being added to the page, using the generated URL from its own > urlFor(). > In the case of Safari (and only Safari), however, the browser in turn > attempts to fetch an encrypted URL which is invalid, causing an exception to > be thrown: javax.crypto.IllegalBlockSizeException: Input length must be > multiple of 8 when decrypting with padded cipher. It appears as though the > URL is either getting mangled during adding of the component, or when the > browser attempts to fetch the resource from the new component. (Will try to > narrow down which it is.) > Unfortunately this one is a bit convoluted to reproduce... > Looking at what's going across the wire, it appears the problem is that the > URL being fetched is wrong. > For a Page URL of > http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor > result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated): > The AJAX response object creates the component on the page with the src > attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...". > The incoming request from Safari, however, is GET > /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... > The incoming request from Chrome looks correct, GET > /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... > So this might also just be a Safari bug, though perhaps it could be worked > around by generating an absolute URL to the IResourceListener instead of a > relative one. > Confirmed that using RequestUtils.toAbsolutePath() works around the issue > with Safari 5.1.5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4491) isVisible() and determineVisibility() don't work as expected on component in BorderBodyContainer
[
https://issues.apache.org/jira/browse/WICKET-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250585#comment-13250585
]
Martin Grigorov commented on WICKET-4491:
-
Hi,
Is the following actually a valid code ?
{@code}
infoBorder.getBodyContainer().add( new Label( "numberOfTransactions",
tp.newSizeModel() )
{
@Override
public void onEvent( final IEvent event )
{@code}
Which #onEvent() is being overridden ?
Please attach a quickstart that demonstrates the problem.
> isVisible() and determineVisibility() don't work as expected on component in
> BorderBodyContainer
>
>
> Key: WICKET-4491
> URL: https://issues.apache.org/jira/browse/WICKET-4491
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 6.0.0-beta1
> Environment: Ubuntu 12.04, java7
>Reporter: Rob Audenaerde
>Priority: Minor
>
> I have an application that has a foldable left bar (somewhat like jQuery's
> accordeon). The menu-panels are implemented as Borders; see the next
> fragment. The problem I have is that components that are placed in this
> border do not correctly reflect the visibily of the bodycontainer -> if the
> bodycontainer is invisible, I expect the component inside that container to
> be invisible as well.
> I need this, as the component in the container acts as EventSink. I use
> events to notify the component to dynamically update itself by ajax. But
> when the event is passed and the component is invisible, there is no
> outputMarkupId and I get an Wicket Ajax Error (this is correct behaviour).
> public class AjaxToggleLinkBorder extends Border
> {
> private static final long serialVersionUID = -5801550490420643837L;
> protected boolean bodyVisible = false;
> final public boolean isBodyVisible()
> {
> return bodyVisible;
> }
> final public void setBodyVisible( final boolean isBodyVisible )
> {
> this.bodyVisible = isBodyVisible;
> getBodyContainer().setVisible( isBodyVisible() );
> }
> public AjaxToggleLinkBorder( final String id, final IModel linkText )
> {
> super( id );
> setBodyVisible( isBodyVisible() );
> setOutputMarkupId( true );
> final AjaxFallbackLink link = new AjaxFallbackLink(
> "link" )
> {
> private static final long serialVersionUID = 3540373588573135540L;
> @Override
> public void onClick( final AjaxRequestTarget target )
> {
> setBodyVisible( !isBodyVisible() );
> target.add( AjaxToggleLinkBorder.this );
> }
> };
> link.add( new Label( "label", linkText ) );
> addToBorder( link );
> }
> }
> I add components line this:
> final Border infoBorder = new AjaxToggleLinkBorder( "infoBorder", new
> Model( "Info" ) );
> infoBorder.getBodyContainer().add( new AmountLabel( "total",
> tp.newTotalModel() ) );
> infoBorder.getBodyContainer().add( new Label( "numberOfTransactions",
> tp.newSizeModel() )
> {
> @Override
> public void onEvent( final IEvent event )
> {
> super.onEvent( event );
> // check if this is a counter update event and if so repaint
> self
> if ( event.getPayload() instanceof CategoryUpdate )
> {
> final CategoryUpdate update = (CategoryUpdate)
> event.getPayload();
> final boolean isVisible = this.determineVisibility();
> if ( update.getTarget() != null && isVisible )
> {
> update.getTarget().add( this );
> }
> }
> }
> } );
> The boolean isVisible is true, while the bodycontainer is not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4487) TextTemplate in RenderHead() on component doesn't Re-Render for every page
[ https://issues.apache.org/jira/browse/WICKET-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247144#comment-13247144 ] Martin Grigorov commented on WICKET-4487: - Hey Andrea, Sorry for not assigning the ticket when I start working on it. Now we both worked on the same task.. Not that this is too bad, now we have two opinions ;-) I think it is actually a bug. TextTemplateResourceReference is just too static in its current state. Since I'm not sure whether it should be static or dynamic I'll attach my patch here to discuss it. > TextTemplate in RenderHead() on component doesn't Re-Render for every page > -- > > Key: WICKET-4487 > URL: https://issues.apache.org/jira/browse/WICKET-4487 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: Tomcat 6.x >Reporter: Tom Burton > Attachments: test.war, test.zip > > > I have a project that uses a menu thats repeated on every page. If I first > view it on a mounted page /PageName and then look at it on a BookMarkable page > /wicket/bookmarkable/page.class.name?foo the images referenced in my > template do not appear.(the javascript template image strings do not change) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4260) UrlRenderer renders invalid relative URLs if first segment contains colon
[ https://issues.apache.org/jira/browse/WICKET-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246203#comment-13246203 ] Martin Grigorov commented on WICKET-4260: - This change also exposed a bug in Jetty 7.6.2 and earlier: https://bugs.eclipse.org/bugs/show_bug.cgi?id=374475 Basically the redirect will fail if it contains non-ASCII chars. The fix will be in Jetty 7.6.3. > UrlRenderer renders invalid relative URLs if first segment contains colon > - > > Key: WICKET-4260 > URL: https://issues.apache.org/jira/browse/WICKET-4260 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.3 >Reporter: Andreas Köhler >Assignee: Sven Meier > Fix For: 1.5.6, 6.0.0-beta1 > > Attachments: WICKET-4260.diff, WICKET-4260.path, ieDotSlashBug.zip, > wicket-4260.tar.bz2 > > > Seen on Wicket 1.5.3. > If a relative url of a link starts with a path segment containing a colon > then the whole uri will be regarded as absolute uri, so typically browsers > will complain that there is no handle for the protocol foo in foo:bar/dee/per. > See also the attached quickstart. The start page contains three links, one > relative with colon, one absolute and one to a mounted page without colon for > comparison. > The application also has a static switch to add an extended urlrenderer, > prepending "./" if needed. This fix is merely a quick shot and there might be > better alternatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-2562) Allow Ajax FormSubmitting component without default form processing (i.e., analogous to IOnChangeListener)
[
https://issues.apache.org/jira/browse/WICKET-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244225#comment-13244225
]
Martin Grigorov commented on WICKET-2562:
-
https://issues.apache.org/jira/browse/WICKET-1894?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel#issue-tabs
This ticket introduced it. Not sure why it has 1.4.15 as "Fix version", the
commits were only in trunk (1.5.x). I see there is no such thing in 1.4.20 but
no new features will be added in 1.4.x anyway.
> Allow Ajax FormSubmitting component without default form processing (i.e.,
> analogous to IOnChangeListener)
> --
>
> Key: WICKET-2562
> URL: https://issues.apache.org/jira/browse/WICKET-2562
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4.3
>Reporter: Martin Makundi
>Priority: Minor
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> Workaround exists but it is a reflection hack:
> public abstract class AjaxFormSubmittingChangeListenerBehavior extends
> AjaxFormSubmitBehavior {
> private final static Method hiddenFieldGetter;
> static {
> try {
> hiddenFieldGetter = Form.class.getDeclaredMethod("getHiddenFieldId");
> hiddenFieldGetter.setAccessible(true);
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
>
> /**
>* @see org.apache.wicket.ajax.AbstractDefaultAjaxBehavior#onBind()
>*/
> @Override
> protected void onBind() {
> super.onBind();
> if (!(getComponent() instanceof IOnChangeListener))
> {
> throw new WicketRuntimeException("Behavior " + getClass().getName() +
> " can only be added to an instance of a IOnChangeListener");
> }
> }
> /**
>* @param event
>*/
> public AjaxFormSubmittingChangeListenerBehavior(String event) {
> super(event);
> }
> /**
>* @see
> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior#onError(org.apache.wicket.ajax.AjaxRequestTarget)
>*/
> @Override
> protected void onError(AjaxRequestTarget target) {
> onSubmit(target);
> }
> /**
>* @see
> org.apache.wicket.ajax.form.AjaxFormSubmitBehavior#onEvent(org.apache.wicket.ajax.AjaxRequestTarget)
>*/
> @Override
> protected void onEvent(AjaxRequestTarget target) {
> org.mortbay.util.MultiMap parameters = ((org.mortbay.jetty.Request)
> ((WebRequest) getComponent()
> .getRequest()).getHttpServletRequest()).getParameters();
> parameters.put(getHiddenFieldId(getForm()),
> getComponent().urlFor(IOnChangeListener.INTERFACE));
> super.onEvent(target);
> }
> /**
>* @param form
>* @return String
>*/
> private String getHiddenFieldId(Form form) {
> try {
> Form root = form.getRootForm();
> return (String) hiddenFieldGetter.invoke(root);
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4472) Modal window accessibility - add role and aria attributes to outer div for assitive technologies
[ https://issues.apache.org/jira/browse/WICKET-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244131#comment-13244131 ] Martin Grigorov commented on WICKET-4472: - Task 1) is added in 6.x. For task 2) someone with better CSS and image manipulation skills should help. > Modal window accessibility - add role and aria attributes to outer div for > assitive technologies > > > Key: WICKET-4472 > URL: https://issues.apache.org/jira/browse/WICKET-4472 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5.5 >Reporter: Lucas >Priority: Minor > Labels: accessibility, aria, close_icon, dialog, labelledBy, > modal > Original Estimate: 1h > Remaining Estimate: 1h > > For more accessible modal windows: > 1) it is desirable that the outer DIV element has a 'dialog' role defined and > an 'aria-labelledBy' attribute pointing to the modal title text. This will > help assistive technologies in properly alerting people with disabilities > (PwD) users about the modal windows that wicket displays. > Until I get familiar/ready for OSS contributions, I leave you a code snippet > for modal.js (around line 1170) > old: > 10px; width: 100px;\"> > new: > aria-labelledBy=\""+idCaptionText+"\" style=\"top: 10px; left: 10px; width: > 100px;\"> > 2) it is desirable that the close icon of modal windows (top right corner) > have associated text. This will help assistive technologies in properly > labeling the icon. Also, because background images are hidden when > high-contrast mode is active (Alt+Shift+PrtSc) the close icon should not be a > background but rather an img tag, with appropriate alt attribute. Following > is a suggestion of the proposed change in modal.js (around line 1191) except > for the image source which I believe requires some rework from your side: > old: > ""+ > new: > " alt=\"close dialog\" />"+ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4476) Inline Enclosure generates not unique markup ids
[ https://issues.apache.org/jira/browse/WICKET-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244083#comment-13244083 ] Martin Grigorov commented on WICKET-4476: - Works fine in 1.5-SNAPSHOT. Both InlineEnclosures have unique ids and the children (links) inside them as well. Maybe it is a problem in 1.4-SNAPSHOT but 1.4.x receives only security fixes. You are recommended to upgrade to 1.5.5. > Inline Enclosure generates not unique markup ids > > > Key: WICKET-4476 > URL: https://issues.apache.org/jira/browse/WICKET-4476 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.20 > Environment: Java 6, Mac OS >Reporter: Olaf Siefart >Priority: Critical > Labels: enclosure, inline, markupid > Original Estimate: 2h > Remaining Estimate: 2h > > Using a repeater with nested inline enclosure i found identical markup ids in > the html markup, so ajax is not working properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4458) wicket-core-1.5.5.jar not closed when Application is undeployed from directory
[
https://issues.apache.org/jira/browse/WICKET-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244082#comment-13244082
]
Martin Grigorov commented on WICKET-4458:
-
The improvement is applied in 1.5.x and 6.x.
I don't see the opened file descriptor in lsof output anymore.
Please re-test with 1.5-SNAPSHOT before 1.5.6 is out.
> wicket-core-1.5.5.jar not closed when Application is undeployed from directory
> --
>
> Key: WICKET-4458
> URL: https://issues.apache.org/jira/browse/WICKET-4458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>Reporter: bernard
>Assignee: Martin Grigorov
>
> How to reproduce:
> - Create a 1.5.5 quickstart
> - deploy it on the GlassFish server with directory deployment (I use NetBeans
> which is easy)
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Error in GlassFish log:
> Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar
> I first thought that this was a GlassFish issue such as:
> http://java.net/jira/browse/GLASSFISH-17339
> To eliminate that, I added glassfish\modules\war-util.jar to the project and
> wrote code to let GlassFish close all jar files:
> In the Application class:
> @Override
> public void onDestroy() {
> super.onDestroy();
> ClassLoader parentClassLoader = this.getClass().getClassLoader();
> ClassLoader classLoader;
> do{
> classLoader = parentClassLoader;
> if(classLoader instanceof WebappClassLoader){
> WebappClassLoader glassFishLoader =
> (WebappClassLoader)classLoader;
> glassFishLoader.closeJARs(true);
> break;
> }
> parentClassLoader = classLoader.getParent();
> }while(parentClassLoader != classLoader && parentClassLoader != null);
>
> }
>
> but this did not fix the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4475) Inline Enclosure needs to check isVisibleInHierarchy, not only isVisible
[ https://issues.apache.org/jira/browse/WICKET-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244030#comment-13244030 ] Martin Grigorov commented on WICKET-4475: - I updated the code to use determineVisilibility() instead of #isVisible() so visibilityAllowed() will be taken into account. But it seems you didn't understand the purpose of Inline in InlineEnclosure. The markup element for the InlineEnclosure is always rendered, even if the child is invisible, this way it can be updated in Ajax requests because the placeholder tag is there. If you want the markup of the enclosure to not be rendered at all then you need , but in this case it wont work in Ajax. > Inline Enclosure needs to check isVisibleInHierarchy, not only isVisible > > > Key: WICKET-4475 > URL: https://issues.apache.org/jira/browse/WICKET-4475 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.20 > Environment: Mac Os, Java 6 >Reporter: Olaf Siefart > Labels: Enclosure, Inline, visibility > Original Estimate: 1h > Remaining Estimate: 1h > > If the Visibility of the child component from the inline enclure uses > setVisibleAllowed, the enclosure is rendered if the component is not visible. > Take a look to the updateVisibility-method of the InlineEnclosure-Class. In > my opinion the method should check for isVisibleInHierarchy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4458) wicket-core-1.5.5.jar not closed when Application is undeployed from directory
[
https://issues.apache.org/jira/browse/WICKET-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244018#comment-13244018
]
Martin Grigorov commented on WICKET-4458:
-
I was able to reproduce it and I'll try Tim's suggestion.
> wicket-core-1.5.5.jar not closed when Application is undeployed from directory
> --
>
> Key: WICKET-4458
> URL: https://issues.apache.org/jira/browse/WICKET-4458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>Reporter: bernard
>Assignee: Martin Grigorov
>
> How to reproduce:
> - Create a 1.5.5 quickstart
> - deploy it on the GlassFish server with directory deployment (I use NetBeans
> which is easy)
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Error in GlassFish log:
> Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar
> I first thought that this was a GlassFish issue such as:
> http://java.net/jira/browse/GLASSFISH-17339
> To eliminate that, I added glassfish\modules\war-util.jar to the project and
> wrote code to let GlassFish close all jar files:
> In the Application class:
> @Override
> public void onDestroy() {
> super.onDestroy();
> ClassLoader parentClassLoader = this.getClass().getClassLoader();
> ClassLoader classLoader;
> do{
> classLoader = parentClassLoader;
> if(classLoader instanceof WebappClassLoader){
> WebappClassLoader glassFishLoader =
> (WebappClassLoader)classLoader;
> glassFishLoader.closeJARs(true);
> break;
> }
> parentClassLoader = classLoader.getParent();
> }while(parentClassLoader != classLoader && parentClassLoader != null);
>
> }
>
> but this did not fix the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4387) StringIndexOutOfBoundsException when forwarding requests
[
https://issues.apache.org/jira/browse/WICKET-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244014#comment-13244014
]
Martin Grigorov commented on WICKET-4387:
-
Hi,
Can you confirm that the fix in 1.5.5 solves the problem for you?
> StringIndexOutOfBoundsException when forwarding requests
>
>
> Key: WICKET-4387
> URL: https://issues.apache.org/jira/browse/WICKET-4387
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.4
>Reporter: Yossi Shaul
>Assignee: Martin Grigorov
>Priority: Critical
> Fix For: 1.5.5, 6.0.0-beta1
>
> Attachments: wicket.zip
>
>
> We're getting StringIndexOutOfBoundsException from wicket when forwarding a
> request from our servlet filter (using request dispatcher) to wicket.
> The problem occurs whenever the original URI is shorter than the wicket
> filter mapping.
> I created an example webapp (based on the quickstart) in which a
> ForwardFilter is mapped to /f/* and it forwards all the requests to /wicket/
> (see web.xml snippet below).
> With this webapp a request to "http://localhost:8081/wicket/f/"; results in
> the following exception:
> {code}
> ERROR - RequestCycle - Error during processing error message
> java.lang.StringIndexOutOfBoundsException: String index out of range: -5
> at java.lang.String.substring(String.java:1958)
> at java.lang.String.substring(String.java:1925)
> at
> org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:180)
> at
> org.apache.wicket.protocol.http.servlet.ServletWebRequest.getClientUrl(ServletWebRequest.java:140)
> at org.apache.wicket.request.UrlRenderer.(UrlRenderer.java:59)
> at
> org.apache.wicket.request.cycle.RequestCycle.newUrlRenderer(RequestCycle.java:148)
> at
> org.apache.wicket.request.cycle.RequestCycle.getUrlRenderer(RequestCycle.java:172)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:145)
> at
> org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:304)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:227)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
> at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
> at
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:402)
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)
> at org.jfrog.ForwardFilter.doFilter(ForwardFilter.java:2
[jira] [Commented] (WICKET-4458) wicket-core-1.5.5.jar not closed when Application is undeployed from directory
[
https://issues.apache.org/jira/browse/WICKET-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242407#comment-13242407
]
Martin Grigorov commented on WICKET-4458:
-
Hi Tim,
Can you refer to some documentation that specifies this behavior ?
I don't see anything specific in JarUrlConnection.
In UrlConnection there is:
* Invoking the close() methods on the InputStream or
OutputStream of an
* URLConnection after a request may free network resources associated
with this
* instance, unless particular protocol specifications specify different
behaviours
* for it.
which opens the door for the impls to do nothing as you said...
But lsof also doesn't show open file descriptor to the .jar here ...
> wicket-core-1.5.5.jar not closed when Application is undeployed from directory
> --
>
> Key: WICKET-4458
> URL: https://issues.apache.org/jira/browse/WICKET-4458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>Reporter: bernard
>
> How to reproduce:
> - Create a 1.5.5 quickstart
> - deploy it on the GlassFish server with directory deployment (I use NetBeans
> which is easy)
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Error in GlassFish log:
> Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar
> I first thought that this was a GlassFish issue such as:
> http://java.net/jira/browse/GLASSFISH-17339
> To eliminate that, I added glassfish\modules\war-util.jar to the project and
> wrote code to let GlassFish close all jar files:
> In the Application class:
> @Override
> public void onDestroy() {
> super.onDestroy();
> ClassLoader parentClassLoader = this.getClass().getClassLoader();
> ClassLoader classLoader;
> do{
> classLoader = parentClassLoader;
> if(classLoader instanceof WebappClassLoader){
> WebappClassLoader glassFishLoader =
> (WebappClassLoader)classLoader;
> glassFishLoader.closeJARs(true);
> break;
> }
> parentClassLoader = classLoader.getParent();
> }while(parentClassLoader != classLoader && parentClassLoader != null);
>
> }
>
> but this did not fix the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4471) Generic registry of javascript/css resource references
[ https://issues.apache.org/jira/browse/WICKET-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239524#comment-13239524 ] Martin Grigorov commented on WICKET-4471: - This is what the attached patch address. > Generic registry of javascript/css resource references > -- > > Key: WICKET-4471 > URL: https://issues.apache.org/jira/browse/WICKET-4471 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 6.0.0-beta1 >Reporter: Ronald Tetsuo Miura >Assignee: Emond Papegaaij >Priority: Minor > Attachments: > 0001-WICKET-4471-unwrap-ResourceBundleReference-to-render.patch > > > It would be nice if JavaScriptLibrarySettings had a generic mechanism to > register javascript/css resource references (maybe using something like > MetaDataKeys). > This way, extension/third-party components (ModalWindow, DateTimeField, etc.) > could register their resources, or just lookup for substitute resource > references for their own scripts/stylesheets. > This would allow some optimizations, such as minification/compression and > joining many files into one, and hosting static files in CDNs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4471) Generic registry of javascript/css resource references
[ https://issues.apache.org/jira/browse/WICKET-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239514#comment-13239514 ] Martin Grigorov commented on WICKET-4471: - Thanks for the clarifications! With the last two comments it is more clear what you meant. So in DEV mode an application can use package resources and for PROD mode the app just need to add a bundle that main resref is ExternalUrlResRef and this bundle will say "I'm responsible for some package resources" so the only generated url is for the external resref. Sounds pretty good. The example can contain the "external resource" in src/main/webapp, i.e. it will simulate being external. > Generic registry of javascript/css resource references > -- > > Key: WICKET-4471 > URL: https://issues.apache.org/jira/browse/WICKET-4471 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 6.0.0-beta1 >Reporter: Ronald Tetsuo Miura >Assignee: Emond Papegaaij >Priority: Minor > Attachments: > 0001-WICKET-4471-unwrap-ResourceBundleReference-to-render.patch > > > It would be nice if JavaScriptLibrarySettings had a generic mechanism to > register javascript/css resource references (maybe using something like > MetaDataKeys). > This way, extension/third-party components (ModalWindow, DateTimeField, etc.) > could register their resources, or just lookup for substitute resource > references for their own scripts/stylesheets. > This would allow some optimizations, such as minification/compression and > joining many files into one, and hosting static files in CDNs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4471) Generic registry of javascript/css resource references
[ https://issues.apache.org/jira/browse/WICKET-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239383#comment-13239383 ] Martin Grigorov commented on WICKET-4471: - I'm not sure that I like Wicket plays like a mashup and combines resources from all over the globe. The idea of CDN is to deliver commonly used libs from the fastest mirror for the user. Why one would want to merge it in a local bundle afterwards. This kills the benefit of CDN. If you want to bundle it then download it locally and add it in the bundle as JavaScriptResRef or CssResRef. I guess someone will want ExternalUrlResRef to be able to fallback to a local ResRef if there is no connection to the external url... > Generic registry of javascript/css resource references > -- > > Key: WICKET-4471 > URL: https://issues.apache.org/jira/browse/WICKET-4471 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 6.0.0-beta1 >Reporter: Ronald Tetsuo Miura >Assignee: Emond Papegaaij >Priority: Minor > Attachments: > 0001-WICKET-4471-unwrap-ResourceBundleReference-to-render.patch > > > It would be nice if JavaScriptLibrarySettings had a generic mechanism to > register javascript/css resource references (maybe using something like > MetaDataKeys). > This way, extension/third-party components (ModalWindow, DateTimeField, etc.) > could register their resources, or just lookup for substitute resource > references for their own scripts/stylesheets. > This would allow some optimizations, such as minification/compression and > joining many files into one, and hosting static files in CDNs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3317) Investigate whether introducing Optional will make life easier
[ https://issues.apache.org/jira/browse/WICKET-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239324#comment-13239324 ] Martin Grigorov commented on WICKET-3317: - Right. The dependency is needed only at compile time and that's why I've been confused that 'compile' is what is needed. I changed it to 'provided'. > Investigate whether introducing Optional will make life easier > -- > > Key: WICKET-3317 > URL: https://issues.apache.org/jira/browse/WICKET-3317 > Project: Wicket > Issue Type: Improvement >Reporter: Igor Vaynberg >Assignee: Igor Vaynberg > Attachments: optional-patch.txt > > > Optional makes handling return values and parameters that may contain null > explicit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3317) Investigate whether introducing Optional will make life easier
[ https://issues.apache.org/jira/browse/WICKET-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239308#comment-13239308 ] Martin Grigorov commented on WICKET-3317: - In branch 'jsr-305' I committed a simple change that adds FindBugs impl of JSR-305. At http://blogs.jetbrains.com/idea/2011/03/more-flexible-and-configurable-nullublenotnull-annotations/ you may see how to configure it in Intellij IDEA. With this setup IDEA showed me some possible null problems - the ones in Image class in commit d3e9411271a01c4617460f5ee125bcfcab76ec60. > Investigate whether introducing Optional will make life easier > -- > > Key: WICKET-3317 > URL: https://issues.apache.org/jira/browse/WICKET-3317 > Project: Wicket > Issue Type: Improvement >Reporter: Igor Vaynberg >Assignee: Igor Vaynberg > Attachments: optional-patch.txt > > > Optional makes handling return values and parameters that may contain null > explicit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4472) Modal window accessibility - add role and aria attributes to outer div for assitive technologies
[ https://issues.apache.org/jira/browse/WICKET-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238421#comment-13238421 ] Martin Grigorov commented on WICKET-4472: - Thanks for the ticket! Either attach the changes as patches or at least paste how it looks now and how it should become. This will make it easier for us to dig the specific code and modify it. Otherwise we can make a mistake and modify the wrong div ... > Modal window accessibility - add role and aria attributes to outer div for > assitive technologies > > > Key: WICKET-4472 > URL: https://issues.apache.org/jira/browse/WICKET-4472 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.5.5 >Reporter: Lucas >Priority: Minor > Labels: accessibility, aria, dialog > Original Estimate: 1h > Remaining Estimate: 1h > > For more accessible modal windows it is desirable that the outer DIV element > has a 'dialog' role defined and an 'aria-labelledBy' attribute pointing to > the modal title text. This will help assistive technologies in properly > alerting people with disabilities (PwD) users about the modal windows that > wicket displays. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4471) Generic registry of javascript/css resource references
[ https://issues.apache.org/jira/browse/WICKET-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238417#comment-13238417 ] Martin Grigorov commented on WICKET-4471: - This is also possible. See the classes in org.apache.wicket.resource.bundles package. But I agree that we should add few lines of documentation about this in the migration page or in a special Wiki dedicated to resoources/resource references . > Generic registry of javascript/css resource references > -- > > Key: WICKET-4471 > URL: https://issues.apache.org/jira/browse/WICKET-4471 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 6.0.0-beta1 >Reporter: Ronald Tetsuo Miura >Priority: Minor > > It would be nice if JavaScriptLibrarySettings had a generic mechanism to > register javascript/css resource references (maybe using something like > MetaDataKeys). > This way, extension/third-party components (ModalWindow, DateTimeField, etc.) > could register their resources, or just lookup for substitute resource > references for their own scripts/stylesheets. > This would allow some optimizations, such as minification/compression and > joining many files into one, and hosting static files in CDNs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4471) Generic registry of javascript/css resource references
[ https://issues.apache.org/jira/browse/WICKET-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238383#comment-13238383 ] Martin Grigorov commented on WICKET-4471: - There is org.apache.wicket.request.resource.ResourceReference#getDependencies(). This way a resource X can say "I depend on resource Y". This is how wicket-ajax-jquery.js depends on wicket-event.js which depends on jquery.js. I.e. doing headerResponse.render(JavaScriptHeaderItem.forReference(WicketAjaxResourceReference.INSTANCE)); will contribute wicket-ajax.js, wicket-event.js and jquery.js. Does this help for your case ? > Generic registry of javascript/css resource references > -- > > Key: WICKET-4471 > URL: https://issues.apache.org/jira/browse/WICKET-4471 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 6.0.0-beta1 >Reporter: Ronald Tetsuo Miura >Priority: Minor > > It would be nice if JavaScriptLibrarySettings had a generic mechanism to > register javascript/css resource references (maybe using something like > MetaDataKeys). > This way, extension/third-party components (ModalWindow, DateTimeField, etc.) > could register their resources, or just lookup for substitute resource > references for their own scripts/stylesheets. > This would allow some optimizations, such as minification/compression and > joining many files into one, and hosting static files in CDNs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4469) MultipartFormInputStream - Error while reading servlet request multi-part data
[ https://issues.apache.org/jira/browse/WICKET-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238299#comment-13238299 ] Martin Grigorov commented on WICKET-4469: - I thought we agreed that it is a regression in GF 3.1.2. Wicket cannot fix the web container it is running in, neither the OS, nor the hardware... > MultipartFormInputStream - Error while reading servlet request multi-part data > -- > > Key: WICKET-4469 > URL: https://issues.apache.org/jira/browse/WICKET-4469 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: Glassfish 3.1.2 >Reporter: Anatoly Ivanov > > Where is bug on FileUploadField by default submit after update to Glassfish > 3.1.2. Submit and upload via AjaxButton is work. > 2012-03-26 15:31:32,966 ERROR > org.apache.wicket.util.upload.MultipartFormInputStream - Error while reading > servlet request multi-part data: Stream ended unexpectedly. > boundary='-4118467633434'; bufSize=4096 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4469) MultipartFormInputStream - Error while reading servlet request multi-part data
[ https://issues.apache.org/jira/browse/WICKET-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238243#comment-13238243 ] Martin Grigorov commented on WICKET-4469: - It seems like a problem introduced in Glassfish 3.1.2. Deploy your app in Tomcat and see how it behaves. > MultipartFormInputStream - Error while reading servlet request multi-part data > -- > > Key: WICKET-4469 > URL: https://issues.apache.org/jira/browse/WICKET-4469 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: Glassfish 3.1.2 >Reporter: Anatoly Ivanov > > Where is bug on FileUploadField by default submit after update to Glassfish > 3.1.2. Submit and upload via AjaxButton is work. > 2012-03-26 15:31:32,966 ERROR > org.apache.wicket.util.upload.MultipartFormInputStream - Error while reading > servlet request multi-part data: Stream ended unexpectedly. > boundary='-4118467633434'; bufSize=4096 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4469) MultipartFormInputStream - Error while reading servlet request multi-part data
[ https://issues.apache.org/jira/browse/WICKET-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238226#comment-13238226 ] Martin Grigorov commented on WICKET-4469: - Can you try with different web container (e.g. Tomcat/Jetty) ? Also please try with Wicket 1.5.4. If it still fails then please create a quickstart and attach it to the ticket. There are many examples of multipart form submits and all of them work. > MultipartFormInputStream - Error while reading servlet request multi-part data > -- > > Key: WICKET-4469 > URL: https://issues.apache.org/jira/browse/WICKET-4469 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 > Environment: Glassfish 3.1.2 >Reporter: Anatoly Ivanov > > Where is bug on FileUploadField by default submit after update to Glassfish > 3.1.2. Submit and upload via AjaxButton is work. > 2012-03-26 15:31:32,966 ERROR > org.apache.wicket.util.upload.MultipartFormInputStream - Error while reading > servlet request multi-part data: Stream ended unexpectedly. > boundary='-4118467633434'; bufSize=4096 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4458) wicket-core-1.5.5.jar not closed when Application is undeployed from directory
[
https://issues.apache.org/jira/browse/WICKET-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238196#comment-13238196
]
Martin Grigorov commented on WICKET-4458:
-
Here is the code related to this stacktrace (o.a.w.Application.java):
InputStream in = null;
try
{
final URL url = resources.next();
final Properties properties = new
Properties();
in = url.openStream(); // LINE 499
properties.load(in);
load(properties);
}
finally
{
IOUtils.close(in);
}
As you can see we close the input stream in 'finally'. It is not even
'IOUtils.closeQuietly()' so if there is an error during #close() it will stop
the initialization of the application.
For some reason I don't trust this detection ...
> wicket-core-1.5.5.jar not closed when Application is undeployed from directory
> --
>
> Key: WICKET-4458
> URL: https://issues.apache.org/jira/browse/WICKET-4458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>Reporter: bernard
>
> How to reproduce:
> - Create a 1.5.5 quickstart
> - deploy it on the GlassFish server with directory deployment (I use NetBeans
> which is easy)
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Error in GlassFish log:
> Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar
> I first thought that this was a GlassFish issue such as:
> http://java.net/jira/browse/GLASSFISH-17339
> To eliminate that, I added glassfish\modules\war-util.jar to the project and
> wrote code to let GlassFish close all jar files:
> In the Application class:
> @Override
> public void onDestroy() {
> super.onDestroy();
> ClassLoader parentClassLoader = this.getClass().getClassLoader();
> ClassLoader classLoader;
> do{
> classLoader = parentClassLoader;
> if(classLoader instanceof WebappClassLoader){
> WebappClassLoader glassFishLoader =
> (WebappClassLoader)classLoader;
> glassFishLoader.closeJARs(true);
> break;
> }
> parentClassLoader = classLoader.getParent();
> }while(parentClassLoader != classLoader && parentClassLoader != null);
>
> }
>
> but this did not fix the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4467) SecurePackageResourceGuard blocks static packages ending on #
[ https://issues.apache.org/jira/browse/WICKET-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236690#comment-13236690 ] Martin Grigorov commented on WICKET-4467: - Are you sure that this really comes from Wicket ? I'm not aware of any place were Wicket puts # in the produced urls. Can you reproduce it in a quickstart ? > SecurePackageResourceGuard blocks static packages ending on # > - > > Key: WICKET-4467 > URL: https://issues.apache.org/jira/browse/WICKET-4467 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.5 >Reporter: Arne Baganz > > Since Wicket 1.5.5, the default SecurePackageResourceGuard blocks static > packages ending on #, for instance I got this stack trace: > org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: > Access denied to (static) package resource com/pany/panels/#. See > IPackageResourceGuard > at > org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:418) > at > org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:338) > at > org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:170) > at > org.apache.wicket.request.resource.caching.version.CachingResourceVersion.getVersion(CachingResourceVersion.java:99) > at > org.apache.wicket.request.resource.caching.FilenameWithVersionResourceCachingStrategy.decorateUrl(FilenameWithVersionResourceCachingStrategy.java:96) > at > org.apache.wicket.request.mapper.BasicResourceReferenceMapper.mapHandler(BasicResourceReferenceMapper.java:219) > at > org.apache.wicket.request.mapper.ParentPathReferenceRewriter.mapHandler(ParentPathReferenceRewriter.java:89) > at > org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:157) > at > org.apache.wicket.protocol.https.HttpsMapper.mapHandler(HttpsMapper.java:125) > at > org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:404) > at org.apache.wicket.request.cycle.RequestCycle.urlFor(RequestCycle.java:456) > at > org.apache.wicket.markup.html.image.resource.LocalizedImageResource.setSrcAttribute(LocalizedImageResource.java:331) > at org.apache.wicket.markup.html.image.Image.onComponentTag(Image.java:242) > at org.apache.wicket.Component.internalRenderComponent(Component.java:2510) > at org.apache.wicket.markup.html.WebComponent.onRender(WebComponent.java:56) > at org.apache.wicket.Component.internalRender(Component.java:2369) > at org.apache.wicket.Component.render(Component.java:2297) > at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1432) > at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1596) > at > org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1571) > at > org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1526) > at > org.apache.wicket.markup.html.link.AbstractLink.onComponentTagBody(AbstractLink.java:181) > at > org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:73) > at org.apache.wicket.Component.internalRenderComponent(Component.java:2539) > at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1535) > at org.apache.wicket.Component.internalRender(Component.java:2369) > at org.apache.wicket.Component.render(Component.java:2297) > at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1432) > at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1596) > at > org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1571) > at > org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1526) > at > org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:73) > at org.apache.wicket.Component.internalRenderComponent(Component.java:2539) > at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1535) > at org.apache.wicket.Component.internalRender(Component.java:2369) > at org.apache.wicket.Component.render(Component.java:2297) > at > org.apache.wicket.markup.repeater.AbstractRepeater.renderChild(AbstractRepeater.java:111) > at > org.apache.wicket.markup.repeater.AbstractRepeater.onRender(AbstractRepeater.java:97) > at org.apache.wicket.Component.internalRender(Component.java:2369) > at org.apache.wicket.Component.render(Component.java:2297) > at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1432) > at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1596) > at > org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1571) > at >
[jira] [Commented] (WICKET-4463) Maybe there are several Ajax event behaviors on the same type assigned to this component
[
https://issues.apache.org/jira/browse/WICKET-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236481#comment-13236481
]
Martin Grigorov commented on WICKET-4463:
-
Hi Serban,
I think you actually benefit from this warning.
I guess your code looks like:
AjaxLink l = new AjaxLink() {...};
l.add(new ConfirmBehavior());
parent.add(link);
If this is the case then ConfirmBehavior is added before AjaxEventBehavior
because the latter is added in AjaxLink#onInitialize(). So
tag.getAttributes().getString("onclick"); should always return "null" for you,
no ?
AjaxEventBehavior#onComponentTag() logs this warning only if there is some
value already for the event it manipulates. Because it completely ignores the
old value and replaces with the result of
org.apache.wicket.ajax.AjaxEventBehavior#getEventHandler().
> Maybe there are several Ajax event behaviors on the same type assigned to
> this component
>
>
> Key: WICKET-4463
> URL: https://issues.apache.org/jira/browse/WICKET-4463
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
>Reporter: Serban Balamaci
>Priority: Minor
>
> I don't know if this is actually an issue, just wanted to know let you know
> what the recent
> http://apache-wicket.1842946.n4.nabble.com/Log-a-warning-when-there-are-several-ajax-event-behaviors-on-the-same-event-td4413925.html
> change impacted.
> We are now seeing:
> WARN (org.apache.wicket.ajax.AjaxEventBehavior:120)-
> org.apache.wicket.ajax.markup.html.AjaxLink$1 {event='onclick'} assigned to [
> [Component id = delete]] is overriding the previous value of the inline
> attribute. Maybe there are several Ajax event behaviors on the same type
> assigned to this component.
> Because we have an AjaxLink with added ConfirmBehavior that does not
> "replace" but "enhances" by appending to a behaviour:
> ConfirmBehavior extends Behavior {
> @Override
> public void onComponentTag(Component component, ComponentTag tag) {
> StringBuilder handler = new StringBuilder(128);
> handler.append("if (!confirm('");
> handler.append(message.getObject());
> handler.append("')) {return false;} ");
> String script = tag.getAttributes().getString("onclick");
> if (script != null) {
> handler.append(script);
> }
> tag.put("onclick", handler.toString());
> }
> }
> we can/should probably change it to an AjaxCallDecorator, just wanted to let
> others know what the change
> http://apache-wicket.1842946.n4.nabble.com/Log-a-warning-when-there-are-several-ajax-event-behaviors-on-the-same-event-td4413925.html
> might affect.
> Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4465) Autocomplete IE javascript error: 'target' is null or not an object
[ https://issues.apache.org/jira/browse/WICKET-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235495#comment-13235495 ] Martin Grigorov commented on WICKET-4465: - The improvement is added. Thanks again! > Autocomplete IE javascript error: 'target' is null or not an object > --- > > Key: WICKET-4465 > URL: https://issues.apache.org/jira/browse/WICKET-4465 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.5.5 > Environment: javascript - IE7, IE8, IE9 >Reporter: Ondrej Fafejta >Assignee: Martin Grigorov > Labels: javascript > Fix For: 1.5.6, 6.0.0 > > Attachments: WICKET-4465.patch > > > When I click to autocomplete textfield the javascript error bellow is shown. > Webpage error details > User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; > Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR > 3.0.30729) > Timestamp: Thu, 22 Mar 2012 08:05:57 UTC > Message: 'target' is null or not an object > Line: 68 > Char: 1 > Code: 0 > URI: > http://xxx:8080/wicket/resource/org.apache.wicket.extensions.ajax.markup.html.autocomplete.AutoCompleteBehavior/wicket-autocomplete-ver-C51E30D722C9620E9D06F141A171849F.js > Wicket 1.5.4 works fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4464) AbstractTransformerBehavior breaks ajax requests in IE8
[
https://issues.apache.org/jira/browse/WICKET-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235473#comment-13235473
]
Martin Grigorov commented on WICKET-4464:
-
Consider upgrading to 1.5.x. There is no such problem there.
1.4.x most likely wont receive any bug fixes anymore. Only security fixes will
be applied in 1.4.x branch.
> AbstractTransformerBehavior breaks ajax requests in IE8
> ---
>
> Key: WICKET-4464
> URL: https://issues.apache.org/jira/browse/WICKET-4464
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.20
>Reporter: Robert Keller
> Labels: Ajax, IE, WICKET-3633
>
> AbstractTransformerBehavior sets ´webResponse.setContentType("text/" +
> getMarkupType(component) + "; charset=" + encoding);´
> This delegates to the page and in our case usually returns "text/html".
> In ajax-request this overwrites the required setting for ajax "text/xml". If
> IE8 receives an ajax-response as "text/html" then in wicket-ajax.js:1049 the
> xmldoc = t.responseXml is null and the error is:
> "ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Could not
> find root element".
> This error was created by https://issues.apache.org/jira/browse/WICKET-3633.
> Possible un-/fixes:
> - Changing the markuptype on page level to "xml" in ajaxrequests might break
> functionality.
> + let only AbstractTransformerBehavior consider ajaxrequests and then set xml
> + at least: make
> org.apache.wicket.markup.html.border.MarkupComponentBorder.getMarkupType(Component)
> protected and not final!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4156) FormTester does not support selection for Palette
[ https://issues.apache.org/jira/browse/WICKET-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234417#comment-13234417 ] Martin Grigorov commented on WICKET-4156: - WicketTester is in -core.jar while Palette is in -extensions.jar thus WicketTester itself cannot have methods that work with Palette. This can be solved like org.apache.wicket.extensions.ajax.markup.html.AjaxLazyLoadPanelTester, i.e. by introducing PaletteTester. Any contributions are welcome! > FormTester does not support selection for Palette > - > > Key: WICKET-4156 > URL: https://issues.apache.org/jira/browse/WICKET-4156 > Project: Wicket > Issue Type: Improvement > Components: wicket, wicket-extensions >Reporter: Brandon Wong >Priority: Minor > Labels: test, wicket > > The FormTester selection methods are not compatible with the form components > in the Palette. > The error "org.apache.wicket.WicketRuntimeException: Selecting on the > component XXX is not supported" is thrown when trying to select the "choices" > component in the Palette. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3165) Queueing model for multiple AJAX requests
[ https://issues.apache.org/jira/browse/WICKET-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233359#comment-13233359 ] Martin Grigorov commented on WICKET-3165: - Calling several listener interfaces in one Ajax request and returning for each of them is easy to do. The complexity comes when an Ajax call makes form submittion or needs to send custom headers. In these cases it wont be easy to differentiate which headers/parameters are part of which Ajax call at the server side. I can imagine this implemented with prefixes for the headers and parameters for the different parts of the combined Ajax call but this will be too complex. > Queueing model for multiple AJAX requests > - > > Key: WICKET-3165 > URL: https://issues.apache.org/jira/browse/WICKET-3165 > Project: Wicket > Issue Type: New Feature > Components: wicket >Reporter: John Armstrong > > Currently wicket ajax requests can block. > This feature request suggests a queuing model where multiple ajax requests > made during some given time horizon (100ms for example, configurable) are > bundled together and sent as one request to a dispatcher. The server > satisfies these and then returns them as a single result. > Wicket on the client side would then dispatch these to their callers. > The result is what appears to be multiple simultaneous AJAX requests. > EXT-JS uses this concept and even though it is a pure client side framework > it may be an interesting model to reference. > From Users list > Thread title: Wicket design incompatible with Web 2.0 > Specific Excerpt > --- > not a bad idea. we already have a concept of "channels", but right now > they can only queue or drop requests. with some work it should be > possible to add an "aggregate" mode and process multiple callbacks > within the same request. please file a jira issue. > -igor > - Hide quoted text - > On Fri, Nov 12, 2010 at 11:44 AM, John Armstrong > wrote: > > EXT-JS does a nice queueing model where you can set a queue timer (say > > 100ms) and any AJAX requests get bundled up into a single package that > > goes across the wire at once, returning and then being sent back to > > their callers. > > > > This lets a page update many components at once in what appears to be > > real-time without blocking. > > > > Might be an interesting model for wicket at some point in the future. > > > > Yes, I know, EST-JS is a client-side framework. I am only using it as > > an example of how some stacks are resolving these sorts of issues. > > > > John- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-1373) cache created proxy classes
[ https://issues.apache.org/jira/browse/WICKET-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233326#comment-13233326 ] Martin Grigorov commented on WICKET-1373: - What exactly should be improved here ? JDK proxy classes are already cached - java.lang.reflect.Proxy#newProxyInstance() calls java.lang.reflect.Proxy#getProxyClass() which supports caching. I'm not sure what is the state in CGLIB. > cache created proxy classes > --- > > Key: WICKET-1373 > URL: https://issues.apache.org/jira/browse/WICKET-1373 > Project: Wicket > Issue Type: Sub-task >Reporter: Igor Vaynberg >Assignee: Johan Compagner > > we can cache the created proxy class and simply give each instance a > new handler... > -igor > On Tue, Feb 26, 2008 at 10:26 AM, James Carman > wrote: > > Have you tried this out using load testing? You are creating a new > > class every time you create a model. Have you run out of permgen > > space? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=13232687#comment-13232687 ] Martin Grigorov commented on WICKET-3068: - org.apache.wicket.settings.ISessionSettings is a good candidate to be removed for Wicket 6.0. > 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4458) wicket-core-1.5.5.jar not closed when Application is undeployed from directory
[
https://issues.apache.org/jira/browse/WICKET-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232636#comment-13232636
]
Martin Grigorov commented on WICKET-4458:
-
Hi,
Can you test with 1.5.4 and verify that there is no problem with it ?
Did you run the tool described in the GF ticket
(https://blogs.oracle.com/quinn/entry/tool_for_diagnosing_failed_glassfish) ? I
see it should point where is the file leak.
Sorry for asking you to do these checks but I don't use neither GF nor Netbeans
and it will take me more time to setup and debug it.
> wicket-core-1.5.5.jar not closed when Application is undeployed from directory
> --
>
> Key: WICKET-4458
> URL: https://issues.apache.org/jira/browse/WICKET-4458
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>Reporter: bernard
>
> How to reproduce:
> - Create a 1.5.5 quickstart
> - deploy it on the GlassFish server with directory deployment (I use NetBeans
> which is easy)
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Error in GlassFish log:
> Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar
> I first thought that this was a GlassFish issue such as:
> http://java.net/jira/browse/GLASSFISH-17339
> To eliminate that, I added glassfish\modules\war-util.jar to the project and
> wrote code to let GlassFish close all jar files:
> In the Application class:
> @Override
> public void onDestroy() {
> super.onDestroy();
> ClassLoader parentClassLoader = this.getClass().getClassLoader();
> ClassLoader classLoader;
> do{
> classLoader = parentClassLoader;
> if(classLoader instanceof WebappClassLoader){
> WebappClassLoader glassFishLoader =
> (WebappClassLoader)classLoader;
> glassFishLoader.closeJARs(true);
> break;
> }
> parentClassLoader = classLoader.getParent();
> }while(parentClassLoader != classLoader && parentClassLoader != null);
>
> }
>
> but this did not fix the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4459) AjaxEditableMultiLineLabel doubles the html element on first edit
[ https://issues.apache.org/jira/browse/WICKET-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232602#comment-13232602 ] Martin Grigorov commented on WICKET-4459: - I've added a note to AjaxEditableMultiLineLabel's javadoc about this. > AjaxEditableMultiLineLabel doubles the html element on first edit > - > > Key: WICKET-4459 > URL: https://issues.apache.org/jira/browse/WICKET-4459 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Reporter: Radu Baranga >Assignee: Sven Meier > Attachments: fix-WICKET-4459.patch, quickstart.zip > > > Clicking on an AjaxEditableMultiLineLabel to edit it creates a new > AjaxEditableMultiLineLabel in edit mode instead of changing existing one to > Edit mode. Bug is present at least since wicket 1.5.3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3554) Constructor of org.apache.wicket.PageReference should be public
[ https://issues.apache.org/jira/browse/WICKET-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230010#comment-13230010 ] Martin Grigorov commented on WICKET-3554: - Store it where ? If you use PageReference instead of pageId in the parameters then it wont be bookmarkable anymore. > Constructor of org.apache.wicket.PageReference should be public > --- > > Key: WICKET-3554 > URL: https://issues.apache.org/jira/browse/WICKET-3554 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.15 >Reporter: Thomas Götz >Priority: Minor > > The construcor of PageReference is not accessible (no qualifier, proteced). > Is this for a reason? As far as I can see, a public qualifier would be nice > as I rather often created an own class with a similar implementation (because > I could not create an instance of PageReference). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-3554) Constructor of org.apache.wicket.PageReference should be public
[ https://issues.apache.org/jira/browse/WICKET-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1323#comment-1323 ] Martin Grigorov commented on WICKET-3554: - So you bring the page id in the request parameters and you prefer to call: page = new PageReference(pageIdInt).getPage() instead of page = getSession().getPageManager().getPage(pageIdInt) ? If there is no page with such id in the current session then expect PageExpiredException instead of null. I'll document this. > Constructor of org.apache.wicket.PageReference should be public > --- > > Key: WICKET-3554 > URL: https://issues.apache.org/jira/browse/WICKET-3554 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4.15 >Reporter: Thomas Götz >Priority: Minor > > The construcor of PageReference is not accessible (no qualifier, proteced). > Is this for a reason? As far as I can see, a public qualifier would be nice > as I rather often created an own class with a similar implementation (because > I could not create an instance of PageReference). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4452) Page id unique across sessions (or even globally unique)
[ https://issues.apache.org/jira/browse/WICKET-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229998#comment-13229998 ] Martin Grigorov commented on WICKET-4452: - Hi, What will that bring for you ? I don't see any benefit here. People are complaining about the "ugly" page id in the url even now. With UUID it will be even more ugly. With Random it will be just broken because you may see someone else's session. Can you explain what is the current problem ? I'll answer you separately in WICKET-3554. > Page id unique across sessions (or even globally unique) > > > Key: WICKET-4452 > URL: https://issues.apache.org/jira/browse/WICKET-4452 > Project: Wicket > Issue Type: Improvement >Reporter: Erik Godding Boye > > The page id (Page#numericId) is an integer originating from a session scoped > "sequence" (Session#pageId). This makes the page id only unique to the > session. > I think there are rationales for making the page id unique across sessions, > or even globally unique (using UUID i.e.). > One potential use case is described in the (closed) issue WICKET-3554. > Without breaking the API backwards compatibility, some uniqueness may be > introduced by using the Random class to generate pageIds. > But this can be greatly improved by changing the type of pageId from int to > String, and use the UUID class to generate globally unique identifiers, but > that will break the API compatibility -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4449) Change IValidationError API to work with java.io.Serializable as other methods (info, error, success, ...) in Component and Session
[
https://issues.apache.org/jira/browse/WICKET-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229330#comment-13229330
]
Martin Grigorov commented on WICKET-4449:
-
With this patch the user can do:
MyValidator#validate(IValidatable validatable) {
validatable.error(new MyValidationError(new MySerializableMessage()));
}
class MyValidationError implements IValidationError {
private Serializable ser;
public MyValidationError(Serializable ser) {
this.ser = ser;
}
public Serializable getErrorMessage() { return ser;}
}
> Change IValidationError API to work with java.io.Serializable as other
> methods (info, error, success, ...) in Component and Session
> ---
>
> Key: WICKET-4449
> URL: https://issues.apache.org/jira/browse/WICKET-4449
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 6.0.0
>Reporter: Martin Grigorov
>Assignee: Martin Grigorov
> Fix For: 6.0.0
>
> Attachments: WICKET-4449.patch
>
>
> Since a while o.a.w.Component's and o.a.w.Session #info(), #error(),
> #success(), etc. methods accept java.io.Serializable.
> With this ticket I suggest a change that will make
> o.a.w.validation.IValidationError in sync with this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4124) Link to examples on Wicket homepage still shows 1.4.18 examples
[
https://issues.apache.org/jira/browse/WICKET-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227631#comment-13227631
]
Martin Grigorov commented on WICKET-4124:
-
Now it points to http://www.wicket-library.com/wicket-examples/index.html which
is more stable and is updated regularly
> Link to examples on Wicket homepage still shows 1.4.18 examples
> ---
>
> Key: WICKET-4124
> URL: https://issues.apache.org/jira/browse/WICKET-4124
> Project: Wicket
> Issue Type: Task
>Reporter: Thomas Götz
>Assignee: Martin Grigorov
> Fix For: 1.5.6
>
>
> The link on http://wicket.apache.org/learn/examples ("live action") points to
> 1.4.18 examples. Those examples should be updated to the newest version.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4443) AbstractClassResolver recreates URL incorrectly
[ https://issues.apache.org/jira/browse/WICKET-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227530#comment-13227530 ] Martin Grigorov commented on WICKET-4443: - The suggestion is committed. > AbstractClassResolver recreates URL incorrectly > --- > > Key: WICKET-4443 > URL: https://issues.apache.org/jira/browse/WICKET-4443 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.4 >Reporter: Jesse Long >Assignee: Martin Grigorov > Labels: classloader > Fix For: 1.5.6, 6.0.0 > > Attachments: WICKET-4443.patch > > > AbstractClassResolver converts java.net.URLs to their external form > (java.lang.String), then converts them back to java.net.URLs. It looks like > the conversion to external form is for comparison between URLs (comparing > URLs is slow, Strings not so - see WICKET-3867), because we only want one > result per URL (Set). > The problem is that, when converting from the external form back to a > java.net.URL, the no context URL is given to the URL constructor, just the > external form String is given. Passing a context URL to the java.net.URL > constructor is the only way of setting the URLStreamHandler related to the > URL. So, if you have some exotic URL schema, like I do, using protocols the > standard Java libraries dont know about, you can no longer load your > resources. > Please see the code in CompoundClassResolver#getResources() - it implements a > unique list of URL by comparing the external forms of the URLs, while still > managing to use the original URL objects, with their URLStreamHandlers > attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4260) UrlRenderer renders invalid relative URLs if first segment contains colon
[ https://issues.apache.org/jira/browse/WICKET-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225073#comment-13225073 ] Martin Grigorov commented on WICKET-4260: - The patch looks quite simple. I'm +1 to commit it in 1.5.x/master once 1.5.5 is out so we can have enough time to test it in different browsers before 1.5.6 is out. > UrlRenderer renders invalid relative URLs if first segment contains colon > - > > Key: WICKET-4260 > URL: https://issues.apache.org/jira/browse/WICKET-4260 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.3 >Reporter: Andreas Köhler > Attachments: WICKET-4260.diff, WICKET-4260.path, wicket-4260.tar.bz2 > > > Seen on Wicket 1.5.3. > If a relative url of a link starts with a path segment containing a colon > then the whole uri will be regarded as absolute uri, so typically browsers > will complain that there is no handle for the protocol foo in foo:bar/dee/per. > See also the attached quickstart. The start page contains three links, one > relative with colon, one absolute and one to a mounted page without colon for > comparison. > The application also has a static switch to add an extended urlrenderer, > prepending "./" if needed. This fix is merely a quick shot and there might be > better alternatives. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4441) PageProvider should create a new Page instance if PageParameters are changed, even if a stored page exists.
[
https://issues.apache.org/jira/browse/WICKET-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224233#comment-13224233
]
Martin Grigorov commented on WICKET-4441:
-
I think this issue is Invalid.
Why: PageParameters is an object that contains the request GET parameters which
were available when the page instance was created. After that the subsequent
requests (like form submittion, link click, ...) may have their own parameters
which should not override the page's parameters. To get to those parameters you
should use getRequest().getRequestParameters().
To support your use case you need to re-read
getRequest().getRequestParameters() in onBeforeRender(). Or use CORS Model's
which read their values from getRequest().getRequestParameters() but write
somewhere else.
I agree that this is not very clear. And even Wicket makes it more confusing by
passing Attributes parameter to some callback methods which provide Request,
Response and PageParameters as inner objects. These PageParameters instances
are "the current request parameters", not the Page's parameters. But it is a
bit late to change that... :-/
> PageProvider should create a new Page instance if PageParameters are changed,
> even if a stored page exists.
> ---
>
> Key: WICKET-4441
> URL: https://issues.apache.org/jira/browse/WICKET-4441
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.5
> Environment: all platform.
>Reporter: Tsutomu YANO
> Attachments: fix-WICKET-4441.patch, pagebug.tar.gz
>
>
> The 'getStoredPage(int)' method returns a stored page instance even if user
> changes parameter values encoded into URL, and the PageParameters object of
> the stored page instance is never changed. So same page is displayed always
> though user changes url on browser manually.
> ** HOW TO REPRODUCT **
> 1. unpack the attached sample project 'pagebug.tar.gz'.
> 2. mvn jetty:run
> 3. access to http://localhost:8080/user/user1
> You will see a form filled with information about user 1. The user's name is
> 'user 1', age is 30 and country is 'Japan'.
> The mount path of this page is '/user/${userId}'. so 'user1' in the accessed
> url is a parameter value.
> after accessing to the url, the url will be changed to
> http://localhost:8080/user/user1?0 . it contains the page id of the
> currently displayed page.
> 4. change some values and submit the form. page id will be changed on every
> submit.
> 5. change only parameter value in url to 'user2'. Never change page-id.
> for example, if you now access to http://localhost:8080/user/user1?5, change
> the url to http://localhost:8080/user/user2?5 .
> 6. This program must display information about user2, because the parameter
> value of url is changed. But you will see the information of user 1. Wicket
> always display the page of page-id = 5 (even though user changed url
> manually).
> In this sample program, I use LoadableDetachableModel for retrieving current
> parameter-value. But I don't get the new parameter-value because
> pageParameters object in a page instance is never changed after the
> construction. pageParameters is fixed in the constructor of Page class.
> I think that there are no easy way to retrieve parameter-values encoded into
> mount-path. Request.getRequestParameters() does not contain parameters
> encoded into mount-path. So there are no work-around for this issue.
> ** HOW TO FIX THIS ISSUE **
> We must return null from getStoredPage(int) method of PageProvider class, if
> current PageParameters is not same with the PageParameters of a stored page.
> In current code, getStoredPage(int) checks only if the class of both pages
> are same. We must check the PageParameters of both pages.
> ** PATCH **
> I attached a pache for PageProvider class. try it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4439) Move classes around so that there are no two packages with the same name in different modules
[ https://issues.apache.org/jira/browse/WICKET-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224101#comment-13224101 ] Martin Grigorov commented on WICKET-4439: - Done. The changes are committed to branch sandbox/wicket4439. About the "endsWith(.classes)" - I did it this way to ignore META-INF folders and the files inside because they exist in all modules. Should I blacklist just them ? > Move classes around so that there are no two packages with the same name in > different modules > - > > Key: WICKET-4439 > URL: https://issues.apache.org/jira/browse/WICKET-4439 > Project: Wicket > Issue Type: Sub-task >Affects Versions: 6.0.0 >Reporter: Martin Grigorov >Priority: Minor > Fix For: 6.0.0 > > Attachments: OsgiPackageAnalyserScript.java, WICKET-4439-test.patch, > WICKET-4439.patch > > > There are several packages which appear in at least two wicket- modules. This > causes some troubles when deploying these modules in OSGi containers. > See http://markmail.org/message/e3isxaqirce2yyfd for more info. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4440) JavaScriptFilteredIntoFooterHeaderResponse breaks Javascript Order
[
https://issues.apache.org/jira/browse/WICKET-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223088#comment-13223088
]
Martin Grigorov commented on WICKET-4440:
-
Attach a quickstart please.
> JavaScriptFilteredIntoFooterHeaderResponse breaks Javascript Order
> --
>
> Key: WICKET-4440
> URL: https://issues.apache.org/jira/browse/WICKET-4440
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.5.3
>Reporter: Michael Frankerl
>
> When using {{JavaScriptFilteredIntoFooterHeaderResponse}} the order of
> aggregated javascript/resources is broken.
> This causes the script error {{Uncaught ReferenceError: Wicket is not
> defined}} in the resulting page.
> While scripts added with {{renderJavaScriptReference}} reside in the footer
> bucket, scripts added with {{renderJavaScript}} are in the {{}}.
> See {{AbstractDefaultAjaxBehavior.renderHead}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-1404) Investigate default focus support (on Page or RequestCycle)
[ https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221880#comment-13221880 ] Martin Grigorov commented on WICKET-1404: - I guess you are right :-) A question: should this behavior be used only for FormComponents or it should be extended to add 'tabindex' parameter for non-FormComponents to be able to focus such ? > Investigate default focus support (on Page or RequestCycle) > --- > > Key: WICKET-1404 > URL: https://issues.apache.org/jira/browse/WICKET-1404 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.1 >Reporter: James Carman >Priority: Minor > Attachments: WICKET-1404.patch > > > We need something which gives a component the focus when the page loads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-1404) Investigate default focus support (on Page or RequestCycle)
[ https://issues.apache.org/jira/browse/WICKET-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221560#comment-13221560 ] Martin Grigorov commented on WICKET-1404: - Is this really needed in -core ? it is quite simple to roll out yourself. I haven't seen anyone asking for this in the mailing lists.. > Investigate default focus support (on Page or RequestCycle) > --- > > Key: WICKET-1404 > URL: https://issues.apache.org/jira/browse/WICKET-1404 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 1.3.1 >Reporter: James Carman >Priority: Minor > Attachments: WICKET-1404.patch > > > We need something which gives a component the focus when the page loads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4433) Exception (Header was already written to response!) when setting response page in IRequestCycleListener
[
https://issues.apache.org/jira/browse/WICKET-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218037#comment-13218037
]
Martin Grigorov commented on WICKET-4433:
-
Yes, it seems onBeginRequest() is not covered to handle reset handler
exceptions ..
Here is a working code that does the same as what the exception would do:
public void onBeginRequest(RequestCycle cycle) {
IPageProvider provider = new PageProvider(PageTwo.class);
RenderPageRequestHandler requestHandler = new
RenderPageRequestHandler(provider) {
@Override
public void respond(IRequestCycle requestCycle)
{
requestCycle.getResponse().reset();
super.respond(requestCycle);
}
};
cycle.scheduleRequestHandlerAfterCurrent(requestHandler);
}
I'm not sure whether onBeginRequest() should be improved.
> Exception (Header was already written to response!) when setting response
> page in IRequestCycleListener
> ---
>
> Key: WICKET-4433
> URL: https://issues.apache.org/jira/browse/WICKET-4433
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Neil Curzon
> Attachments: myproject.zip, myproject.zip
>
>
> We have an IRequestCycleListener implementation that's basically:
> @Override
> public void onBeginRequest(RequestCycle cycle) {
> if ()) {
> cycle.setResponsePage(SpecificPage.class);
> }
> }
> This results in an exception when the condition is true, and the response
> page is set:
> java.lang.IllegalStateException: Header was already written to response!
> at
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.checkHeader(HeaderBufferingWebResponse.java:64)
> at
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.setDateHeader(HeaderBufferingWebResponse.java:134)
> at
> org.apache.wicket.protocol.http.BufferedWebResponse$SetDateHeaderAction.invoke(BufferedWebResponse.java:310)
> at
> org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:580)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:185)
> at
> org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:304)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4433) Exception (Header was already written to response!) when setting response page in IRequestCycleListener
[
https://issues.apache.org/jira/browse/WICKET-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217246#comment-13217246
]
Martin Grigorov commented on WICKET-4433:
-
I just answered you in the mailing list.
Use RestartResponseException instead.
> Exception (Header was already written to response!) when setting response
> page in IRequestCycleListener
> ---
>
> Key: WICKET-4433
> URL: https://issues.apache.org/jira/browse/WICKET-4433
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Neil Curzon
> Attachments: myproject.zip, myproject.zip
>
>
> We have an IRequestCycleListener implementation that's basically:
> @Override
> public void onBeginRequest(RequestCycle cycle) {
> if ()) {
> cycle.setResponsePage(SpecificPage.class);
> }
> }
> This results in an exception when the condition is true, and the response
> page is set:
> java.lang.IllegalStateException: Header was already written to response!
> at
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.checkHeader(HeaderBufferingWebResponse.java:64)
> at
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.setDateHeader(HeaderBufferingWebResponse.java:134)
> at
> org.apache.wicket.protocol.http.BufferedWebResponse$SetDateHeaderAction.invoke(BufferedWebResponse.java:310)
> at
> org.apache.wicket.protocol.http.BufferedWebResponse.writeTo(BufferedWebResponse.java:580)
> at
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:185)
> at
> org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:304)
> at
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:313)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4410) The datepicker components stops popup in Chrome 17.
[ https://issues.apache.org/jira/browse/WICKET-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215503#comment-13215503 ] Martin Grigorov commented on WICKET-4410: - YUI is updated to 2.9.0 in 1.5.x. Can you try whether your problem is gone there ? Or create a quickstart app that I can modify. See http://wicket.apache.org/start/quickstart.html > The datepicker components stops popup in Chrome 17. > > > Key: WICKET-4410 > URL: https://issues.apache.org/jira/browse/WICKET-4410 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4.19 > Environment: Windows XP 32bit, Google Chrome 17. >Reporter: Ilya Tepikin > Labels: chrome, datepicker > Attachments: QuickStartDatePicker.war, datepicker_chrome_bug.jpg > > Original Estimate: 2h > Remaining Estimate: 2h > > The datepicker components stops popup in Chrome 17. To reproduce bug follow > steps bellow: > 1) Fill in date in the input. > 2) Repeat some times cycle of show-hide. > Chome's Console will show error: > Uncaught TypeError: this is not a Date object. > YAHOO.widget.DateMath.clearTime calendar.js:1052 > Calendar.isDateOOB calendar.js:4037 > Calendar.select calendar.js:3702 > Wicket.DateTime.showCalendar wicket-date.js:154 > showCalendar wicket-date.js:180 > _addListener.wrappedFn event.js:937 > Surrounding code in clearTime js function (from calendar.js) with try/finally > bug fixes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4427) possible to bypass PackageResourceGuard
[ https://issues.apache.org/jira/browse/WICKET-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215479#comment-13215479 ] Martin Grigorov commented on WICKET-4427: - I cannot reproduce this problem. Please either attach a quickstart or a patch for org.apache.wicket.markup.html.SecurePackageResourceGuardTest that shows the problem. Thanks! > possible to bypass PackageResourceGuard > --- > > Key: WICKET-4427 > URL: https://issues.apache.org/jira/browse/WICKET-4427 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4.18 >Reporter: Sebastiaan van Erk > > It is possible to bypass the filters in the PackageResourceGuard by adding > %10, %13, or %20 to the end of the url, i.e., > http://my.site.com/myapp/mounted_package/myfile.properties%20 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4426) java.lang.ExceptionInInitializerError thrown when app on tomcat is restarted
[ https://issues.apache.org/jira/browse/WICKET-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214834#comment-13214834 ] Martin Grigorov commented on WICKET-4426: - Just tried with Tomcat 7.0.25 and all works fine. I guess there is an improvement in Tomcat since 6.0.13. Try with latest 6.x (6.0.30 I think) and with 7.0.26. We will reopen the ticket if you reproduce it with them. > java.lang.ExceptionInInitializerError thrown when app on tomcat is restarted > > > Key: WICKET-4426 > URL: https://issues.apache.org/jira/browse/WICKET-4426 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.3 > Environment: windows, tomcat 6.0.13, java 6 >Reporter: Tomek Szpinda > Labels: serialization, startup, tomcat > > The exception gets thrown while restarting app via jconsole in the deployment > mode on. > The application doesn't have any specific handing for page serialization, its > not clustered, "the only" non-standard thing is that it runs as a part of old > legacy app written in struts. > java.lang.ExceptionInInitializerError > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) > at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) > at java.lang.reflect.Field.getFieldAccessor(Field.java:899) > at java.lang.reflect.Field.getLong(Field.java:528) > at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614) > at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52) > at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425) > at java.security.AccessController.doPrivileged(Native Method) > at java.io.ObjectStreamClass.(ObjectStreamClass.java:413) > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310) > at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547) > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at java.util.ArrayList.readObject(ArrayList.java:593) > at sun.reflect.GeneratedMethodAccessor19271.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at java.io
[jira] [Commented] (WICKET-4065) Improve behavior#getStatelessHint() by accounting for the common cases when behaviors are not stateless
[
https://issues.apache.org/jira/browse/WICKET-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214549#comment-13214549
]
Martin Grigorov commented on WICKET-4065:
-
Isn't that true for components as well ?
A component may implement ILinkListener, IResourceListener or any other
specialization of IRequestListener. In this case this component should be
marked as stateful too.
So it is easy to add
if (this instanceof IRequestListener)
{
// this component implements a callback interface, so it cannot be
stateless
return false;
}
Is there any sense a Behavior to implement another specialization, e.g.
IResourceListener ? If yes then the check in Behavior#getStatelessHint() should
be updated to "this instanceof IRequestListener" as well.
> Improve behavior#getStatelessHint() by accounting for the common cases when
> behaviors are not stateless
> ---
>
> Key: WICKET-4065
> URL: https://issues.apache.org/jira/browse/WICKET-4065
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Reporter: Igor Vaynberg
>Assignee: Igor Vaynberg
>Priority: Minor
> Fix For: 6.0.0
>
>
> behavior#getStatelessHint() can check if behavior implements
> IBehaviorListener and if it does return false from stateless hint. also
> InvalidBehaviorIdException can point to getstatelesshint() being true when it
> should indeed be false as a probable cause for the error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4426) java.lang.ExceptionInInitializerError thrown when tomcat is restarted
[ https://issues.apache.org/jira/browse/WICKET-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213679#comment-13213679 ] Martin Grigorov commented on WICKET-4426: - How do you restart the app via jconsole ? Do you call some Tomcat JMX interface ? It seems that Tomcat uses different logic when restarted via JMX vs. normally. > java.lang.ExceptionInInitializerError thrown when tomcat is restarted > - > > Key: WICKET-4426 > URL: https://issues.apache.org/jira/browse/WICKET-4426 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.3 > Environment: windows, tomcat 6.0.13, java 6 >Reporter: Tomek Szpinda > Labels: serialization, startup, tomcat > > The exception gets thrown while restarting app via jconsole in the deployment > mode on. > The application doesn't have any specific handing for page serialization, its > not clustered, "the only" non-standard thing is that it runs as a part of old > legacy app written in struts. > java.lang.ExceptionInInitializerError > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) > at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) > at java.lang.reflect.Field.getFieldAccessor(Field.java:899) > at java.lang.reflect.Field.getLong(Field.java:528) > at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614) > at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52) > at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425) > at java.security.AccessController.doPrivileged(Native Method) > at java.io.ObjectStreamClass.(ObjectStreamClass.java:413) > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310) > at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547) > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at java.util.ArrayList.readObject(ArrayList.java:593) > at sun.reflect.GeneratedMethodAccessor19271.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) > at j
[jira] [Commented] (WICKET-2334) DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is restarted
[ https://issues.apache.org/jira/browse/WICKET-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213602#comment-13213602 ] Martin Grigorov commented on WICKET-2334: - Please open a separate ticket. This is an interesting issue. By default Wicket serializes the application name when serializing a page and uses it at deserialization time to deal with problems like this one. I guess this is not easy to reproduce with a quickstart... Can you give more details about your app - do you do something special regarding page serialization? Is there anything interesting about session replication? Etc.. > DebugBar throws an java.lang.ExceptionInInitializerError when Tomcat is > restarted > - > > Key: WICKET-2334 > URL: https://issues.apache.org/jira/browse/WICKET-2334 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.4-RC5 >Reporter: Zoltan Luspai >Assignee: Igor Vaynberg > Fix For: 1.4-RC6 > > > I have just added the DebugBar to our base page, and since then when Tomcat > is restarted and session would be reloaded by this it throws this exception: > 1ERROR org.apache.catalina.session.ManagerBase - Exception loading > sessions from persistent storage > java.lang.ExceptionInInitializerError > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) > at > sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918) > at java.lang.reflect.Field.getFieldAccessor(Field.java:899) > at java.lang.reflect.Field.getLong(Field.java:528) > at > java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614) > at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52) > at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425) > at java.security.AccessController.doPrivileged(Native Method) > at java.io.ObjectStreamClass.(ObjectStreamClass.java:413) > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310) > at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at > java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480) > at org.apache.wicket.Component.readObject(Component.java:4469) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) > at > java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at > java.util.concurrent.CopyOnWriteArrayList.readObject(CopyOnWri
[jira] [Commented] (WICKET-4407) Url segments in CryptoMapper may be larger than 260 chars => HTTP 400 - 'Bad request' when using IIS
[ https://issues.apache.org/jira/browse/WICKET-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213594#comment-13213594 ] Martin Grigorov commented on WICKET-4407: - Where exactly in the article did you see that changing 'UrlSegmentMaxLength' is extremely dangerous ? Windows is to play games on it. Don't use it for business :-) You can use your version of CryptoMapper if it serves you well. The current implementation of Wicket's CryptoMapper produces these urls to be able to handle relative urls in .css files (which are not manipulated by Wicket). Touching this logic will break a lot more applications already in production. I also don't like that Windows sys admins don't want to upgrade IE installations to something more modern and I have to write ugly hacks just to support strange problems in IE6/7/8 but ... C'est la vie :-/ Feel free to raise your problem at d...@wicket.apache.org. Maybe someone else will see a better solution. > Url segments in CryptoMapper may be larger than 260 chars => HTTP 400 - 'Bad > request' when using IIS > > > Key: WICKET-4407 > URL: https://issues.apache.org/jira/browse/WICKET-4407 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5.4 > Environment: IIS >Reporter: Jurriaan Pruys >Priority: Minor > Attachments: CryptoMapper.java > > > CryptoMapper encrypts the whole Url into a single segment. As a result the > encrypted url segment can be very long (> 260 characters). The default > maximum url segment size for IIS is 260 characters (see > http://support.microsoft.com/kb/820129). The warning note for changing this > default is "Changing this registry key is considered extremely dangerous. > This key causes Http.sys to use more memory and may increase vulnerability to > malicious attacks." > I've created my own CryptoMapper that puts the encrypted request in a request > parameter. This works fine, but it would be nice to have this as a > (configurable | default) behavior of CryptoMapper. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4410) The datepicker components stops popup in Chrome 17.
[ https://issues.apache.org/jira/browse/WICKET-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213588#comment-13213588 ] Martin Grigorov commented on WICKET-4410: - Currently wicket-datetime uses yui 2.8.1RC2. Looking at 2.9.0 (last from the 2.x series) changelog I don't see a fix which sounds like this problem. YUI team said that this is the last release of 2.x and it is recommended to use 3.x (3.4.1 at the moment). > The datepicker components stops popup in Chrome 17. > > > Key: WICKET-4410 > URL: https://issues.apache.org/jira/browse/WICKET-4410 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.4.19 > Environment: Windows XP 32bit, Google Chrome 17. >Reporter: Ilya Tepikin > Labels: chrome, datepicker > Attachments: QuickStartDatePicker.war, datepicker_chrome_bug.jpg > > Original Estimate: 2h > Remaining Estimate: 2h > > The datepicker components stops popup in Chrome 17. To reproduce bug follow > steps bellow: > 1) Fill in date in the input. > 2) Repeat some times cycle of show-hide. > Chome's Console will show error: > Uncaught TypeError: this is not a Date object. > YAHOO.widget.DateMath.clearTime calendar.js:1052 > Calendar.isDateOOB calendar.js:4037 > Calendar.select calendar.js:3702 > Wicket.DateTime.showCalendar wicket-date.js:154 > showCalendar wicket-date.js:180 > _addListener.wrappedFn event.js:937 > Surrounding code in clearTime js function (from calendar.js) with try/finally > bug fixes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request
[ https://issues.apache.org/jira/browse/WICKET-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213583#comment-13213583 ] Martin Grigorov commented on WICKET-4404: - I reproduced it by extracting the generated urls manually from the generated html. The problem is that you keep the generated callback url to the behavior in a String instance (i.e. you cache it) at com.test.wicket.menu.yui.YuiMenuBarItem#setUrl(). Initially the page is rendered for the home page url (i.e. '/') and at this time you cache the generated url. Then Wicket sees that this is a stateful page (its url needs the page id - ?0) and needs to regenerate the page html, but since you keep the url as a member which is rendered manually at com.test.wicket.menu.yui.YuiMenuBarItem#toJavascript() the url is not regenerated. Later when you request this url Wicket sees that it is stale and re-renders the whole page. I suggest you to create a Link-like Wicket component that generates its url (javascript:) whenever asked by Wicket (i.e. when #onComponentTag() is called). This way it will have the correct url. > CryptoMapper is not successfully decoding > AbstractDefaultAjaxBehavior.generateCallbackScript request > > > Key: WICKET-4404 > URL: https://issues.apache.org/jira/browse/WICKET-4404 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.4 > Environment: IE9 >Reporter: Josh Chappelle > Labels: 1.5, AbstractDefaultAjaxBehavior, cryptomapper, > generateCallbackScript, wicket > Attachments: HomePageSource.txt, wicket_cryptomapper_quickstart.zip > > > I have a yui menu wrapper that I have written that does not work when the > cryptomapper is being used. It works fine otherwise. It basically outputs > javascript in the header and that javascript renders the dom elements. So the > only wicket component is a div that represents the menu. All of the items get > generated by the javascript. One of the attributes on the menu item is a > "url" attribute. In the url attribute I have "javascript: " and then the > javascript string that is created via the generateCallbackScript method. The > respond method never gets called if the cryptomapper is enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4404) CryptoMapper is not successfully decoding AbstractDefaultAjaxBehavior.generateCallbackScript request
[ https://issues.apache.org/jira/browse/WICKET-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213563#comment-13213563 ] Martin Grigorov commented on WICKET-4404: - Sorry, I cannot run this quickstart. Just tried it again with Firefox 10 and no menu is being shown. just the link. The error in console is: Node cannot be inserted at the specified point in the hierarchy. In Chrome 19 the error is: HIERARCHY_REQUEST_ERR: DOM Exception 3. > CryptoMapper is not successfully decoding > AbstractDefaultAjaxBehavior.generateCallbackScript request > > > Key: WICKET-4404 > URL: https://issues.apache.org/jira/browse/WICKET-4404 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.4 > Environment: IE9 >Reporter: Josh Chappelle > Labels: 1.5, AbstractDefaultAjaxBehavior, cryptomapper, > generateCallbackScript, wicket > Attachments: HomePageSource.txt, wicket_cryptomapper_quickstart.zip > > > I have a yui menu wrapper that I have written that does not work when the > cryptomapper is being used. It works fine otherwise. It basically outputs > javascript in the header and that javascript renders the dom elements. So the > only wicket component is a div that represents the menu. All of the items get > generated by the javascript. One of the attributes on the menu item is a > "url" attribute. In the url attribute I have "javascript: " and then the > javascript string that is created via the generateCallbackScript method. The > respond method never gets called if the cryptomapper is enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4403) Go to page 1 when datatable is filtered
[ https://issues.apache.org/jira/browse/WICKET-4403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213489#comment-13213489 ] Martin Grigorov commented on WICKET-4403: - Can you provide a patch ? > Go to page 1 when datatable is filtered > --- > > Key: WICKET-4403 > URL: https://issues.apache.org/jira/browse/WICKET-4403 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.5.3 >Reporter: Rotschi Fanky >Priority: Trivial > > Go to the first page of a datatable when you filtered the data with a > IFilterStateLocator. Currently this is already implemented when you sort a > column. > When you're not on the first page and you filter the data, you go to the last > page available for the new data. This is confusing and ugly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4425) Wicket 1.5 rewrites template content where it should not
[ https://issues.apache.org/jira/browse/WICKET-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212796#comment-13212796 ] Martin Grigorov commented on WICKET-4425: - The developer should not be aware of the fact that Wicket uses XML to deliver the HTML response in Ajax response. This CDATA is there exactly for this reason - to allow DOMParser (JS) to create a proper JS Document no matter what is the actual content. Additionally is a valid by HTML specs but some browsers don't behave well with with. And Wicket tries to help in this situation as well, by expanding it to . I'll commit this patch soon if there are no technical problems with it. > Wicket 1.5 rewrites template content where it should not > > > Key: WICKET-4425 > URL: https://issues.apache.org/jira/browse/WICKET-4425 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.5.4 >Reporter: Pointbreak >Assignee: Martin Grigorov > Attachments: WICKET-4425.patch, myproject.zip > > > I have recently upgraded from Wicket 1.4.14 to 1.5.4. One issue that I > encountered is that tags in panel templates are rewritten by > Wicket, even when the