They can also cause issue with duplicate IDs if the ID of the bound component is auto-generated
On 4/9/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
Phanidhar Adusumilli wrote: > Section 3.1.5 of the JSF specification, recommends not use component > bindings at session/application scope. > > What are the issues in binding components to manged beans at > session/application scope? A UIComponent object has references to its parent and all its children. Therefore if you store a reference to any UIComponent in a session-scope bean then the entire component tree for a particular view is kept in memory. Session-scope backing beans are generally a bad idea anyway; they waste memory as they are created when a user accesses some view then hang around until the user logs out even if the user never revisits that view. If this object has a reference to a UIComponent, therefore keeping an entire component tree in memory too (see above) then that's even worse. There are some cases where session-scoped beans are appropriate but normal "backing beans for views" should be request-scoped wherever possible. Referencing a component from an application-scope bean (ie one shared between users) just makes no sense at all. Components are not thread-safe but application-scope beans are shared between users and therefore must be thread-safe.
