• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to get method expression from ajax request in JSF 2 portlets

 
Flemming Unnerup
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm required to implement audit logging of all action requests. The logging should contain the action name and request parameters.

I have implemented the logging in a phase listener (PhaseId.INVOKE_APPLICATION).

I'm having trouble figuring out how to get the action name from ajax requests. More specific when the form command button does not contain an action attribute:



Calling the UICommand object (which represents the pressed button) getActionExpression method returns NULL.

Any ideas on how to solve this will be highly appreciated.
 
Tim Holloway
Bartender
Posts: 18411
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Flemming!

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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!