Pass value from one bean to another using RequestScoped beans?

[john lazeraski]

Hi all,

I am trying to keep my app request scoped as much as possible. It's more of a challenge right now to see if I can do it, partly because I've done a lot of REST work and love the idea of keeping the server side request based as much as possible.

Is there a way where I can pass in a form from one page that results in a created object, then forwards to a 2nd page... that also has a form on it.. and when that 2nd page form is submitted, the created objects id (or other info) is sent with the form? Or.. more to the point, I know there is a way, I am just not sure the best way to do this.. hidden fields, path parameters, or what? I am familiar with how to do this in the old JSP way, but not quite sure how best to do it with JSF and backing beans. Appreciate any ideas on the best approach.. without using session or conversation scope.

Thank you.

[john lazeraski]

I should add that I am aware of the Flash object, and would also like to be deploy-able to Tomcat so using the ConversationScope is not an option in this case. I may need to be able to do a redirect to keep the web URL in sync with the page.. not for sure on this. I am also considering how to turn this idea into two separate components where info from the first component plugs in to the 2nd one, which could show up on a page alone, or with a "parent" employer info present IF the data passed to the employee component can find an employer object for the data (id) passed in.

[Tim Holloway]

JSF is ill-suited to the ReST approach. Because of its heavy reliance on postback mechanisms, JSF needs to maintain a lot of context, and the choices are either to pass large amounts of data back and forth between client and server (loads the network and is potentially insecure) or retaining data on the server (session-scoping).

Request scope is actually pretty useless in JSF, in fact. Anything with dataTable objects won't work in Request scope, and I suspect that dropdown lists may not fare much better.

Overall, if there is a compelling need to avoid holding session data, I would say that JSF is not the platform you want to use. JSF's optimal audience is for a relatively small number of users who are doing stuff that's heavy on self-validating input forms. If you attempt to warp JSF to avoid sessions, you'll end up losing many of its virtues. Including the fact that it's a well-understood standard, because whatever you do is likely to be very much unique to you.

You can combine ReST and JSF in a single app, but in that case, you should be using ReST for the zero-session stuff and JSF for form-heavy stuff. And take steps to ensure that sessions are only created when needed. Which probably means having basically 2 different classes of users: signed-on JSF and "bee-like" ReST users.

[john lazeraski]

Your reply is interesting... I don't have a solid grasp on the inner working of JSF 2 just yet, but my understanding of it is that it's essentially the UI layer for JEE applications. I don't understand why data tables, drop down lists, etc would not work in request scope? You return a response page which can pull data from the database if need be to render the data tables, drop down lists, etc. I fail to see why you need session scope for this?

I asked the question partly because I always try to think of the best way to handle scaling, and remaining as stateless as possible is one way to avoid having to worry about large object replication of the session across nodes.

I am also referring to a couple of posts I've recently read...

http://balusc.blogspot.com/2013/02/stateless-jsf.html which refers to https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1055

It seems a lot of people want a way to use JSF in a stateless manner where it makes sense.

[Tim Holloway]

JSF is more than just a simple "UI layer".

It is one of the purest implementations of the Model/View/Controller paradigm done for the HTTP (web) environment.

In MVC, the Controllers act as the intermediaries to cause changes to the data in the Models to be reflected in the Views and vice versa. You rarely see (much less code) Controllers in JSF, since they're pre-supplied as part of JSF itself, but they still function exactly as a non-web Controller would with the exception that since HTTP cannot make unsolicited updates to clients, View updates cannot occur asynchronously.

Wherever possible, JSF attempts to use POJOs for Model objects. Two cases where it cannot are tables (need row context) and Select items (where the data value and displayed values may not be the same thing). For these model objects, JSF provides decorator classes to add the missing JSF functionality to their underlying POJOs.

One of the problems with MVC, however, is that you cannot update/query a model unless it exists. And Request-scope objects, by definition, only exist for the duration of the request. Once the request has been responded to, the request objects are destroyed. A subsequent request would require re-constructing the destroyed objects, and in the case of the JSF model classes, they lack the ability to re-construct themselves in the exact same state that they had been in when destroyed.

