Issue migrating from PrettyFaces 3.3.3 to Rewrite 2.0.2.

Splash Forums PrettyFaces Users Issue migrating from PrettyFaces 3.3.3 to Rewrite 2.0.2.

This topic contains 4 replies, has 2 voices, and was last updated by  Lincoln Baxter III 8 years, 7 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #24264



    We’ve been using PrettyFaces in our JSF2 project and we though to migrate to rewrite in order to get the new functionalities.

    However, there is one issue where generated URLs are no longer pretty after the switch.
    This is the mapping in pretty-config.xml:

    <url-mapping id="matriceFatturato">
        <pattern value="/matriceFatturato" />
        <view-id value="/admin/obeconomici/matriceMargini.jsf?tipoRecuperoId=2" />

    this is part of the button jsf snippet:
    <h:commandLink action="#{matriceMarginiBean.selectMerceologia}"/>

    this is an example action method code that makes problems:

    public String selectMerceologia() {
            return "/admin/obeconomici/matriceMargini.jsf?faces-redirect=true&tipoRecuperoId=2&zz=2";

    The user is redirected to:

    Any help is appreciated,



    Also, I have a problem if I try to use rewrite-integration-faces module if the following manner:


    The URL the user is redirected to is:
    where it seems that the context path (“po”) is appended twice.

    Another thing, not related to migration and I don’t even know if it’s a problem or desired behavior: Can the parameters declared in the urlmapping>viewId section be removed from the generated url? So that the resulting URL from the example given would be “matriceFatturato?zz=2” instead of “matriceFatturato?tipoRecuperoId=2&zz=2”.



    Hey Andrei,

    Regarding your first issue; PrettyFaces was never really designed to support query-parameters in the view ID, which may be a mistake we can fix, but I think you probably want to be using the <query-param> element in your pretty-config. Or use an action method to set the value.

    The second issue sounds like a bug plain and simple. Do you think you could create a small example project or rewrite test-case that reproduces these issues? I have created a bug report for both of these and we will need to take a look at it. If you wanted to debug it might help this go faster because Christian is on vacation right now so we are a person down 🙂

    Also, creating a sample app we can use to test would be extremely helpful for getting these resolved faster, thanks!





    Thanks for the reply, I will look into them this evening or tommorow morning at the latest and will try to provide as much as I can to have them fixed. One mention I have is that I think appended parameters to view-id work in rewrite also, but only when there aren’t any additional parameters than those in the view-id declaration. It seems to be an parameter order related problem, because in my example the order was broken (it generated zz=2&tipoRecuperoId=2 when I specifed it backwards in my action method).

    Regarding the same issue, I think I saw that kind of configuration being advertied in some older slides about prettyfaces.
    And I think it’s quite usefull to have the same jsf view being reused in more pretty URLs.

    So I can have for example (all urls are relative to context path):
    /candies forwarding to /items.jsf?tipe=1 or
    /toys forwarding to /items.jsf?tipe=2.
    What I’m thinking about <query-param> is generating an url like /items?type=toys and setting pathparams in action would still generate somthing like /items/toys. Am I missing something here?

    Many thanks for all your contributions to the oss community,


    Thank you! I love writing OSS 🙂

    And yeah, I think that you are probably right that ordering is part of the issue, but in reality I don’t think that Query params should be matched or generated as part of the URL path; so, separating the logic for this might be a good idea to prevent ordering issues, as you suggested.

    I appreciate you taking a look! If you want an idea of how to get started, I would probably take one of the existing tests in the rewrite-config-prettyfaces-tests module (from github –, copy it, rename it to something that relates to this problem, and write a test that verifies the failure.

    Once you have that failing test, start writing the functionality to fix it. This will be beneficial because we can ensure that the problem never occurs again, and also if you have issues, I can easily reproduce the problem by running your test case and help out 🙂

    Thanks again!

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

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

Comments are closed.