Path default add parameter to parameters

Splash Forums Rewrite Users Path default add parameter to parameters

This topic contains 9 replies, has 2 voices, and was last updated by  RedShadow 9 years, 4 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #18693


    Maybe I use something wrong, but when I have a rule like:


    I will always get the parameter with the name “0” added to the query when calling “/test”, “test/” etc.

    Adding the path parameters by default is somehow annoying, also because there is no option to remove the parameter from that list afterwards!

    I use this kind of rule to support arbitary levels of URLs, so for example the following will be catche by that rule


    Any plans on changing the default behavior or supporting to remove parameters?


    Hm. So you mean that the parameter is being added to the request parameter map? Could you be a little more descriptive? Thanks.


    Even better, if you could create an Arquillian test case that reproduces this, it would make it very easy to fix :)

    For example:

    I think, however that I’ve found the issue.


    Oh, sorry. I got a lot little lost there. Yes – this is the default behavior of Join. It’s important to be able to do this so that you can correctly map path parameters to query-parameters in the application itself. This behavior won’t be changing – however, what I could possibly do is add a method:


    In fact, there is already a method called withRequestBinding that does nothing because it is always enabled by default anyway, so that’s worth fixing.

    But… if you want to achieve this functionality now, you can combine the Path and Forward configurations:


    I don’t really think this is a great idea, though, since you’ll be wanting to rewrite your outbound URLs as well. You would then need to figure out how to generate that URL. I don’t see what is wrong with adding the parameter, since otherwise Rewrite wouldn’t know how to generate the outbound URL either.

    If this is really what you want, then that’s fine, but I’m not sure it is, which is why I am suggesting that you stick with Join :)




    Well i will give you a hint on what i want to achieve ^^

    The mapping should be as follows, where the left side of the “rules” is kind of a regex:

    /test(.*) (Forward =>) /test/login.xhtml (when not logged in)

    /test(.*) (Forward =>) /test/test.xhtml (when logged in)

    Both /test/login.xhtml and /test/test.xhtml should be URL encoded to /test when for example used in JSF like:

    <h:link outcome=”/test/login.xhtml” value=”Login”/>


    In that case, you should build separate inbound and oubound rules for each URL, as I suggested, using the Path configuration:




    You can build any kind of custom rules you want – you just need to know what you want :)




    Thanks for the example, figured it out myself in the end.

    Anyways there really should be a withoutRequestBinding(). Why are you not storing the things in HttpServletRequest#attributes?

    All this will become a problem when using CODI which redirects a request to the same page, with the windowId appended.

    So the first request to a URL like /test/bla with the rule /test/{param} will result in /test/bla?windowId=123&param=bla which is not what I want. The appending of the windowId is somehow annoying, why isn’t there an option to disable the windowId for specific views or so?


    Path parameters are bound to request parameters by default when using Join – that’s just how this rule works because generally people want to map Path values as if they were coming in via the query string in name-value pairs. But if you want something more specific, however, then it sounds like you should probably build your own rule and customize it how you like :)

    That being said, it sounds like this is actually a bug in CODI, or something that needs to be improved in Rewrite. Can you tell if Rewrite is actually getting a chance to operate on the special CODI redirect? If not, that is a problem with CODI.

    Also, you will be happy to see this, which was added a week or so ago:




    The workaround for the problem illustrated in[1] is actually not really working. The sample app will show the general problem of the forever loop which is probably also the root cause of the troubles with CODI.

    Rewrite always get’s the chance to do something.

    I think the main problems are

    1. The first request to a mapped URL which is using Join will result in parameters being present in the new location due to redirect of CODI

    2. Using a non valid windowId will break every request(this is only with rewrite on classpath, see[1])

    Problem 1 seems to be resolved by skipping further rewrite handling when windowId is not present on non resource requests like:









    The second problem is fixed with the final solution of the other thread I started. Since the “withoutRequestBinding” method will be added, it should be fine.

    By the way, the session id problem was more or less fixed by that final solution. Now the session id only gets appended as path parameter to the resources within a document, which is not very nice either, but at least the user does not see the session id any more. If you have any idea how turn that off, I would be happy if you let me know ;)

Viewing 10 posts - 1 through 10 (of 10 total)

The forum ‘Rewrite Users’ is closed to new topics and replies.

Comments are closed.