JSF is also very much about interactive editing. You don't just throw a page up, input from it, then go on. JSF is extensively into input validation. So if you enter invalid data, the page is updated, including an error message(s) that indicate the invalid data, the user corrects the data and re-submits the page. And repeat until they get it right. Application code doesn't even get involved, as JSF itself takes care of the process. The mechanism by which this occurs is called "Postback". And, again, if you destroy the model objects that are being used to re-render the successive displays of the page, you are going to have a bad time.

Of course, some of the Model support objects don't need to hang around once the page has passed editing and a new page has been presented. However, since Session (or Application) scope is the only J2EE-sanctioned way to retain data between HTTP requests, this led to a lot of objects that were basically dead unless forcibly removed. JSF2 recognized this need and added View scope, which is essentially Session Scope with the ability to discard these dead objects automatically when they're not longer needed.

ReST is not MVC based. For that matter, it really isn't a UI approach at all. So they don't have such limitations.

[john lazeraski]

Hi,

I agree with you with what you have said, makes sense. The whole post-back thing to handle automatically validating data, updating errors, etc using ViewScope.

But you didn't provide any thought on those two articles I pasted on.. which I guess is my stumbling block.. why is there a push for request based handling... which from what I gather as many said in the issue tracker that JSF doesn't offer a way to handle load very well.. without the ability to have stateless as an option, you're forced to use their session management for everything.. although if you use RequestedScope for every bean I guess the only purpose for the extra tag in BalusC's article is to avoid the view being created on the server side, thus saving on resources.

So my guess with what I know now is that IF we use the statelessness option, then post-back is basically broke, so the developer is on their own to implement validation, error messages, etc. But the trade off is they could build more responsive scalable JSF2 applications with the benefits of using JSF2 for UI rendering.

[Tim Holloway]

MVC is inherently stateful. That's what the Controllers do - reflect changes in Model state and allow the View to make changes in Model state.

