[
http://www.stripesframework.org/jira/browse/STS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11452#action_11452
]
Ben Gunter commented on STS-592:
--------------------------------
The root of this problem lies either in your test code or in the MockRoundtrip,
depending on your viewpoint. Either way, it does not lie in the clean URL code.
I took your example @UrlBinding from STS-262, applied it to an ActionBean,
generated the URL with the given parameter values using s:link, clicked the
link, and all the parameters were there.
You are creating a MockRoundtrip, passing in an ActionBean URL that contains a
query string. In a real app server, the URL is parsed into the file part and
the query string part (file?query) before the ActionResolver sees it. The
ActionResolver then uses just the file part to map the URL to an ActionBean --
in this case, everything up to the question mark in your @UrlBinding. Then the
parameters that were defined after the '?' in @UrlBinding are there because
they are just normal query parameters, provided by the app server.
In the MockRoundtrip, that query string is not parsed out first so the query
parameters you appended to the query string beyond the definition of the last
"clean" parameter just become part of that "clean" parameter's value. The only
way MockHttpServletRequest can have any normal request parameters is if they
are specified using MockRoundtrip#addParameter(..), which you are not doing.
I modified MockRoundtrip to strip the query string and parse the parameters
out, calling #addParameter(..) for each one, and all the parameters were
correct after that. However, because that basically converts do={$event} to a
parameter named "do" with the event name as its value, the event name is no
longer what you would expect.
What this basically comes down to is that clean URLs are not intended to
support embedded query strings. It could be argued that the '?' should be
URL-encoded as the URL is built. But it is also valid to say that developers
should not embed special characters in a clean URL. Or, at least, if they do so
they should be responsible for URL-encoding such characters themselves.
> Stripes 1.5 URLBindingFactory does not parse clean URLs with appended
> parameters
> ---------------------------------------------------------------------------------
>
> Key: STS-592
> URL: http://www.stripesframework.org/jira/browse/STS-592
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.5
> Environment: OS X
> Reporter: Andrew Jaquith
>
> I've found an issue in build 947 with the implementation of clean URLs, which
> relates to differences in how the ActionResolver and UrlBuilder handle
> appended parameters. I had previously written up my observations in comments
> on STS-262, but that issue had been marked closed. I was not sure if my
> comments had been read, hence I am opening a new issue.
> Summary:
> With a given "clean" @UrlPattern, if parameters otherwise unspecified in the
> pattern are added to the UrlBuilder, they are properly appended in the
> generated URL. But if that generated URL is passed back to the StripesFilter,
> the trailing parameters are not parsed as expected, even if the ActionBean
> has properties that those parameters "should" bind do. In other words, it is
> not a "round trip" operation.
> For more in-depth comments, *and* a proposed patch to fix the issue, see
> STS-262.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
