Where is FacesContextFactory instance stored ?

[Ronald Wouters]

Hi all,

I am new to JSF and just read the JSF chapter in the Java EE tutorial and the JSF 1.2 specification. What is not clear to me is the following. I understand that the FacesServlet is the "initial point of contact" lets say for a jsf app and that each request is associated by a FacesContext instance which is created/retrieved by the FacesContextFactory. However, where is the factory instance itself stored by the Sun implementation of JSF ? I know JSF is built on top of the Servlet 2.3 or later spec so my first guess would be that the FacesServlet stores this FacesContextFactory in the servlet context of the web app. Is this guess correct ?

Regards

[Tim Holloway]

The JSF environment is completely created - and destroyed - with each JSF resquest/response cycle. There is no instance of the factory object, it uses static class methods.

Any data you want to pass from request to request has to be done using object of your own construction.

This keeps overhead for JSF itself down at the cost of not being able to recycle anything. As a consequence, however, you can easily intermingle JSF and non-JSF requests (JSP, Struts, servlets, etc.) since the intermingled requests don't have to worry about damaging the JSF state. There is none.

[Ronald Wouters]

...since the intermingled requests don't have to worry about damaging the JSF state. There is none.

In the Java EE 5 tutorial it says this about the "Restore View Phase" of the lifecycle of a jsf page :

If the request for the page is a postback, a view corresponding to this page already exists. During this phase, the JavaServer Faces implementation restores the view by using the state information saved on the client or the server.

This seems to contradict what you mentioned. What am I missing here ?
Regards

[Ronald Wouters]

I also read the following in the JSF 1.2 specification :

A single instance of javax.faces.context.FacesContextFactory must be made available to each JSF-based web application running in a servlet or portlet container

and

The factory instance can be acquired, by JSF implementations or by application code, by executing:

FacesContextFactory factory =
(FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);

The FacesContextFactory implementation class provides the following method
signature to create (or recycle from a pool) a FacesContext instance ...

public FacesContext getFacesContext(Object context, Object
request, Object response, Lifecycle lifecycle);

The above suggests to me that the FacesContextFactory instance stores some kind of "view" state that is "injected" in the FacesContext instance when a new request/response cycle starts.
That is what prompted my original question about where the FacesContextFactory instance was stored...
[ September 13, 2008: Message edited by: Ronald Wouters ]

[Tim Holloway]

Not exactly. You're confusing the application's Faces Context with the FacesContext object. The context is pure data and you can configure JSF to either pass that data back and forth between client (browser) and server or to maintain the data on the server - one technique makes the web pages fatter and adds transmission overhead, the other replaces these problems with an increased resource load on the server. It can also make a difference if you're clustering JSF servers.

The factory uses this context as input to (re)create the JSFContext when the JSF servlet begins processing an HTTP request. The factory itself is a singleton object. As a general rule, the Factory design pattern discourages factories from having states - they should produce a uniform product.

If you select the server-side context option for JSF, the factory isn't required to expose where it's getting the information from or even what form it's in - just be able to reconstruct the Faces context on demand.

Note also that I said intermingled non-JSF requests don't have to worry about damaging the JSF state. The JSF state is related to JSF views and not the application in general.