Sorry I missed your links. I do that. :(

Essentially, what they are really looking for is not really to make JSF stateless (whether they realize it or not), as it is to make it sessionless. And to reduce/eliminate storage and construction of the Component tree (more on this shortly).

Sessions have both advantages and disadvantages. Their advantages are that since they're basically in-RAM storage, access to session objects is extremely fast. The disadvantage is scalability. The amount of required RAM is basically b*n, where "b" is the amount of session ram required for a single user (session) and "n" is the number of concurrent sessions. Also, unless you have clustering enabled, the same computer is stuck with the job of handling the user's session for the life of the session. If you do have clustering enabled, you have extra overhead as the session is transferred back and forth between CPUs in the clusted, either via internal pipelining or storage media (cluster disk files or database objects).

A ReSTful approach scales very well, because there's no need to transfer sessions around. Just put a rotary switch at the head of the cluster, forward the request to the next idle CPU in the group, and let it go. However, the downside is that ReST requires extra overhead unless you're stateless, because the state has to be retrieved and/or reconstructed for each request. It partially pays for itself because you can add CPUs virtually ad inifinitum, but each CPU is working a bit harder. And, as I said, MVC is stateful just because of what it is.

In addition to session objects, another obstacle to scalability in JSF is the component tree. A component tree is built for each View (page). Initially, it is constructed by compiling the View Template (.xhtml, in JSF2). Thereafter, it is kept stored in one of two ways: server-side or client-side. Server-side is default. Server-side has the same basic advantages and disadvantages as Session objects do, although note that the Component Tree is not a session object itself nor is it session-related. Client-side lightens the server requirements, but there's overhead to transferring the component tree back and forth on each request. Plus anything that makes a trip to the client and back is potentially hackable. Those are also reasons why I'm not an advocate of attempting to use Request scope for MVC session information.

View Component trees are kept in cache. That's partly for general performance and partly to make sure that the client browser's "back" button will work properly. There are only a finite number of Views stored in this cache, however, after which you get a ViewExpiredException, which is another headache of JSF.

JSF made a lot of improvements towards reducing the Component tree overhead, but I don't expect that we're anywhere near perfection on that. Generally when a process has reached maturity it becomes simple enough to be explained in books on the topic and stops being arcane magic processes known only to a few illuminati.

Or, to take the tl;dr executive summary:

ReST: optimal case is stateless non-conversational request/response.

JSF: optimal case is stateful and conversational.

[john lazeraski]

Thank you Tim for taking the time to continue to explain in detail. I appreciate it. I have a better understanding now of what you are saying.

It's funny.. because I was originally going with Wicket, but read that it's more of a low user count sort of framework, better suited for administrative web apps, Also, it has a bit of a learning curve to it. I then interviewed for a job that was using ext-js, and I really liked it. I loved the ability to use Swing like layout managers and the large array of components that made the web look nice. But like Wicket, it was heavy server side and apparently is also not ideal for a large scale site. So then JEE 7 dropped not too long ago and I thought.. may as well start relearning the latest JSF 2 and use it since it's part of JEE. So from various forums around the web I felt like JSF 2 was up to the task of a large scale site, but from what you are saying, it's also like Wicket and ext-js, in that it's heavy on the server side and thus not the best to use for handling tons of clients at one time.

So now I am starting to ask.. what is a good light-weight easy to use UI framework other than pure html/css hand coded in jsp pages that uses Java? Please don't tell me Ruby, PHP or python lol. I am learning python now anyway, but I would hope there is a good developers framework that would not require me to be an expert in css layout and browser compatibility issues, yet light enough to provide decent scalability options.

I'll be sticking with JSF 2 for a while as the app I am building would be lucky to have a few hundred users at the same time, which I hope a server of todays specs (32GB ram, quad to 8 core cpus, plenty of HD) can handle that many users.

[john lazeraski]

Alas with all your good info I got away from my question..

So.. I'll bite on the idea that perhaps I shouldn't be trying to stick to pure stateless with JSF. However, I am trying to build my site so that it "helps" users when they first log in to show some pages that they *should* fill out (and options to skip, etc), but at the same time those forms (wizard setup style) should be directly accessible later on once they are logged in to add/edit/delete.

As an example, each user can have one or more emails, one or more addresses, etc. I've not quite mastered the building of a component, but I was hoping to put each of these forms in components so I can reuse them as needed in different parts of the site. My original question was about a parent/child two page component.. perhaps that's not the right way to say it. But, during the wizard/setup step the user MUST enter a parent, then hitting next saves it, then the next page shows the child form. This could pertain to any number of scenarios, so I am using parent and child loosely here. The problem is, when the child form is submitted, it needs a reference to the parent form in order for the ejb to associate the child to the parent (one to many mapping). That is why I thought about passing the parent id via a hidden form field in the child page. Before you answer.. the thing here is the child depends on the parent id for the proper association. But, during the wizard/setup, the UI layout will be different than after they complete it and later log back in to add another child to the parent. At that point, the parent would be in a drop down list along with the child form, so the user could choose the parent, then fill in the child info and all of it submits fine.

I am also asking this to understand how a component that depends on another can be separated as a component independently from the parent component, or if that is even possible. It's sort of like an interface.. where the child component expects a specific interface implementation (the parent id for example) to be passed to it, and then the back end code figures out what to do with the child form and parent id passed in.

Confused yet? Shoot I think I am! So much easier to white board these sorts of things! Anyway, hopefully you get the gist of what I am trying to do and can maybe steer me in the right direction with regards to JSF.

Again, thank you.

[Tim Holloway]

OK. I'm sure I'll miss something, but we'll see how much of that I can cover.

Hundreds of users and JSF is not something I have any solid numbers on. You might be better off using Struts, but I also have no benchmarks for that framework on this sort of thing. JSF is easier to work with than Struts, but I think Struts might make it a little easier to cut down on some overhead. The good news is that JSF is not a jealous framework and apps can be written that employ JSF, Struts, and raw servlets/JSPs all in the same app (as well as other alternatives), all doing what they do best.

As for the "quick-and-dirty" platforms, their problem is that they are exactly that. Quick and Dirty. They don't have the security or even general scalability of J2EE and often once you get past the basic "gee-whiz" instant app stuff and into the ganrly real-world junk, they can be more liability than asset. I mostly use Python for command-line quickies, although Django is nice for what it does. For quick apps, my go-to is PHP. But the heavy industrial stuff is when I switch to Java.

I'm not sure I got your flow requirements right, but JSF - and Struts - are good at "wizard-style" data input workflows. JSF isn't very good for "pop-up window" workflows, but I don't like having browser windows/tabs opening up all over my already-crowded screen anyway. You can get a "pop-up dialog" equivalency from some of the extension tagsets such as RichFaces, but they do tend to be a bit of a pain.

As far as parent/child "forms" are concerned, in JSF the main thing is not the View, it's the Model. When a wizard sequence is being processed, it's common to have a shared backing bean (Model) object maintain the composite data and possible "helper" Models handling the per-View specifics. In practical terms, that means that the Wizard core object is a session-scope object and the individual view models are typically View-scoped (or, when possible, Request-scoped) with the master (core) object injected into them so that they can reference/update the core data as needed.

One of the advantages of the Model/View/Controller architecture is that the same Model can be presented in different Views having different appearances. Even at the same time, if you like. A classic example of that would be where on-screen you have both a graph and a spreadsheet view of some particular model data. That's because when properly designed, Models and Views are completely self-contained and the Controllers are what bind them to each other.

[john lazeraski]

Was just about to send you a PM and see you replied here. Thank you. My primary concern with performance is that it can handle scaling if needed. For that to work, in the case of JSF which is heavy session scoped (including view scoped that is stored on the session I think but then managed/removed by the framework), there needs to be the ability to fail over the session state to other servers (one or two more) for fault tolerance, as no doubt you understand. In the case of handling large numbers of users, usually in the case of a stateful application a smart router has to be employed that can ensure a request with a session cookie is routed to the same server continuously.. but in the case that server dies, it has to know the other server(s) in a cluster to send the request to, of which those server(s) would have had the session state replicated to them pretty frequently. Back in the JEE 1.0 days, when I worked with Orion server, there was a notion of islands, where each island had 2 or 3 servers in it and every single HttpSession.setAttribute() call would replicate the session state to the other one or two servers. The router was also an Orion server that was aware of what servers were in a cluster (island) and thus could properly ensure the request would go to one of the two or three servers in the same island, even if one server died. You could then scale up and add more islands, to handle more load. I've not had the pleasure of working with a large site for many years so I am not sure to what extent Tomcat, Glassfish, Jboss.. scale in this manner. The past many years I've mostly dealt with REST api's and that is easy to scale.. simply add more servers and a round robin or load-watching router to the mix.

I've yet to see any books that really explain how to scale a site using JEE 6/7 technology including how to handle JSF, sessions, etc. I am going out on a limb to guess that the method of handling scaling is not that different from what I've explained above. Have you had a need to add more than one server for JSF based apps, if so, what was the process you took to handle more clients, peak client load times, etc?

I am still rather confused with the whole notion of number of requests and number of threads a server can handle at once. This no doubt also has to account for processors and speed, as well as RAM and caching and HD space to some degree. But given today's cheap servers are much much faster than what we had 8 or so years ago (last time I dealt with scaling), I'd guess that a single 8-core AMD server with 32GB ram could easily handle hundreds of simultaneous users with little problem. The good thing is, my apps market size is about 100,000 users.. and if we can be lucky enough to gain 1% of that market, we're going to be doing quite well.. but still I always think about being ready to scale from the start.. rather than an after thought. To me, the architecture of the app plays a role in how well it will scale later on, so thinking about it up front makes more sense to me than waiting and hoping I didn't cludge together a crappy app and have to spend more time rewriting it!