I am currently investigating a legacy JSF web app based on JSF 1.1 RI. Its deployed on WAS 7.0. Just in case its important, it is also using IBM JSF component library viz. jsf-ibm.jar.
I have found many objects of type javax.faces.component.UIViewRoot inside my server side session object i.e. javax.servlet.http.HttpSession. These objects are saved against some attributes named as follows:
I suspect these attributes are implicitely saved into http session by JSF framework to maintain view state because i could not find any explicit code doing the same. I tried to prove my doubt by creating a tets JSF 1.1. web app and investigating its session attributes but i did not find similar attribute there.
So now I am wondering how exactly this object gets set as a session attribute? Anyone any idea?
If you have lots and lots of code that accesses JSF-specific classes such as UIViewRoot, you may be better off rewriting the entire webapp. The reason being that JSF was designed to be primarily POJO-based, and the presence of lots of javax.faces stuff that isn't datamodel objects is usually a screaming indication that the original author(s) had no idea what they were doing. Aside from that, there's also a much higher chance that they've coded things that broke when JSF2 came out, since they're more intimately involved with the inner workings of the JSF1 implementation than POJO objects would be.
But aside from that, The UIComponent tree of JSF is not a session object in either JSF1 or in JSF2. It lives in its own little world. Depending on the options that were set in the webapp's web.xml file, the component tree may be passed back and forth between client and server or it may be stored by JSF solely on the server. The option depends on how much server overhead you want versus how much network overhead, as well as some security concerns (anything that gets sent to/from a client can be hacked).
The mechanisms for handling the UIComponent tree are automatic. You don't need to code anything other than basic configuration parameters. As I said initially, if someone was coding so close to JSF internals that the automated mechanisms don't serve, you don't have a webapp so much as you have a bucket of fishing bait.
An IDE is no substitute for an Intelligent Developer.