Why JSF POST requests don't work with PrettyFaces

Question

I have been using JSF (MyFaces) with PrettyFaces for a while. Everything works perfectly, excepting POST requests.

The only problem I have is that I can’t make POST requests to any of the pages that are rewritten by PrettyFaces. I would really appreciate your help, because it’s a show stopper.

pretty-config.xml

<url-mapping id="market-view-item">
  <pattern value="/market/#{viewItem.itemId}" />
  <view-id value="/market/view-item.xhtml" />
</url-mapping>

pom.xml

<dependency>
  <groupId>org.ocpsoft.rewrite</groupId>
  <artifactId>rewrite-servlet</artifactId>
<version>2.0.5.Final</version>
</dependency>
<dependency>
  <groupId>org.ocpsoft.rewrite</groupId>
  <artifactId>rewrite-config-prettyfaces</artifactId>
  <version>2.0.5.Final</version>
</dependency>

I used 2.0.4.Final until today. I hoped that it will work by upgrading to 2.0.5, but nothing.

web page form:

<h:form prependId="false">
  <p:inputTextarea rows="3" style="width:450px; margin:5px 0;" autoResize="false"/>
  <h:commandButton action="#{test.doSomething}" class="pg-button" value="Add comment"/>
</h:form>

CDI bean:

@Named("test")
@RequestScoped
public class TestB {
    public void doSomething() {
        System.out.println("I work.........");
    }
}

Any ideas why POST requests are not executed? Whatever I do, they just don’t happen. No error at all. Just nothing.

When I press the submit (Add comment) button, Chrome makes a request (ajax / non-ajax (I tried both)), but method doSomething is not triggered.

I tried withing bean viewItem also (the one specified in pretty config), but nothing. I tried in 100 ways…

I have to mention that all pretty faces config mappings work perfectly on GET requests, just that I can’t post from them.

I couldn't find any solution/answer to this until now.
I would really appreciate any help.
Thanks a lot!

You should first try if this is really a PrettyFaces issue. Just remove the mapping from the pretty-config.xml file and then test the page using the original URL "/market/view-item.xhtml". As you are using a path parameter, you will have to hard-code some valid ID in your code for a simple test. If this still doesn't work, you have some kind of other issue. If you action is not executed, it's usually caused by some parent component which is rendered="false" during the postback. You could also replace RequestScoped with SessionScoped to see if this makes a difference. — chkal, Aug 02 '13 at 16:44
I think that what @chkal said is a good place to start. If this still presents a problem then please contact us on the support forums at http://ocpsoft.org/support/ and upload a small sample project that reproduces the issue. We will fix the problem and release a new version just for you because we hate bugs! :) — Lincoln, Aug 02 '13 at 19:24
Hi, guys! Thanks for willing to help. @chkal The pages .xhtml pages work properly alone. POST doesn't work just on those links mapped by PrettyFaces. SessionScoped is not what I'm looking for. For Lincoln: I will try to make a sample project for this. — zmirc, Aug 03 '13 at 08:06
Change your bean to SessionScope is just a common test to find the root cause of such problems. If it works with session scope, then the problem is usually caused by some state related problem. It wasn't meant as a long term solution. :) — chkal, Aug 03 '13 at 14:24
@chkal It seems to work properly with SessionScoped. I've played a little bit more with RequestScoped, and I've figured out that it works from the second time. So, first Post doesn't do anything (it's non ajax), reloads the page, then second Post seems to finally call the action method. Any ideas what should I do to make it work properly with RequestScoped? — zmirc, Aug 03 '13 at 17:24
In most cases the request scoped bean isn't in the same state during the postback as it was when rending the page in the first time. Usually the part of the page containing the button is nested in a component for which the rendered attribute evaluates to false in the postback case. If your button is inside of an iterating component, make sure that the list of objects isn't empty during the postback. Have a look at this question which describes the most common causes for such a problem: http://stackoverflow.com/questions/2118656/hcommandlink-hcommandbutton-is-not-being-invoked — chkal, Aug 03 '13 at 18:08
@chkal Nothing seems to be my problem. I'm trying to isolate the problem in a test project, so PrettyFaces team could check it. — zmirc, Aug 04 '13 at 12:30
Ok, sure. Just upload the application to the OCPsoft forums and we will have a look. :) — chkal, Aug 04 '13 at 13:10
@chkal I continued on OCPsoft forum: http://ocpsoft.org/support/topic/post-requests-dont-work/#post-24482 — zmirc, Aug 05 '13 at 06:00
Hi again! Well, I tried with SessionScoped and it worked, as I specified on stackoverflow. The “problem” is that I can’t isolate the error in a new project. Moreover, as specfied on stack, RequestScoped POST seems to work from the second try (first try does just refresh the page, the second does execute the method). What is your view on this? What else should I check? PS. I use Apache Tomee 1.5.2 web profile — zmirc, Aug 05 '13 at 20:05
I attached web.xml, pom.xml and pretty-config.xml here. I hope it helps. http://ocpsoft.org/support/topic/post-requests-dont-work/#post-24512 — zmirc, Aug 09 '13 at 18:27

zmirc · Answer 1 · 2013-08-15T08:39:27.230

First of all, thanks for helping. It is something strange, that's why I couldn't isolate the problem (to get it happen in another project), which is not executing the POST requests at first try, but from the second one. I have removed the filters I had in web.xml without any difference. The same behavior.

I've just had the idea of testing the project in other Tomee version than 1.5.2. Surprisingly, dev version 1.6.0 from 29.07.2013 seems to don't have this problem. Why didn't I think at this sooner? :( I had to write separate Servlet components for my post functionalities. Aaaah!

Well, this means that not PrettyFaces was problematic (Huraay!), but, probably, Apache MyFaces, CDI impl. or something else in Tomee. Uf...I'm so happy that it works now.

Thanks again for trying to help.

///////////////////////////////News//////////////////////////////////
It seems that it didn't work in other versions of Tomee neither. The problem was having a c:forEach in that page (inside a custom component used in that page), even though the commandButton was not inside the loop. By switching to ui:repeat, the problem is gone in all versions of Tomee.

It is probably a bug in MyFaces, because Glassfish 3.1.2.2 (with Majorra) doesn't have this problem. (tested)

///////////////////////////////News 2//////////////////////////////////
Ha...even more interesting.
If h:form is after c:forEach, the POST method is not triggered at first try. It works just from the second try. That's the original problem.

If h:form is before c:forEach, the Post method (action of the form) is executed properly from the first time/click.

score 0 · Answer 2 · answered Aug 11 '13 at 10:34

CDI bean:

@Named("test")
@RequestScoped
public class TestB {
    public void doSomething() {
        System.out.println("I work.........");
    }
}

Is it possible that your 'CDI' bean lacks constructor method and that could be causing the problem here?

I have been using TomEE+ ever since TomEE+ 1.5.1 'SNAPSHOT', then I migrated to TomEE+ 1.5.2 'SNAPSHOT' as soon as it was available, and then I migrated to TomEE+ 1.6.0 'SNAPSHOT', and always try to use latest versions of the 'SNAPSHOT' JAR file. I only use 'SNAPSHOT' versions this way, and 'SNAPSHOT' = 'latest and greatest'. :)

Thanks, but, as I answered in Tomee's forum, I don't think this is the problem, because all beans work properly on pages without URL rewriting. Moreover, all java classes have an empty constructor by default, so it doesn't seem to make sense. — zmirc, Aug 11 '13 at 10:47

Why JSF POST requests don't work with PrettyFaces

2 Answers2