Stripes

CLONE - UrlBindingFactory interprets parameters first in url as conflict

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: Release 1.5.1, Release 1.5.2
  • Fix Version/s: None
  • Component/s: ActionBean Dispatching
  • Labels:
    None

Description

I would like to have a parameter first in my urls, representing different sections of a site; eg: @UrlBinding("/{section}/foo/bar/{$event}.html")
This UrlBinding results in a conflict between all ActionBeans using the {section} parameter. While debugging I find the UrlBindingFactory.getBindingPrototype(String uri) method ignoring the componentMatch when checking if we have a conflict, which seems to be a bug. At least in this case the result is not logical.

Additionally when I use the url "/section1/foo/bar.html", the section parameter is set to "section1/foo/bar".
This works and gives me the default handler if I dont have the section as a parameter. Perhaps these two issues are related?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kris Luhr added a comment - 10/Aug/11 12:38 PM

Tests to reproduce the problem

Show
Kris Luhr added a comment - 10/Aug/11 12:38 PM Tests to reproduce the problem
Hide
Permalink
Kris Luhr added a comment - 10/Aug/11 12:51 PM

Sorry that it has taken so long, I havent had the time to address this issue and create a minimalistic test suite until now.
Have upgraded to 1.5.6 and the problem still remains.

I think that as long as two UrlBindings are unique they should not be considered conflicting. The attached tests show that [/{section}/stuff/bean1/{$event}.html, /{section}/stuff/bean2/{$event}.html] are considered conflicting.

I am not sure if my findings from debugging in 1.5.1 and 1.5.2 are relevant anymore, please ignore. Hope the attached test cases are clear enough to illustrate the issue.

Show
Kris Luhr added a comment - 10/Aug/11 12:51 PM Sorry that it has taken so long, I havent had the time to address this issue and create a minimalistic test suite until now. Have upgraded to 1.5.6 and the problem still remains. I think that as long as two UrlBindings are unique they should not be considered conflicting. The attached tests show that [/{section}/stuff/bean1/{$event}.html, /{section}/stuff/bean2/{$event}.html] are considered conflicting. I am not sure if my findings from debugging in 1.5.1 and 1.5.2 are relevant anymore, please ignore. Hope the attached test cases are clear enough to illustrate the issue.
Hide
Permalink
Kris Luhr added a comment - 10/Aug/11 12:51 PM

Our workaround is to have one ActionBean for each section with the section specified explicitly in each UrlBinding.
eg.
@UrlBinding("/abc/stuff/bean1/{$event}.html")
public class SectionFirst1AbcAction implements ActionBean { ... }

@UrlBinding("/xyz/stuff/bean1/{$event}.html")
public class SectionFirst1XyzAction extends SectionFirst1Action { ... }

This works fine but gives us 3 times as many actionbeans.

Show
Kris Luhr added a comment - 10/Aug/11 12:51 PM Our workaround is to have one ActionBean for each section with the section specified explicitly in each UrlBinding. eg. @UrlBinding("/abc/stuff/bean1/{$event}.html") public class SectionFirst1AbcAction implements ActionBean { ... } @UrlBinding("/xyz/stuff/bean1/{$event}.html") public class SectionFirst1XyzAction extends SectionFirst1Action { ... } This works fine but gives us 3 times as many actionbeans.
Hide
Permalink
Ken Koster added a comment - 12/Jan/13 2:50 AM

There is a second unwanted behavior caused by this issue in UrlBindingFactory, one manifested when executing a RedirectResolution with a target of "/". Instead of a redirect to "/" ending up with the client requesting a welcome-file (as defined in the web.xml) at the context root, the redirect instead goes to the URL with a parameterized first URL component, with that first parameter bound to the empty string. This leads to a 404 error.

So in the case of the ActionBean presented in the original problem description, trying to redirect a user to "/" would result in a redirection to //foo/bar/.html

(I'm not sure how the last component will be interpolated and whether .html will be part of the produced URL. But which ever way it gets interpolated, the core problem is still there.)

At resolution execution time, the corresponding binding for "/" gets looked up in the UrlBindingFactory.pathCache. This cache is incorrectly populated with an entry that has a key of "/" and a UrlBinding object for the URL with a parameter in the first component.

Show
Ken Koster added a comment - 12/Jan/13 2:50 AM There is a second unwanted behavior caused by this issue in UrlBindingFactory, one manifested when executing a RedirectResolution with a target of "/". Instead of a redirect to "/" ending up with the client requesting a welcome-file (as defined in the web.xml) at the context root, the redirect instead goes to the URL with a parameterized first URL component, with that first parameter bound to the empty string. This leads to a 404 error. So in the case of the ActionBean presented in the original problem description, trying to redirect a user to "/" would result in a redirection to //foo/bar/.html (I'm not sure how the last component will be interpolated and whether .html will be part of the produced URL. But which ever way it gets interpolated, the core problem is still there.) At resolution execution time, the corresponding binding for "/" gets looked up in the UrlBindingFactory.pathCache. This cache is incorrectly populated with an entry that has a key of "/" and a UrlBinding object for the URL with a parameter in the first component.

People

Vote (1)
Watch (2)

Dates

  • Created:
    10/Aug/11 12:37 PM
    Updated:
    12/Jan/13 2:50 AM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for Stripes Framework. Try JIRA - bug tracking software for your team.