You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Pascal Bleser (JIRA)" <ji...@apache.org> on 2008/09/07 12:51:44 UTC

[jira] Commented: (WICKET-1821) WebRequestCodingStrategy assumes mount path prefix for matching

    [ https://issues.apache.org/jira/browse/WICKET-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628963#action_12628963 ] 

Pascal Bleser commented on WICKET-1821:
---------------------------------------

In case other people run into this, here is a workaround: add the following method in your Application class:

<pre>
@Override protected IRequestCycleProcessor newRequestCycleProcessor() {
   return new WebRequestCycleProcessor() {
      @Override protected IRequestCodingStrategy newRequestCodingStrategy() {
             return new WebRequestCodingStrategy() {
                 @Override public IRequestTargetUrlCodingStrategy urlCodingStrategyForPath(String path) {
                     if (path == null) {
                         return super.urlCodingStrategyForPath(path);
                     } else {
                         for (IRequestTargetUrlCodingStrategy strategy : listMounts()) {
                             if ((strategy != null) && strategy.matches(path)) {
                                 return strategy;
                             }
                         }
                     }
                     return null;
                 }
             };
         }
    };
}
</pre>

It does have a drawback though: it doesn't synchronize on WebRequestCodingStrategy.mountsOnPath as does the overridden method, because that attribute is private. But it's safe if you don't add mounts dynamically (i.e. outside of Application.init()), at least as far as I can tell.

> WebRequestCodingStrategy assumes mount path prefix for matching
> ---------------------------------------------------------------
>
>                 Key: WICKET-1821
>                 URL: https://issues.apache.org/jira/browse/WICKET-1821
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.4-M1, 1.4-M2, 1.4-M3
>         Environment: Linux (openSUSE 10.2 and 11.0), x86_64, jetty; but affects all environments
>            Reporter: Pascal Bleser
>            Priority: Minor
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> WebRequestCodingStrategy makes an assumption about IRequestTargetUrlCodingStrategy implementations in what seems to be a minor optimization:
> in WebRequestCodingStrategy.MountsMap.strategyForPath:
> for (Entry<String, IRequestTargetUrlCodingStrategy> entry : map.entrySet())
> {
>    final String key = entry.getKey();
>    if (path.startsWith(key))
>    {
>       IRequestTargetUrlCodingStrategy strategy = entry.getValue();
>       if (strategy.matches(path))
>       {
>          return strategy;
>       }
>    }
> }
> While it should actually be the following instead:
> for (IRequestTargetUrlCodingStrategy strategy : listMounts()) {
>    if ((strategy != null) && strategy.matches(path)) {
>       return strategy;
>    }
> }
> I ran into that issue while implementing a custom IRequestTargetUrlCodingStrategy that uses a pattern based approach, e.g. for an URL like this:
> /customer/1000/site/100/edit
> It is mounted with the following String:
> "/customer/${customerId}/site/${siteId}/edit"
> but it is simply skipped by WebRequestCodingStrategy.MountsMap.strategyForPath() because the mount prefix doesn't match (as in a simple String.startsWith(), as performed by strategyForPath()), while only calling match(String) on the IRequestTargetUrlCodingStrategy works, because match(String) is implemented accordingly in the custom IRequestTargetUrlCodingStrategy.
> I would consider this to be a bug, because the current implementation in WebRequestCodingStrategy.MountsMap.strategyForPath() assumes that all IRequestTargetUrlCodingStrategy have a fixed prefix that can be matched using String.startsWith(), while that isn't necessarily the case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.