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 1 year, 5 months ago.

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

    fturizo
    Participant

    Greetings.

    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:

        <error-page>
            <error-code>403</error-code>
            <location>/errors/403.xhtml</location>
        </error-page>
        <error-page>
            <error-code>404</error-code>
            <location>/errors/404.xhtml</location>
        </error-page>
        <error-page>
            <error-code>500</error-code>
            <location>/errors/common.xhtml</location>
        </error-page>

    Relevant ConfigurationProvider code:

    @RewriteConfiguration
    public class AccessConfigurationProvider extends HttpConfigurationProvider {
        
        @Inject
        private IntegrationConfiguration ic;
        
        @Override
        public Configuration getConfiguration(ServletContext context) {
            ConfigurationBuilder builder = ConfigurationBuilder.begin()
                    .addRule(Join.path("/fleets/admin").to("/knowledge/admin.xhtml"))
                    .addRule(Join.path("/knowledge/builder/for/{id}").to("/knowledge/builder.xhtml"))
                    .addRule(Join.path("/lrcm/for/{code}").to("/lrcm/work-order.xhtml"))
                    .addRule(Join.path("/feedback/manager").to("/lrcm/feedback/manager.xhtml"))
                    .addRule(Join.path("/audit/trail/for/{id}").to("/audit/trail.xhtml"))
                    .addRule(Join.path("/admin").to("/system/admin.xhtml"));
            if(ic.hasWithRcmCost()){
                builder.addRule(Join.path("/rcmcost/import/to/{id}").to("/integration/awb-rcmcost/import.xhtml"));
            }
            if(ic.hasWithCmms()){
                builder.addRule(Join.path("/cmms/ellipse/events/log").to("/integration/cmms-ellipse/logViewer.xhtml"));
                builder.addRule(Join.path("/cmms/ellipse/codes").to("/integration/cmms-ellipse/codeMapping.xhtml"));
            }
            return builder;
        }
        
        @Override
        public int priority() {
            return 1;
        }
    }
    

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

    #26958

    How are your links defined?

    #26959

    fturizo
    Participant

    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>
     </h:commandLink>

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

    <navigation-case>
       <description>To fleet administration view</description>
       <from-action>fleet-administration</from-action>
       <to-view-id>/knowledge/admin.xhtml</to-view-id>
       <redirect/>
    </navigation-case>
    • This reply was modified 1 year, 5 months ago by  fturizo.
    #26961

    I think this could be caused by:

    https://github.com/ocpsoft/rewrite/issues/190

    #26966

    fturizo
    Participant

    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?

    #26970

    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.

    #26972

    fturizo
    Participant

    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

    #26973

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

    #26974

    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 🙂

    #26975

    fturizo
    Participant

    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.

    #26976

    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)

You must be logged in to reply to this topic.

Comments are closed.