Sessions and Controllers best-practice in JSF2

[jmsjr]

Hi,

I've not done web development work since last using Apache Struts for its MVC framework ( about 6 years ago now ). So bear with me if my questions does not make sense:

SESSIONS

1) Reading through the JSF2 spec PDF, it mentions about state-saving via the StateManager. I presume this is also the same StateManager that it used to store managed-beans that are in @SessionScoped ?

2) In relation to session-scoped managed beans, when does a JSF implementation start a new session ? That is, when does the implementation such as JBoss7 call ExternalContext.getSession( true ) .. and when does it simply uses an existing session ( calling ExternalContext.getSession( false ) ) ?

3) In relation to session-scoped managed beans, when does a JSF implementation invalidate a session ? That is, when does the implementation call ExternalContext.invalidateSession() ?

4) Does ExternalContext.getSession( true ) or ExternalContext.invalidateSession() even make sense if the state-saving mechanism is client ? ( javax.faces.STATE_SAVING_METHOD = client ) Will the JSF implementation ever call these methods if the state-saving mechanism is client ?

When working with Struts long time ago, __I__ have to ( or the application developer, not the framework ) decide when to start a new HttpSession and when to invalidate the session.

With JSF, the annotation with @SessionScoped suggests to me that the JSF implementation itself will create an HttpSession by itself, but I would like to know when is a new one created, or when an existing one is used, and when it invalidates the current session.

CONTROLLERS

Most of the JSF2 tutorials that I have been reading on-line uses the same backing-bean when perfoming an action on the form ( when doing a POST or a GET or a post-back to the same page ).

Is this best practice ? It looks like mixing what should have been a simple POJO with additional logic that should really be in a separate class.
What have others done ?

[nickarls]

Hmm. Perhaps the mojarra-people have more details but comparing with CDI, I would think the actual session instances are kept in the session and the statemanager is more for handling JSF view state.

I think sessions are created when they are needed, i.e. when a session scoped bean is being accessed for the first time. In the same manner, I would guess that invalidation happens when the session times out

(as set be web.xml or some other mechanism) or when the session is explicitly killed. And regarding the client state, I think we are talking about view state.

Regarding controllers I would say that with EE6 lots of the old "J2EE patterns" are not needed. If you know you are going to write a web application,

I have no problems in writing a backing bean that couples with JSF (using a change listener) and persisting entities which are used by the view.

If I need another sort of client, I can break out the JSF parts, add interfaces etc. That's why the people at Eclipse made refactoring so easy.

Die, DTO:s. Respawn where appropriate.