post-redirect-get in JSF 2.0

In Burns's and Schalk's JAVASERVER FACES 2.0: THE COMPLETE REFERENCE, the authors do some exercises regarding redirects. There are new facilities in JSF 2.0 to allow using redirect to easily follow the post-redirect-get convention (instead of the normal JSF post-forward convention). Now with these facilities we have bookmarkable url’s in our web browser. We also expose some of our parameters to whomever looks at their address line. Under some circumstances this is OK.

The conversion of a page that does not use this to one that does is pretty quick. I took the same book's registration application and converted it to use PRG (post-redirect-get) in one airplane ride (3 hours) and I only worked 2 of those hours, and I worked very slowly.

There are apparently two ways to communicate between pages that use redirect in JSF 2.0. One of them is to use a new “scope” called Flash. Flash allows you to store information between redirected pages; apparently request scope does not. Redirecting makes a second request, whereas the normal post-forward does the page/view navigation all in one request. So that means that things stored on request scoped managed beans will persist from one page to the next, while redirects will re-instantiate request scoped beans.

The other way to store stuff in between redirects is to pass parameters on the request url. Interestingly the new view parameter facility has the parameters defined on the page you are going to. If you define them on this page/view, then there they will be…on your request url, as if you had put them there yourself (which you did…indirectly ;-)

Interestingly enough, ADF 11g, the controller portion, has solved the same issue in JSF 1.2 with something called bookmarks. These bookmarks make a structure called a task flow compensate (like view parameters and redirecting combination in JSF 2.0) for the same issue. I suspect in the long run ADF will adopt JSF 2.0. I wonder if at that point, view parameters will have something to do with the implementation of bookmark parameters.

thread dump for OC4J JVM

To get a thread trace on a JVM, make sure your opmn java-options in your start-options does not include -Xrs. (If you had to remove it, be sure to restart your AS (maybe the OC4J restart would be enough...)) This -Xrs option reduces signaling capability. Then (in UNIX) you get the JVM process id to kill. One way is through Enterprise manager. In 10.1.3.4 EM, in your topological list of oc4j's, you should have a link showing how many JVM's you have for each oc4j you have in you iAS. If you click on this, the resulting page will show you your process id. If you then type

kill -3 <theprocessidyoujustlookedup>

and hit enter, your opmn log (you know: the one in $ORACLE_HOME/opmn/logs that has your oc4j's name in the middle of it, with tilde's in the name...*THAT* log) should display a lovely thread dump.

I wanted a thread dump because such a thing seems to be how Oracle characterizes their bugs against their iAS. So for example they might say, if a thread dump shows the following...then you have this problem...and here's how to fix it.

Thanks to Mike Lehmann for his helpful article, which you can see, is just a click away; I basically took what he did, distilled it and added the things I had to go look up.