Rewrite/PrettyFaces and JSF actions

Splash Forums Rewrite Users Rewrite/PrettyFaces and JSF actions

This topic contains 8 replies, has 2 voices, and was last updated by  Christian Kaltepoth 1 year, 7 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #26542

    marco.schulte
    Participant

    I can’t get usual JSF actions wo work when the page is loaded through a prettyfied URL. I tried it with prettyfaces and plain Rewrite.

    Assume I have defined following rule:
    return ConfigurationBuilder.begin().addRule(Join.path("/edit").to("/editPosting.html"));
    or in prettyfaces config

    	<url-mapping id="edit" onPostback="false">
    		<pattern value="/edit" />
    		<view-id value="/editPosting.html" />
    	</url-mapping>

    The mapping itself works like a charm, but any action, e.g. <h:commandButton action="#{editPostingAction.save}" value="Save" /> doesn’t work anymore. Pressing the button just reloads the page instead of submitting the values and calling the save method.

    In contrast, when navigating directly to /editPosting.html everything works as expected.

    I’m using the JEE 7 stack deployed on Wildfly 8.0, rewrite-servlet 2.0.12.Final.

    Any help is appreciated

    • This topic was modified 1 year, 8 months ago by  marco.schulte.
    #26549

    Did you include the rewrite-integration-faces module in your dependencies? Could you try that?

    #26573

    marco.schulte
    Participant

    Unfortunately no difference. Any other idea? Should I bundle a sample webapp which reproduces the error? Do you expect that problem to disappear in a different Application Server?

    #26575

    When you click the button, does the postback go to /editPosting.html or /edit? You can use the development tools of your browser to check this.

    #26581

    marco.schulte
    Participant

    The postback goes to /edit.

    I assume this is an error which should be corrected by onPostback=false? I can’t find that option when using the ConfigurationBuilder. And it didn’t help when I used the older prettyfaces version with the xml config.

    #26584

    There is a IgnorePostbackOperation. Just wrap your operation in this one. In this case the execution will be skipped for postbacks.

    However, I don’t think that this causes your problem. Perhaps you could add a PhaseListener that logs starting and stopping of each phase so we can see if INVOKE_APPLICATION is skipped or not.

    #26586

    marco.schulte
    Participant

    The complete configuration I’m currently using is return ConfigurationBuilder.begin().addRule(Join.path("/edit").to("/editPosting.html"));, I didn’t see a way to integrate IgnorePostbackOperation into that, as I’m not performaing any Operation, and the Join isn’t wrappable.

    I added the PhaseListener and the invoke application phase is indeed skipped. Here is the log:

    08:40:31,348 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-7) Before phase <RESTORE_VIEW 1>
    08:40:31,351 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-7) After phase <RESTORE_VIEW 1>
    08:40:31,351 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-7) Before phase <RENDER_RESPONSE 6>
    08:40:31,408 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-7) After phase <RENDER_RESPONSE 6>
    08:40:42,234 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-13) Before phase <RESTORE_VIEW 1>
    08:40:42,235 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-13) After phase <RESTORE_VIEW 1>
    08:40:42,236 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-13) Before phase <RENDER_RESPONSE 6>
    08:40:42,267 INFO  [de.mut.urlrewrite.CustomPhaseListener] (default task-13) After phase <RENDER_RESPONSE 6>

    The page is loaded at 08:40:31, the commandButton is pressed at 08:40:42.

    • This reply was modified 1 year, 8 months ago by  marco.schulte.
    #26638

    marco.schulte
    Participant

    I’ve solved the problem, here’s the update.

    I’ve been wondering why we aren’t hitting the apply request values phase and debugged the RewriteFilter. The submitted values weren’t even appearing in the request object when posting to a rewritten URL. This didn’t feel like a rewrite-servlet problem, as the filter was the first rewrite-servlet class to appear in the stacktrace, so I simply tried different AS. Wildfly 8.1 Final still had the same problem, but Wildfly 9.0 Alpha works like a charm.

    Thanks for the help.

    #26648

    Thanks for the update. 🙂

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

You must be logged in to reply to this topic.

Comments are closed.