[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:
Attachment: WICKET-1974.patch
This patch will remove the leading / from the buffer id (when present) in
WebApplication#addBufferedResponse.
mvn test
runs fine.
Please apply to wicket 1.4 branch.
If trunk is still similar, please apply there to.
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
Attachments: WICKET-1974.patch
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] Updated: (WICKET-1974) render_to_buffer does not work for absolute URLs (with patch)
[
https://issues.apache.org/jira/browse/WICKET-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik van Oosten updated WICKET-1974:
Summary: render_to_buffer does not work for absolute URLs (with patch)
(was: render_to_buffer does not work for absolute URLs)
render_to_buffer does not work for absolute URLs (with patch)
-
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
Attachments: WICKET-1974.patch
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-2404) Quickstart for 1.4 uses 1.3 dtd in HomePage.html
Quickstart for 1.4 uses 1.3 dtd in HomePage.html Key: WICKET-2404 URL: https://issues.apache.org/jira/browse/WICKET-2404 Project: Wicket Issue Type: Bug Components: wicket-quickstart Affects Versions: 1.4.0 Reporter: Erik van Oosten Priority: Trivial The generated HomePage.html contains the following header: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.3-strict.dtd; That should be: html xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC5 -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2332: Attachment: WICKET-2332.patch Please apply path in trunk. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC5 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721107#action_12721107 ] Erik van Oosten edited comment on WICKET-2332 at 6/18/09 12:25 AM: --- Please apply patch in trunk. was (Author: erikvanoosten): Please apply path in trunk. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC5 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2332: Fix Version/s: (was: 1.4-RC5) 1.4-RC6 Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC6 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721143#action_12721143 ] Erik van Oosten commented on WICKET-2332: - Hmm, perhaps org.apache.wicket.markup.Markup.makeImmutable() should be made public as well. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC6 Attachments: WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2332) Open up Markup ctor and MarkupContainer#renderNext
[ https://issues.apache.org/jira/browse/WICKET-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2332: Attachment: WICKET-2332-2.patch Second patch also makes org.apache.wicket.markup.Markup.makeImmutable() public. Again, please apply in trunk. Open up Markup ctor and MarkupContainer#renderNext -- Key: WICKET-2332 URL: https://issues.apache.org/jira/browse/WICKET-2332 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC4 Reporter: Erik van Oosten Fix For: 1.4-RC6 Attachments: WICKET-2332-2.patch, WICKET-2332.patch -1- Change org.apache.wicket.markup.Markup#Markup(): from default to public -2- Change org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (it stays final) Rationale from the dev e-mail list: Erik van Oosten wrote: --- Hi, I am writing a Swing like layout manager (with MIG layout manager's API as inspiration). The layout manager will generate HTML, but also has the ability to override this with HTML defined by the user. I have a prototype that does this. It takes elements from the current Markupstream, adds the elements that are missing, and then some more to facilitate the layouting (well the last step is next on my todo list). These elements are then put in a new markupstream that is used to drive onComponentTagBody of the layout component. For this to work I had to open up 2 things: - org.apache.wicket.markup.Markup#Markup(): from default to public I could have written my own implementation of IMarkup, but that seems a bit overkill as I need exactly what is in Markup. - org.apache.wicket.MarkupContainer#renderNext(MarkupStream): from private to protected (don't care if it stays final) My onComponentTagBody implementation is loosely based on method org.apache.wicket.MarkupContainer#renderAssociatedMarkup(String,String). One of the methods I need to call to render children seems to be renderNext. Could these two be opened up? --- Juergen Donnerstag wrote: --- I don't mind open up both, as long as renderNext() stays final and we tag it as THIS IS WICKET INTERNAL. --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IBATIS-609) ibator does not support generics in javaType attribute
[
https://issues.apache.org/jira/browse/IBATIS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720516#action_12720516
]
Erik van Oosten commented on IBATIS-609:
I realize that :) , I am using a TypeHandler to convert a comma separated
varchar to a Set.
ibator does not support generics in javaType attribute
--
Key: IBATIS-609
URL: https://issues.apache.org/jira/browse/IBATIS-609
Project: iBatis for Java
Issue Type: Bug
Components: Tools
Reporter: Erik van Oosten
Assignee: Jeff Butler
I tried to define a SetUserRole, however ibator seems to mangle the
javatype.
For example the following definition:
table tableName=USER .
columnOverride column=ROLES
javaType=java.util.Setlt;com.example.UserRolegt; jdbcType=NVARCHAR2/
/table
Leads to the following generated code:
class User {
private com.example.UserRole roles;
}
expected was:
class User {
private java.util.Setcom.example.UserRole roles;
}
Tested with ibator 1.2.2-SNAPSHOT of around 2009-06-16.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2292) TabbedPanel uses too much generics (revert Wicket-2135)
TabbedPanel uses too much generics (revert Wicket-2135) --- Key: WICKET-2292 URL: https://issues.apache.org/jira/browse/WICKET-2292 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Fix For: 1.4-RC5 Please revert Wicket-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve Wicket-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2292) TabbedPanel uses too much generics (revert WICKET-2135)
[ https://issues.apache.org/jira/browse/WICKET-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2292: Description: Please revert WICKET-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. was: Please revert Wicket-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve Wicket-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. Summary: TabbedPanel uses too much generics (revert WICKET-2135) (was: TabbedPanel uses too much generics (revert Wicket-2135)) TabbedPanel uses too much generics (revert WICKET-2135) --- Key: WICKET-2292 URL: https://issues.apache.org/jira/browse/WICKET-2292 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Fix For: 1.4-RC5 Please revert WICKET-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2292) TabbedPanel uses too much generics (revert WICKET-2153)
[ https://issues.apache.org/jira/browse/WICKET-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-2292: Description: Please revert WICKET-2153. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2153, the user should cast his/her list to ListITab or just create a list of that type in the first place. was: Please revert WICKET-2135. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2135, the user should cast his/her list to ListITab or just create a list of that type in the first place. Summary: TabbedPanel uses too much generics (revert WICKET-2153) (was: TabbedPanel uses too much generics (revert WICKET-2135)) TabbedPanel uses too much generics (revert WICKET-2153) --- Key: WICKET-2292 URL: https://issues.apache.org/jira/browse/WICKET-2292 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Fix For: 1.4-RC5 Please revert WICKET-2153. By declaring the list of tabs as List? extends ITab you are saying that the list contains elements with some super type that is a subtype of ITab. Having this type there is no way of knowing which exact supertype that is, just that it is a subclass of ITab. The result is that you can only add null to the list. Of course this is non-sense; TabbedPanel uses ITab and not some unknown subclass thereof. To demonstrate: right now you can not do: ITab tab = ...; tabbedPanel.getTabs().add(tab); To properly solve WICKET-2153, the user should cast his/her list to ListITab or just create a list of that type in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2288) Refactor DefaultPageFactory#constructor
[ https://issues.apache.org/jira/browse/WICKET-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712425#action_12712425 ] Erik van Oosten commented on WICKET-2288: - BTW, the default ctor instances could be cached as well, but that is definitely outside the scope of this issue. Refactor DefaultPageFactory#constructor --- Key: WICKET-2288 URL: https://issues.apache.org/jira/browse/WICKET-2288 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC3 Reporter: Erik van Oosten Priority: Trivial Original Estimate: 0.03h Remaining Estimate: 0.03h Method DefaultPageFactory#constructor should loose the second parameter (argumentType) as it looks up cached Constructor instances without regard of the argument type. Instead the type (always PageParameters.class) should be hard coded in DefaultPageFactory#constructor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2040) Wrong log message text in RequestCycle#prepare
Wrong log message text in RequestCycle#prepare -- Key: WICKET-2040 URL: https://issues.apache.org/jira/browse/WICKET-2040 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten Priority: Trivial In RequestCycle#prepare it says: log.error(Exception occurred during onEndRequest of the SessionStore, e); This should be: log.error(Exception occurred during onBeginRequest of the SessionStore, e); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2025) isVisible should not be called after detach
isVisible should not be called after detach --- Key: WICKET-2025 URL: https://issues.apache.org/jira/browse/WICKET-2025 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten I think isVisible should not be called after detach to prevent model reloads. I found one call to isVisible after detach in method ComponentRequestTarget#respond(RequestCycle). That method initiates a detach and then calls page.endComponentRender. This leads to a call to Page#checkRendering which calls isVisibleInHierarchy() and from there isVisible(). Method checkRendering only does something when the debug setting 'componentUseCheck' is enabled (which according to the javadoc is true by default). Short term workaround: set debug setting 'componentUseCheck' to false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2025) isVisible should not be called after detach
[ https://issues.apache.org/jira/browse/WICKET-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12664533#action_12664533 ] Erik van Oosten commented on WICKET-2025: - In that case the javadoc of IDebugSettings needs an update. It does not change the importance of this issue. isVisible should not be called after detach --- Key: WICKET-2025 URL: https://issues.apache.org/jira/browse/WICKET-2025 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Erik van Oosten I think isVisible should not be called after detach to prevent model reloads. I found one call to isVisible after detach in method ComponentRequestTarget#respond(RequestCycle). That method initiates a detach and then calls page.endComponentRender. This leads to a call to Page#checkRendering which calls isVisibleInHierarchy() and from there isVisible(). Method checkRendering only does something when the debug setting 'componentUseCheck' is enabled (which according to the javadoc is true by default). Short term workaround: set debug setting 'componentUseCheck' to false. -- 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.
[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-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:
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] Commented: (WICKET-1878) ExternalLink should have title field
[
https://issues.apache.org/jira/browse/WICKET-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643227#action_12643227
]
Erik van Oosten commented on WICKET-1878:
-
Proposed solution: Won't fix.
Wicket should stay clean and mean. Adding these kinds of options all over the
place won't help achive this goal.
Here is a custom component that reaches the comitters goal with a custom
component.
public abstract class TitledLink extends Link {
public TitledLink(String id, String title) {
this(id, new ModelString(title));
}
public TitledLink(String id, IModelString titleModel) {
super(id);
add(new AttributeModifier(title, true, titleModel));
}
}
ExternalLink should have title field
Key: WICKET-1878
URL: https://issues.apache.org/jira/browse/WICKET-1878
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.4, 1.4-M3
Reporter: Steve Swinsburg
The ExternalLink component should either by default have a title field, or
have another constructor that takes the title as a paremeter. Currently this
is only achieved by using AttributeAppender and setting the title attribute
onto the link.
eg current:
ExternalLink emailLink = new ExternalLink(mailToLink,new Model(mailto:; +
emailAddress),new Model(emailAddress));
emailLink.add(new AttributeAppender(title, new Model(emailAddress), ));
I propose the following constructor:
ExternalLink(java.lang.String id, java.lang.String href, java.lang.String
label, java.lang.String title)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635118#action_12635118 ] Erik van Oosten commented on WICKET-1355: - Okay. I'll try. I'll be a JAOO so it has to wait till Thursday though. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Igor Vaynberg Fix For: 1.3.5 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1746) gecko: ajax javascript reference rendering problem
[
https://issues.apache.org/jira/browse/WICKET-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634772#action_12634772
]
Erik van Oosten commented on WICKET-1746:
-
As a workaround, add the following behavior to your page (javascript based on
wicket 1.3.4):
private static class WicketAjaxRelativePathFixBehaviour extends AbstractBehavior
{
private static final long serialVersionUID = 1L;
@Override
public void renderHead(IHeaderResponse response)
{
String script = if (Wicket Wicket.Ajax
Wicket.Ajax.Request) {+
Wicket.Ajax.Request.prototype.doGet =
function() { +
if (this.precondition()) { +
this.transport =
Wicket.Ajax.getTransport(); +
var url = this.createUrl(); +
this.log(\GET\, url); +
Wicket.Ajax.invokePreCallHandlers(); +
var t = this.transport; +
if (t != null) { +
t.open(\GET\, url,
this.async); +
t.onreadystatechange =
this.stateChangeCallback.bind(this); +
/*set a special flag to
allow server distinguish between ajax and non-ajax requests*/ +
t.setRequestHeader(\Wicket-Ajax\, \true\); +
t.setRequestHeader(\Wicket-FocusedElementId\, Wicket.Focus.lastFocusId ||
\\); +
t.setRequestHeader(\Accept\, \text/xml\); +
t.send(null); +
return true; +
} else { +
this.failure(); +
return false; +
} +
} else { +
Wicket.Log.info(\Ajax GET
stopped because of precondition check, url:\ + this.url); +
this.done(); +
return true; +
} +
}};
response.renderOnDomReadyJavascript(script);
}
}
gecko: ajax javascript reference rendering problem
--
Key: WICKET-1746
URL: https://issues.apache.org/jira/browse/WICKET-1746
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4-M2
Reporter: Jan Loose
Assignee: Matej Knopp
Fix For: 1.3.5, 1.4-M4
Hi,
i tried render the javascript as:
public void renderHead(IHeaderResponse response) {
response.renderJavascriptReference(contextPath + js/test.js);
}
The test.js is in webapp/js/test.js (out of classpath). All works greatly in
Opera but in FF (gecko) is there a problem in wicket-ajax.js (the code is
form trunk version):
836: if (Wicket.Browser.isGecko()) {
837: var href = document.location.href;
838: var lastIndexOf = href.lastIndexOf('/');
839: if (lastIndexOf 0)
840: {
841: url = href.substring(0,lastIndexOf+1) + url;
842:}
843:}
Why is there this fix/workaround? This works only for relative path but for
absolute is this code broken.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1349) Wicket Ajax response generates a ^ character in the javascript code
[
https://issues.apache.org/jira/browse/WICKET-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12629479#action_12629479
]
Erik van Oosten commented on WICKET-1349:
-
Note, the code above will also require changes in the ajax code. The ajax code
currently only retrieves the first text node for every type of response, with
the escaping from above it should get all text nodes and concatenate them (like
a XPath query would do). Actually, you should *always* get all text nodes as
most XML DOM parsers (if not, all) do not guarantee that they put all
consecutive text in a single text node.
The fix above is not complete, it should also give back another encoding string
(method getEncodingName()).
Wicket Ajax response generates a ^ character in the javascript code
-
Key: WICKET-1349
URL: https://issues.apache.org/jira/browse/WICKET-1349
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Environment: IE6 and IE7
Reporter: Wen Tong Allan
Assignee: Igor Vaynberg
I have a page that uses AjaxFallbackDefaultDataTable (using
SortableDataProvider ). The markup contains user-define javascript that I
added. When I try to do some action (delete row) with the table, the page
doesn't refresh in IE6 and IE7. I checked the Wicket Ajax Debugger and it
displays:
ERROR: Error while parsing response: Object required
INFO: Invoking post-call handler(s)...
INFO: invoking failure handler(s)...
I also noticed that the user-define javascript that was returned by the ajax
debugger was appended by ^. (See javascript below):
// enable disable button.
function setButtonState() {
var formObj =
eval(document.getElementsByName(contactListForm)[0]^);
var state = anyChecked(formObj);
document.getElementsByName(deleteContactsButton)[0]^.disabled = !state;
document.getElementsByName(newContactGroupButton)[0]^.disabled = !state;
document.getElementsByName(newEventButton)[0]^.disabled
= !state;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-847) setResponsePage redirects to wrong url
[
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628320#action_12628320
]
Erik van Oosten commented on WICKET-847:
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My patch is:
In BookmarkablePageRequestTarget:
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
And in RedirectRequestTarget:
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
RequestContext rc = RequestContext.get();
if (rc.isPortletRequest()
((PortletRequestContext)rc).isEmbedded())
{
response.redirect(redirectUrl);
}
else
{
String location = RequestCycle.get()
.getRequest()
.getRelativePathPrefixToContextRoot() +
this.redirectUrl.substring(1);
// START OF PATCH
if (location.startsWith(./)) {
location = location.substring(2);
}
// END OF PATCH
response.redirect(location);
}
}
else if (redirectUrl.startsWith(http://;) ||
redirectUrl.startsWith(https://;))
{
response.redirect(redirectUrl);
}
else
{
response.redirect(RequestCycle.get()
.getRequest()
.getRelativePathPrefixToWicketHandler() +
redirectUrl);
}
}
setResponsePage redirects to wrong url
--
Key: WICKET-847
URL: https://issues.apache.org/jira/browse/WICKET-847
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.0-beta2
Reporter: Andrew Klochkov
Assignee: Alastair Maw
Fix For: 1.3.5
Attachments: wicket-quickstart.tar.gz
When I do setResponsePage(MyHomePage.class) IE tries to show me
my.site.com/./ url and gets 404 response.
Firefox just shows my.site.com without any troubles. I'm using wicket
1.3-beta2 and WicketFilter mapped to /*.
It's being reproduced under tomcat only, jetty works fine. My tomcat version
is 5.5.17.
Quickstart project which reproduces the bug is attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-847) setResponsePage redirects to wrong url
[
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628320#action_12628320
]
erikvanoosten edited comment on WICKET-847 at 9/4/08 5:03 AM:
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My workaround was to patch these two Wicket core files (I can confirm it works):
BookmarkablePageRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
---8--
RedirectRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
RequestContext rc = RequestContext.get();
if (rc.isPortletRequest()
((PortletRequestContext)rc).isEmbedded())
{
response.redirect(redirectUrl);
}
else
{
String location = RequestCycle.get()
.getRequest()
.getRelativePathPrefixToContextRoot() +
this.redirectUrl.substring(1);
// START OF PATCH
if (location.startsWith(./)) {
location = location.substring(2);
}
// END OF PATCH
response.redirect(location);
}
}
else if (redirectUrl.startsWith(http://;) ||
redirectUrl.startsWith(https://;))
{
response.redirect(redirectUrl);
}
else
{
response.redirect(RequestCycle.get()
.getRequest()
.getRelativePathPrefixToWicketHandler() +
redirectUrl);
}
}
---8--
was (Author: erikvanoosten):
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My patch is:
In BookmarkablePageRequestTarget:
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
And in RedirectRequestTarget:
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
[jira] Issue Comment Edited: (WICKET-847) setResponsePage redirects to wrong url
[
https://issues.apache.org/jira/browse/WICKET-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628320#action_12628320
]
erikvanoosten edited comment on WICKET-847 at 9/4/08 5:03 AM:
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My workaround was to patch these two Wicket core files (I can confirm it works
when redirecting to the home page):
BookmarkablePageRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
---8--
RedirectRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
Response response = requestCycle.getResponse();
response.reset();
if (redirectUrl.startsWith(/))
{
RequestContext rc = RequestContext.get();
if (rc.isPortletRequest()
((PortletRequestContext)rc).isEmbedded())
{
response.redirect(redirectUrl);
}
else
{
String location = RequestCycle.get()
.getRequest()
.getRelativePathPrefixToContextRoot() +
this.redirectUrl.substring(1);
// START OF PATCH
if (location.startsWith(./)) {
location = location.substring(2);
}
// END OF PATCH
response.redirect(location);
}
}
else if (redirectUrl.startsWith(http://;) ||
redirectUrl.startsWith(https://;))
{
response.redirect(redirectUrl);
}
else
{
response.redirect(RequestCycle.get()
.getRequest()
.getRelativePathPrefixToWicketHandler() +
redirectUrl);
}
}
---8--
was (Author: erikvanoosten):
I got bitten by this as well (with 1.4-m3).
The failing combination is: Tomcat and IE (6 or 7).
Firefox correctly interprets the ./ as so its okay to use Firefox + Tomcat.
Jetty converts ./ to , so its okay to use any borwser on Jetty.
My workaround was to patch these two Wicket core files (I can confirm it works):
BookmarkablePageRequestTarget:
---8--
public void respond(RequestCycle requestCycle)
{
if (pageClassRef != null pageClassRef.get() != null)
{
if (requestCycle.isRedirect())
{
IRequestCycleProcessor processor =
requestCycle.getProcessor();
String redirectUrl =
processor.getRequestCodingStrategy()
.encode(requestCycle, this)
.toString();
// START OF PATCH
if (redirectUrl.startsWith(./)) {
redirectUrl = redirectUrl.substring(2);
}
// END OF PATCH
requestCycle.getResponse().redirect(redirectUrl);
}
else
{
// Let the page render itself
getPage(requestCycle).renderPage();
}
}
}
---8--
RedirectRequestTarget:
---8--
public void
[jira] Commented: (WICKET-1449) './' appended to URL causes HTTP 404 in Internet Explorer (using root context)
[
https://issues.apache.org/jira/browse/WICKET-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628321#action_12628321
]
Erik van Oosten commented on WICKET-1449:
-
Duplicate of WICKET-847.
I would rate this issue as a blocker as well.
'./' appended to URL causes HTTP 404 in Internet Explorer (using root context)
--
Key: WICKET-1449
URL: https://issues.apache.org/jira/browse/WICKET-1449
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Environment: Wicket 1.3.2
JBoss 4.0/Jetty 6.1.7
JDK 1.6.0_03
Reporter: Will Hoover
Assignee: Alastair Maw
Fix For: 1.3.5
Original Estimate: 72h
Remaining Estimate: 72h
SYNOPSIS:
1) Web application is using the root context (/)
1) form.add(new Button(mybutton));
2) Button is clicked on any WebPage that is NOT MOUNTED
ISSUE:
WebRequestCodingStrategy.encode appends './' to the URL. The page is
redirected to http://www.mysite.com/./; It works fine in Firefox and Opera,
but in IE an HTTP 404 ('.' page is not found) is rendered.
Mounting the home page to something like '/home' solved the problem ('./' is
not appended, but this causes a redirect every time a use hits the page).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1349) Wicket Ajax response generates a ^ character in the javascript code
[
https://issues.apache.org/jira/browse/WICKET-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625300#action_12625300
]
Erik van Oosten commented on WICKET-1349:
-
We are using AjaxRequestTarget while at the client side we use jquery only and
therefore also have problems with the '^' in the raw stream.
By replacing the AjaxRequestTarget#encode method with the following, you get
proper XML escaping.
/**
* Encodes a string so it is safe to use inside CDATA blocks
*
* @param str
* @return encoded string
*/
protected String encode(String str)
{
if (str == null)
{
return null;
}
return Strings.replaceAll(str, ], ]]]![CDATA[).toString();
}
Wicket Ajax response generates a ^ character in the javascript code
-
Key: WICKET-1349
URL: https://issues.apache.org/jira/browse/WICKET-1349
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Environment: IE6 and IE7
Reporter: Wen Tong Allan
Assignee: Igor Vaynberg
I have a page that uses AjaxFallbackDefaultDataTable (using
SortableDataProvider ). The markup contains user-define javascript that I
added. When I try to do some action (delete row) with the table, the page
doesn't refresh in IE6 and IE7. I checked the Wicket Ajax Debugger and it
displays:
ERROR: Error while parsing response: Object required
INFO: Invoking post-call handler(s)...
INFO: invoking failure handler(s)...
I also noticed that the user-define javascript that was returned by the ajax
debugger was appended by ^. (See javascript below):
// enable disable button.
function setButtonState() {
var formObj =
eval(document.getElementsByName(contactListForm)[0]^);
var state = anyChecked(formObj);
document.getElementsByName(deleteContactsButton)[0]^.disabled = !state;
document.getElementsByName(newContactGroupButton)[0]^.disabled = !state;
document.getElementsByName(newEventButton)[0]^.disabled
= !state;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595347#action_12595347 ] Erik van Oosten commented on WICKET-1355: - Richard, that change was the whole point of the fix. Apparently there is still a problem with the z-index, but reverting this line will not fix the problem of this issue. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Janne Hietamäki Fix For: 1.3.4 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1534) Allow multiple URL coding strategies on the same mount path
[ https://issues.apache.org/jira/browse/WICKET-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589834#action_12589834 ] Erik van Oosten commented on WICKET-1534: - After a small investigation I found that a CompoundRequestTargetUrlCodingStrategy is indeed possible. However, it would not really work well unless WebRequestCodingStrategy is changed such that the IRequestTargetUrlCodingStrategy#matches methods are executed outside a synchronized block. In my application I have to access the database in the matches methods. (Although the data is heavily cached, I can not afford to have all requests to stand still while the database is accessed for one page.) I'll try to make new patches, but if someone else is quicker I would welcome that :) Allow multiple URL coding strategies on the same mount path --- Key: WICKET-1534 URL: https://issues.apache.org/jira/browse/WICKET-1534 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.3 Reporter: Erik van Oosten Fix For: 1.4-M1 Attachments: VersatileWebRequestCodingStrategy.java It is currently not possible to mount multiple URL coding strategies on the same mount path. However, in combination with method #matches(String urlPath) this would be quite easy to accomplish in a backward compatible way. Please find attached a class that can be used instead of WebRequestCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1534) Allow multiple URL coding strategies on the same mount path
[ https://issues.apache.org/jira/browse/WICKET-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1534: Attachment: VersatileWebRequestCodingStrategy.java Allow multiple URL coding strategies on the same mount path --- Key: WICKET-1534 URL: https://issues.apache.org/jira/browse/WICKET-1534 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.3 Reporter: Erik van Oosten Fix For: 1.4-M1 Attachments: VersatileWebRequestCodingStrategy.java It is currently not possible to mount multiple URL coding strategies on the same mount path. However, in combination with method #matches(String urlPath) this would be quite easy to accomplish in a backward compatible way. Please find attached a class that can be used instead of WebRequestCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1534) Allow multiple URL coding strategies on the same mount path
[ https://issues.apache.org/jira/browse/WICKET-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589048#action_12589048 ] Erik van Oosten commented on WICKET-1534: - Nothing changes there. It is already possible that multiple URL encoders are mounted for the same page type. Allow multiple URL coding strategies on the same mount path --- Key: WICKET-1534 URL: https://issues.apache.org/jira/browse/WICKET-1534 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.3 Reporter: Erik van Oosten Fix For: 1.4-M1 Attachments: VersatileWebRequestCodingStrategy.java It is currently not possible to mount multiple URL coding strategies on the same mount path. However, in combination with method #matches(String urlPath) this would be quite easy to accomplish in a backward compatible way. Please find attached a class that can be used instead of WebRequestCodingStrategy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1484) class cast exception (String) in MixedParamUrlCodingStrategy with additional params with patch
[
https://issues.apache.org/jira/browse/WICKET-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589084#action_12589084
]
Erik van Oosten commented on WICKET-1484:
-
An alternative is to replace the getParameterMap() method in ServletWebRequest
like this:
public Map getParameterMap()
{
// Lazy-init parameter map. Only make one copy. It's more
efficient, and
// we can add stuff to it (which the BookmarkablePage stuff
does).
if (parameterMap == null)
{
parameterMap = new
HashMap(httpServletRequest.getParameterMap());
// Replace single value parameter arrays with a single string.
for (Iterator i = parameterMap.keySet().iterator(); i.hasNext(); )
{
Object key = i.next();
Object value = parameterMap.get(key);
if ((value instanceof String[]) ((String[]) value).length ==
1)
{
parameterMap.put(key, ((String[]) value)[0]);
}
}
}
// return a mutable copy
return parameterMap;
}
class cast exception (String) in MixedParamUrlCodingStrategy with additional
params with patch
--
Key: WICKET-1484
URL: https://issues.apache.org/jira/browse/WICKET-1484
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.2
Reporter: Michael Grinner
Attachments: 1484_patch.txt
MixedParamUrlCodingStrategy has a bug in
MixedParamUrlCodingStrategy
appendParameters
if (!parameterNamesToAdd.isEmpty())
{
boolean first = true;
final Iterator iterator;
if (UnitTestSettings.getSortUrlParameters())
{
iterator = new
TreeSet(parameterNamesToAdd).iterator();
}
else
{
iterator = parameterNamesToAdd.iterator();
}
while (iterator.hasNext())
{
url.append(first ? '?' : '');
String parameterName = (String)iterator.next();
@@@ String value = (String)parameters.get(parameterName);
url.append(urlEncode(parameterName)).append(=).append(urlEncode(value));
first = false;
}
}
where value should be a String[] not a String.
like in AbstractRequestTargetUrlCodingStrategy
appendParameters
String[] values = (String[])value;
for (int i = 0; i values.length; i++)
{
appendValue(url, entry.getKey().toString(), values[i]);
}
it works ok after patching MixedParamUrlCodingStrategy to
if (!parameterNamesToAdd.isEmpty()) {
boolean first = true;
final Iterator iterator;
if (UnitTestSettings.getSortUrlParameters()) {
iterator = new TreeSet(parameterNamesToAdd).iterator();
} else {
iterator = parameterNamesToAdd.iterator();
}
while (iterator.hasNext()) {
url.append(first ? '?' : '');
String parameterName = (String) iterator.next();
Object value = parameters.get(parameterName);
if (value != null) {
if (value instanceof String[]) {
String[] values = (String[]) value;
for (String element : values) {
url.append(this.urlEncode(parameterName)).append(=).append(this.urlEncode(element));
}
} else {
url.append(this.urlEncode(parameterName)).append(=).append(this.urlEncode(value.toString()));
}
}
first = false;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1329) AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586447#action_12586447 ] Erik van Oosten commented on WICKET-1329: - When the fix in [WICKET-1355] is applied, the changes for this bug should probably be undone. AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow -- Key: WICKET-1329 URL: https://issues.apache.org/jira/browse/WICKET-1329 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-final Reporter: Andy Chu Assignee: Gerolf Seitz Fix For: 1.3.3 When an AutoCompleteTextField is used in panel showed inside a ModalWindow, the dropdown list for suggestions will be disappeared. The reason is that the z-index of a normal ModalWindow is 2 while the z-index of the dropdown list is 1. And there is no way to set this parameter programatically. Therefore, the dropdown list is masked by the ModalWindow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586448#action_12586448 ] Erik van Oosten commented on WICKET-1355: - The changes for bug [WICKET-1329] should probably be undone when the fix attached to this issue is applied. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Assignee: Janne Hietamäki Fix For: 1.3.4 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: (was: wicket-autocomplete.js) Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: wicket-autocomplete.js Removed the non-working attachment. The currently attached version works on all regular browsers. Note: we had to move the drop-down div to another location to prevent it from staying on the same location on the screen while the content is scrolled. It is now the sibling of the input element. This may cause problems in css. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1355) Autocomplete window has wrong position in scrolled context
Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-1355: Attachment: wicket-autocomplete.js A fix for the problem. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569925#action_12569925 ] Erik van Oosten commented on WICKET-1355: - Attached code is not yet correct. Autocomplete window has wrong position in scrolled context -- Key: WICKET-1355 URL: https://issues.apache.org/jira/browse/WICKET-1355 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.1 Reporter: Erik van Oosten Fix For: 1.3.2 Attachments: wicket-autocomplete.js When the autocompleted field is located in a scrolled div, the drop-down window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAVENUPLOAD-1619) Please upload XMLUnit for Java 1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104070 ] Erik van Oosten commented on MAVENUPLOAD-1619: -- Meanwhile, is there another repository? Please upload XMLUnit for Java 1.1 -- Key: MAVENUPLOAD-1619 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1619 Project: maven-upload-requests Issue Type: Wish Reporter: Stefan Bodewig Assignee: Carlos Sanchez XMLUnit for Java 1.1 has been released today. http://xmlunit.sf.net/ I am listed as a project admin at http://sourceforge.net/projects/xmlunit/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-214) Call all behaviors attached to the same event
[ https://issues.apache.org/jira/browse/WICKET-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495299 ] Erik van Oosten commented on WICKET-214: The situation would already be improved a lot if the javadoc would make it clear that it is not possible to add multiple behaviors to the same event. Yet another option is to provide an aggregation behavior. Something that would allow you to merge 2 behaviors into 1. I am not sure how this could work. I am not familiar with Wicket.Event (a 1.3 feature?). Call all behaviors attached to the same event - Key: WICKET-214 URL: https://issues.apache.org/jira/browse/WICKET-214 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.2.4, 1.3, 2.0 Reporter: Erik van Oosten Assigned To: Johan Compagner Fix For: 1.3, 2.0 If one adds 2 AjaxFormComponentUpdatingBehaviors with event onchange to the same form component, only the behavior that was added last will actually be called. Please make it so that both are called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-176) Introduce AjaxFormElementValidatingBehavior
[ https://issues.apache.org/jira/browse/WICKET-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495301 ] Erik van Oosten commented on WICKET-176: As this class validates a field on the server as soon as it is changed, this class would be ideal for the currently discussed HibernateValidator. Introduce AjaxFormElementValidatingBehavior --- Key: WICKET-176 URL: https://issues.apache.org/jira/browse/WICKET-176 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.2.3 Reporter: Erik van Oosten Assigned To: Eelco Hillenius Fix For: 1.3, 2.0 Attachments: AjaxFormComponentValidatingBehavior.java, AjaxFormComponentValidatingBehavior.java There is currently no easy way to validate a single form element using Ajax. Please add attached code to the Wicket-core. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-256) wicket-ajax.js not added as regular header contribution
wicket-ajax.js not added as regular header contribution --- Key: WICKET-256 URL: https://issues.apache.org/jira/browse/WICKET-256 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.2.4 Reporter: Erik van Oosten Since wicket-ajax.js is not added as a regular header contribution, so that doing something like add(HeaderContributor.forJavaScript(AbstractDefaultAjaxBehavior.JAVASCRIPT); from a component will add the file to the header twice. Discussed on the user maillist: http://www.nabble.com/forum/ViewPost.jtp?post=8809387framed=y -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-218) Removing comments from markup can fail
[ https://issues.apache.org/jira/browse/WICKET-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik van Oosten updated WICKET-218: --- Attachment: MarkupParserPatch.txt Removing comments from markup can fail -- Key: WICKET-218 URL: https://issues.apache.org/jira/browse/WICKET-218 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.2.4 Reporter: Erik van Oosten Attachments: MarkupParserPatch.txt Markup with comments in it sometimes causes Wicket to crash with a nasty StringIndexOutOfBoundsException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-218) Removing comments from markup can fail
[ https://issues.apache.org/jira/browse/WICKET-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465747 ] Erik van Oosten commented on WICKET-218: The problem is that the code tries to read beyond the comment even when the comment is exactly at the end of the rawMarkup. Removing comments from markup can fail -- Key: WICKET-218 URL: https://issues.apache.org/jira/browse/WICKET-218 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.2.4 Reporter: Erik van Oosten Attachments: MarkupParserPatch.txt Markup with comments in it sometimes causes Wicket to crash with a nasty StringIndexOutOfBoundsException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WICKET-214) Call all behaviors attached to the same event
Call all behaviors attached to the same event - Key: WICKET-214 URL: https://issues.apache.org/jira/browse/WICKET-214 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.2.4, 1.3, 2.0 Reporter: Erik van Oosten If one adds 2 AjaxFormComponentUpdatingBehaviors with event onchange to the same form component, only the behavior that was added last will actually be called. Please make it so that both are called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WICKET-176) Introduce AjaxFormElementValidatingBehavior
[ http://issues.apache.org/jira/browse/WICKET-176?page=all ] Erik van Oosten updated WICKET-176: --- Attachment: AjaxFormComponentValidatingBehavior.java I found out that AjaxFormComponentValidatingBehavior is a better name for the class. Introduce AjaxFormElementValidatingBehavior --- Key: WICKET-176 URL: http://issues.apache.org/jira/browse/WICKET-176 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.2.3 Reporter: Erik van Oosten Attachments: AjaxFormComponentValidatingBehavior.java There is currently no easy way to validate a single form element using Ajax. Please add attached code to the Wicket-core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WICKET-153) FormElement cookies not set when called using AJAX
FormElement cookies not set when called using AJAX -- Key: WICKET-153 URL: http://issues.apache.org/jira/browse/WICKET-153 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.2.3 Reporter: Erik van Oosten I have a DropDownChoice with wantOnSelectionChangedNotifications returning true and persistent set to true. Unfortunately the cookie is not set when the submit is done through AJAX (with an AjaxSubmitButton). In addition when there is a cookie in the AJAX request, that cookie is not used for the form component's value when it is constructed during the AJAX call. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-21) Inherit authorisation rules from base class
[
http://issues.apache.org/jira/browse/WICKET-21?page=comments#action_12456717 ]
Erik van Oosten commented on WICKET-21:
---
Ok. That is fair. At least someone who want to do this can grab the code from
this issue.
Inherit authorisation rules from base class
---
Key: WICKET-21
URL: http://issues.apache.org/jira/browse/WICKET-21
Project: Wicket
Issue Type: Improvement
Components: wicket-auth-roles
Affects Versions: 1.2.2
Reporter: Erik van Oosten
Please make authorisation rules inheritable from the base class(es) of a
component.
The following change will allow you to define authorization rules on some
class. All sub-classes will automatically inherit these authorization rules.
It is easy to override this by explicitly adding authorization rules for a
subclass.
Change InstantiationPermissions#authorizedRoles to:
// TODO: make java 5 code by inserting generics again
public Roles authorizedRoles(final Class componentClass) {
if (componentClass == null) {
throw new IllegalArgumentException(Argument componentClass
cannot be null);
}
Class c = componentClass;
while (Component.class.isAssignableFrom (c)
!rolesForComponentClass.containsKey(c)) {
c = c.getSuperclass();
}
return (Roles) rolesForComponentClass.get(c);
}
This has been tested under a jrocket 1.4 jvm.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WICKET-138) new MixedUrlEncoding
[ http://issues.apache.org/jira/browse/WICKET-138?page=all ] Erik van Oosten updated WICKET-138: --- Attachment: MixedParamUrlCodingStrategy.java new MixedUrlEncoding Key: WICKET-138 URL: http://issues.apache.org/jira/browse/WICKET-138 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 2.0, 1.3, 1.2.4 Reporter: Erik van Oosten Attachments: MixedParamUrlCodingStrategy.java, MixedParamUrlCodingStrategyTest.java The current URL encoders have no variant that allows you to specify a part of the parameters as URL path and the rest as querystring. Attached is an implementation that does this. Feel free to include this in the wicket repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WICKET-71) Extra clarification on changing rendering of ListView
Extra clarification on changing rendering of ListView - Key: WICKET-71 URL: http://issues.apache.org/jira/browse/WICKET-71 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.2.3 Reporter: Erik van Oosten Please add the following to the class comment of wicket.ListItem. * * p * NOTE: when you want to change the default generated markup it is important to * realise that the ListView instances does not correspond to any markup however, * the generated ListItems do. br / * This means that methods like [EMAIL PROTECTED] #setRenderBodyOnly(boolean)} and * [EMAIL PROTECTED] #add(wicket.behavior.IBehavior)} should be invoked on the ListItem that * given in the [EMAIL PROTECTED] #populateItem(ListItem)} method. * /p -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
