This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
HTTP is a request/response protocol. Regardless of whether you're programming in JSF, Struts, raw JSP, servlets, or even Perl or Python, assembly Lnaguage, C or FORTRAN, the #1 rule is this:
For every request there must be a response.
It's why no HTTP service can ever do do true MVC - an HTTP server cannot send out an unsolicited response, and it's why you can't have what you want; every request must be followed by a response. Even AJAX isn't immune to that most fundamental of strictures.
On the other hand, in JSF, the default response is to redisplay the requesting JSF page, so visually it makes no difference other than a delay and maybe a screen flicker.
If, however, you want your page to post data to some other location and remain on the current page, what you can do is have the JSF action method do an HttpURLConnection request from the JSF server to the other location. Which can be on the same server or any other server in the world, as long as the JSF server can access it. The Secondary server must response with something, since it's subject to the First Law of HTTP, although a simple empty "200 OK" status is good enough. Once your JSF backing bean's action method sees that response, it can then complete its action - or, if something went wrong, it can throw an exception or something.
An IDE is no substitute for an Intelligent Developer.