permaculture playing cards*
The moose likes JSF and the fly likes Http Session Attributes of type javax.faces.component.UIViewRoot into a JSF 1.1 Web App Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Http Session Attributes of type javax.faces.component.UIViewRoot into a JSF 1.1 Web App" Watch "Http Session Attributes of type javax.faces.component.UIViewRoot into a JSF 1.1 Web App" New topic
Author

Http Session Attributes of type javax.faces.component.UIViewRoot into a JSF 1.1 Web App

Nirmal K Singh
Greenhorn

Joined: Jul 15, 2003
Posts: 1
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:

/mywebappfolder/myjsppages.jsp

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?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15958
    
  19

Welcome to the JavaRanch, Nirmal!

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.

Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Http Session Attributes of type javax.faces.component.UIViewRoot into a JSF 1.1 Web App
 
Similar Threads
Session Size
Internet Explorer expires session when sent from secure to non secure page
Losing session attribute
Mock exams for JSP
Request Attributes Thread Safe?