What you have been tasked with is problematic under JSF. JSF isn't an HTTP framework, it's an abstract Model/View/Controller framework which simply happens to be most widely implemented using HTTP as a transport mechanism. That's why JSF forms don't contain method or action attributes. Those properties are not generic MVC properties.
The actual communications within JSF are done via POST requests and the URL that's posted to is not always an indicator of what the objects being controlled are - it's more of a "handle" that JSF uses. The POST data will include JSF-specific meta-data, and JSF AJAX POSTS will, of course be partial form submits, but will still include JSF meta-data and will, again, not necessarily have a URL that maps to the current View resource.
Because JSF is MVC, and not actually HTTP, there aren't, strictly speaking, "request parameters". What JSF is attempting to do is what MVC does, which is to synchronize the values of the backing bean (Model) properties with the values of the form controls (View) and vice versa, using JSF's internal Controllers to do so. JSF will attempt not to update data unless the data is actually determined to be out of sync, and, of course, submitted data must be valid or JSF will reject the entire incoming data set, refuse to update the Model and not invoke the command action. A consequence, incidentally, of the validation mechanism is that JSF expects the same form may be repeatedly POSTed until all submitted data has been made valid by the remote user.
Having said all that, you can do a brute-force capture of traffic (it is, after all still HTTP underneath, just not a straight mapping).
1. Use the "redirect" modifier on navigation to cause the URL to map to the currently-requested resource instead of operating in "handle" mode. This is extra overhead, however and it only changes the URL target. The payload is as ugly as ever.
2. JSF can be entered via simple "GET" requests, although the actual lifecycle once entered is POST-based. JSF2 permits GET request parameters, and the third-party PrettyFaces framework not only supports GET parameters, it supports custom URLs, including URLs where the parameters are part of the URL itself. But again, once a form has been displayed, the postbacks are always JSF POST requests.
3. JSF is not an exclusive framework. Meaning that while the JSF parts of a webapp operate under JSF rules, you can also have generic servlets and JSPs and even other non-greedy frameworks such as Struts operating in the same webapp. All of those will operate using the same URL formats and contents that they would without JSF as part of the webapp.
Incidentally, the brute-force type of data capture you are looking for - aside from requiring a lot of extrapolation to allow for JSF - is likely to add significant overhead to each and every web request. If you're looking to audit, I'd suggest something more refined. If you're looking for general network/protocol troubleshooting and tuning, consider something that can be switched on and off externally. For example, the Tomcat webapp server has a Valve that can be wired in that captures raw traffic. Likewise, at the OS level, you may be able to use something like "tcpdump" to do so.
Loudly announcing something is true and finding out you're wrong makes you feel foolish.
Finding out you're wrong and refusing to admit it makes you LOOK foolish.