[jira] Created: (WICKET-1975) Allow custom form components to be more easily created by removing final from certain methods.
Allow custom form components to be more easily created by removing final from certain methods. -- Key: WICKET-1975 URL: https://issues.apache.org/jira/browse/WICKET-1975 Project: Wicket Issue Type: Improvement Components: wicket Reporter: Larry Zappaterrini Priority: Minor I was perusing Wicket's Javadocs and I came across a link to an old thread: http://www.nabble.com/Why-add%28IBehavior%29-is-final--td7248198.html#a7248198 The issue in that message thread was resolved by WICKET-94 with the final modifier being removed from from Component#add(IBehavior). I am currently trying to do something similar to the original author of the thread and I believe the same concession should be extended to FormComponent#add(IValidator) and FormComponent#setFieldType(Class) due to similar arguments. In fact, might it make sense to look though the public final methods of FormComponent and only make final those that are absolutely necessary from an encapsulation standpoint? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1620) Portlet 2.0 support
[ https://issues.apache.org/jira/browse/WICKET-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654837#action_12654837 ] Antony Stubbs commented on WICKET-1620: --- Sorry Ate, to what does the patch apply cleanly to? I'm having some trouble patching trunk with it. > Portlet 2.0 support > --- > > Key: WICKET-1620 > URL: https://issues.apache.org/jira/browse/WICKET-1620 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Thijs Vonk >Assignee: Ate Douma > Attachments: myWicketPortal20Patch-example-project.patch, > myWicketPortal20Patch-v2.patch, > myWicketPortal20Patch-v3-example-project.patch, > myWicketPortal20Patch-v3.patch, portlet2-0.patch, portlet2-0.patch, > WICKET-1620-portlet2.0.patch > > > Upgrade wicket to fully support portlet 2.0 (jsr 286; > http://jcp.org/en/jsr/detail?id=286). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1972) site does not forward to index.html
[ https://issues.apache.org/jira/browse/WICKET-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst closed WICKET-1972. Resolution: Cannot Reproduce Works for me... > site does not forward to index.html > --- > > Key: WICKET-1972 > URL: https://issues.apache.org/jira/browse/WICKET-1972 > Project: Wicket > Issue Type: Bug > Components: site >Reporter: Jay Bose > > When you go to http://wicket.apache.org/, you see a blank page, rather than > being redirected to a default index page. > I assume the correct behavior would be to forward to > http://wicket.apache.org/index.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1971) AjaxSelfUpdatingBehavior problem with HttpSessionStore
[
https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654757#action_12654757
]
Henk Leermakers commented on WICKET-1971:
-
I agree this is a serious issue and should be fixed with high priority ! Users
of applications suffering with this problem are getting frustrated. Submit's
will end with "page expired" or alternatively ajax processes just don't do
anything.
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> --
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.5
>Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is
> PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired
> by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed
> back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user
> pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
>if (pageId != access.getId())
>{
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
>}
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ?
> wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
>
> ERROR: Error while parsing response: Could not find root
> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens,
> AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But
> instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was
> added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on
> previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put
> an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link
> and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way
> this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this
> happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Description:
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the first
char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading "/" from the
buffer id when present
-2- or alternatively, remove the leading "/" from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
* Note: use this only when WickterFilter listens on the root context.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return "/";
}
@Override
public String getRelativePathPrefixToContextRoot() {
return "/";
}
}
was:
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the first
char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading "/" from the
buffer id when present
-2- or alternatively, remove the leading "/" from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return "/";
}
@Override
public String getRelativePathPrefixToContextRoot() {
return "/";
}
}
> render_to_buffer does not work for absolute URLs
>
>
> Key: WICKET-1974
> URL: https://issues.apache.org/jira/browse/WICKET-1974
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> After installing a WebRequest instance that makes all URLs absolute,
> render_to_buffer does not work anymore. The problem is that WicketFilter
> assumes that all URLs are relative (WebFilter#getRelativePath removes the
> first char of the URL).
> Proposed fixes:
> -1- in WebApplication#addBufferedResponse remove the leading "/" from the
> buffer id when present
> -2- or alternatively, remove the leading "/" from the URL (when present) in
> WebRequestCycle, just before addBudderedResponse is called
> Here is the installed AbsoluteServletWebRequest:
> /**
> * WebServletRequest that makes bookmarkable links absolute.
> * Note: use this only when WickterFilter listens on the root context.
> *
> * @author Erik van Oosten
> */
> public class AbsoluteServletWebRequest extends ServletWebRequest {
> public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
> super(servletRequest);
> }
> @Override
> public int getDepthRelativeToWicketHandler() {
> return 0;
> }
> @Override
> public String getRelativePathPrefixToWicketHandler() {
> return "/";
> }
> @Override
> public String getRelativePathPrefixToContextRoot() {
> return "/";
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1974) render_to_buffer does not work for absolute URLs
render_to_buffer does not work for absolute URLs
Key: WICKET-1974
URL: https://issues.apache.org/jira/browse/WICKET-1974
Project: Wicket
Issue Type: Improvement
Components: wicket, wicket-auth-roles
Affects Versions: 1.4-RC1
Reporter: Erik van Oosten
After installing a WebRequest instance that makes all URLs absolute,
render_to_buffer does not work anymore. The problem is that WicketFilter
assumes that all URLs are relative (WebFilter#getRelativePath removes the first
char of the URL).
Proposed fixes:
-1- in WebApplication#addBufferedResponse remove the leading "/" from the
buffer id when present
-2- or alternatively, remove the leading "/" from the URL (when present) in
WebRequestCycle, just before addBudderedResponse is called
Here is the installed AbsoluteServletWebRequest:
/**
* WebServletRequest that makes bookmarkable links absolute.
*
* @author Erik van Oosten
*/
public class AbsoluteServletWebRequest extends ServletWebRequest {
public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
super(servletRequest);
}
@Override
public int getDepthRelativeToWicketHandler() {
return 0;
}
@Override
public String getRelativePathPrefixToWicketHandler() {
return "/";
}
@Override
public String getRelativePathPrefixToContextRoot() {
return "/";
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Component/s: (was: wicket-auth-roles)
> render_to_buffer does not work for absolute URLs
>
>
> Key: WICKET-1974
> URL: https://issues.apache.org/jira/browse/WICKET-1974
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4-RC1
>Reporter: Erik van Oosten
>
> After installing a WebRequest instance that makes all URLs absolute,
> render_to_buffer does not work anymore. The problem is that WicketFilter
> assumes that all URLs are relative (WebFilter#getRelativePath removes the
> first char of the URL).
> Proposed fixes:
> -1- in WebApplication#addBufferedResponse remove the leading "/" from the
> buffer id when present
> -2- or alternatively, remove the leading "/" from the URL (when present) in
> WebRequestCycle, just before addBudderedResponse is called
> Here is the installed AbsoluteServletWebRequest:
> /**
> * WebServletRequest that makes bookmarkable links absolute.
> *
> * @author Erik van Oosten
> */
> public class AbsoluteServletWebRequest extends ServletWebRequest {
> public AbsoluteServletWebRequest(HttpServletRequest servletRequest) {
> super(servletRequest);
> }
> @Override
> public int getDepthRelativeToWicketHandler() {
> return 0;
> }
> @Override
> public String getRelativePathPrefixToWicketHandler() {
> return "/";
> }
> @Override
> public String getRelativePathPrefixToContextRoot() {
> return "/";
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1973) Messages lost upon session failover with redirect_to_buffer
Messages lost upon session failover with redirect_to_buffer --- Key: WICKET-1973 URL: https://issues.apache.org/jira/browse/WICKET-1973 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten Using the redirect_to_buffer render strategy, messages in the session get cleared after the render. If the redirected request comes in at another node, the buffer is not found and the page is re-rendered. In this case the messages are no longer available. See the javadoc of WebApplication#popBufferedResponse(String,String). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
