Stripes

stripes:link doesn't resolved URL properly when used with DynamicMappingFilter

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: Release 1.5
  • Fix Version/s: Release 1.5.2, Release 1.6
  • Component/s: Tag Library
  • Labels:
    None
  • Environment:
    linux, tomcat 6, using lates stripes code from trunk (clean checkout)

Description

Steps to reporduce (note I am using DynamicFilterMapping):

1) create an action bean e.g.:

@UrlBinding("/foo/{$event}/{entryName}")
com.somewhere.FooAction

2)create a page with link:

<s:link beanclass="com.somewhere.FooAction" event="view">
<s:param name="entryName">${entry.name}</s:param>
${entry.name}
</s:link>

3) Deploy webapp into webapps/foo/

4) link resolves to /foo/view/someName
expected is:
/foo/foo/view/someName

Now change step 3 and deploy app into webapps/bar/
link now resolves to (as expected):
/bar/foo/view/someName

(or skip deployment change within 3 and only change url mapping to "/bar/{$event}/{entryName}, than link becomes: /foo/bar/view/someName)

Activity

Hide
m.j.milicevic added a comment - 20/Oct/08 8:03 AM

one more (this time war is deployed into foobar context):

I've mapped /action/* within dynamic filter,
<filter-mapping>
<filter-name>DynamicMappingFilter</filter-name>
<url-pattern>/action/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>

my action has following mapping:
@UrlBinding(value = "/action/register/{$event}")

Now, eveything works fine, however, if I have a form and try to submit, event is never mapped to the right action, and never gets called. It gets called if I use action instead of beanclass atribute.

Changing this to /actions/* instead of /action/*, fixes things. (of course @UrlBinding is changed as wel)

Deployment is on tomcat/linux

Show
m.j.milicevic added a comment - 20/Oct/08 8:03 AM one more (this time war is deployed into foobar context): I've mapped /action/* within dynamic filter, <filter-mapping> <filter-name>DynamicMappingFilter</filter-name> <url-pattern>/action/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping> my action has following mapping: @UrlBinding(value = "/action/register/{$event}") Now, eveything works fine, however, if I have a form and try to submit, event is never mapped to the right action, and never gets called. It gets called if I use action instead of beanclass atribute. Changing this to /actions/* instead of /action/*, fixes things. (of course @UrlBinding is changed as wel) Deployment is on tomcat/linux
Hide
m.j.milicevic added a comment - 05/Mar/09 3:52 AM

Ithink this one can be closed as
http://www.stripesframework.org/jira/browse/STS-611 is fixed (probably same issue, haven tested it though)

Show
m.j.milicevic added a comment - 05/Mar/09 3:52 AM Ithink this one can be closed as http://www.stripesframework.org/jira/browse/STS-611 is fixed (probably same issue, haven tested it though)
Hide
Ben Gunter added a comment - 05/Mar/09 7:44 AM

It is similar but not quite the same. Both problems stem from having a context-relative path that starts with the context path – e.g., /foo/foo/bar. But STS-611 was specific to RedirectResolution, and this one is specific to LinkTag.

Now that I've compared the two, however, I realize I can resolve them both the same way. If the prependContext= attribute of stripes:url or stripes:tag is not set then it will try to figure out if the context should be prepended or not. If it is set then it will do whatever it is directed to do. That's how STS-611 was fixed.

My guess is the separate issue reported in the first comment here is resolved in 1.5.1.

Show
Ben Gunter added a comment - 05/Mar/09 7:44 AM It is similar but not quite the same. Both problems stem from having a context-relative path that starts with the context path – e.g., /foo/foo/bar. But STS-611 was specific to RedirectResolution, and this one is specific to LinkTag. Now that I've compared the two, however, I realize I can resolve them both the same way. If the prependContext= attribute of stripes:url or stripes:tag is not set then it will try to figure out if the context should be prepended or not. If it is set then it will do whatever it is directed to do. That's how STS-611 was fixed. My guess is the separate issue reported in the first comment here is resolved in 1.5.1.
Hide
Ben Gunter added a comment - 05/Mar/09 8:42 AM

Fixed. The prependContext field is now Boolean. If it is set true then the context will always be prepended; if it is false then it will never be prepended. If it is null and the context is not the root context, then it will be prepended if the URL does not already start with the context path or if the beanclass attribute is not null (because the ActionBean URL binding is always context-relative).

Show
Ben Gunter added a comment - 05/Mar/09 8:42 AM Fixed. The prependContext field is now Boolean. If it is set true then the context will always be prepended; if it is false then it will never be prepended. If it is null and the context is not the root context, then it will be prepended if the URL does not already start with the context path or if the beanclass attribute is not null (because the ActionBean URL binding is always context-relative).

People

Vote (0)
Watch (0)

Dates

  • Created:
    03/Mar/08 4:57 PM
    Updated:
    04/Jan/11 2:49 PM
    Resolved:
    05/Mar/09 8:42 AM