CommandLinks in Error page not Working

Splash Forums PrettyFaces Users CommandLinks in Error page not Working

This topic contains 10 replies, has 3 voices, and was last updated by  Christian Kaltepoth 6 years, 11 months ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #26957



    I am using Rewrite with JSF integration v2.0.12.Final and everything works fine, except that in my custom error pages (declared in web.xml descriptor) the commandlinks aren’t working correctly. Whenever they’re pressed i end up navigating to the same page. Do i need to configure something to allow theses error pages to navigate correctly?

    Relevant web.xml configuration:


    Relevant ConfigurationProvider code:

    public class AccessConfigurationProvider extends HttpConfigurationProvider {
        private IntegrationConfiguration ic;
        public Configuration getConfiguration(ServletContext context) {
            ConfigurationBuilder builder = ConfigurationBuilder.begin()
            return builder;
        public int priority() {
            return 1;

    The application is deployed to a Glassfish 4.1 Open Source. Any help is appreciated.


    How are your links defined?



    These links are defined in a common facelets template that both the user interface and error pages use. An example of these links would be this:

    <h:commandLink action="fleet-administration" styleClass="main_link">
        <h:graphicImage name="img/blank.gif" styleClass="img_holder fleet-menu"/>
        <span class="menu-text1">#{msg.fleet_administration}</span>

    Where the action is a global navigation action defined in the faces-config file like this:

       <description>To fleet administration view</description>
    • This reply was modified 6 years, 11 months ago by  fturizo.

    I think this could be caused by:



    Yes, regarding the github issue my problem it’s exactly that the links (that are already a in h:form) aren’t correctly conformed since they navigate to the same page that caused the error (my test was made by using the 404 error page). Is there any estimate of this issue being fixed? Is there some workaround i can use in the meantime?


    I don’t know if there is a workaround for this.

    However, we would be happy to get help fixing issue #190. So if you want to help by contributing a patch or something like that you are more than welcome.



    Well, i ended implementing the workaround that the issuer made in his own project; that is, implement a replacement to the DefaultActionUrlProvider and register it as a SPI in my project. This class would delegate the calculation of the action URL to the JSF implementation instead of using FacesRewriteLifecycleListener.getActionURL


    Doesn’t this cause other problems? In this case all postbacks are going to the unrewritten URL, correct?


    I think he probably wrote it so that it only affects the error page (this should be possible, as you said in the issue log.) I think I’ll look at this issue this afternoon (after my swim 🙂



    That is correct, in my ActionUrlProvider i check if the current page is a web.xml declared error page and delegate the URL generation to the ViewHandler of JSF, otherwise i use FacesRewriteLifecycleListener.getActionURL. If you can look to this issue and find a cleaner solution i would appreciate it.


    Instead of comparing the URL with the error page from web.xml, you could use request.getDispatchType() to detect the error case. That’s basically what I suggested in #190.

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

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

Comments are closed.