With JSF, the following information and objects generated based on the user-created Facelets files or JSP files are registered in HTTP sessions:

• Information of HTML page windows (View state)
• Objects of the ManagedBean class with the SessionScope defined

You can use the explicit memory management functionality to control the same objects and information, as used in other Web applications.

However, whether the objects and information are registered in HTTP sessions is subject to conditions. Furthermore, not all the information registered in HTTP sessions is necessarily managed with the explicit memory management functionality. The following table describes the conditions when information and objects can be registered in HTTP sessions and whether the registered information or objects can be managed with the explicit memory management functionality.

Table 3-6 Conditions for registering the information and objects in HTTP sessions

Information or object	Condition for registering in HTTP sessions	Whether the explicit memory management functionality can be used for controlling
View information of the UIComponent (information of the View that comprises I/O interface components such as text fields, radio buttons, and submit buttons for enabling the user interaction)	When the value of the JSF standard context parameter (javax.faces.STATE_SAVING_METHOD) is "server"(default value)	Not used
ManagedBean object	When you specify the SessionScope annotation, or "session" in the managed-bean-scope in faces-config.xml.	Used
Character code to be used in pages	When an HTTP session is generated	Used
Objects registered in the SessionMap	When used in a user application	Used

If you intend to use the explicit memory management functionality, you must calculate the approximate memory size that the JSP application requires for the explicit memory management area. You can calculate the memory size with the following formula:

Memory size used by a JSF application for the explicit memory management area

 
The memory size used for the explicit memory management area in one session
=(A#+1) X 0.4 KB
+ ManagedBean object size (when registering in the HTTP session)
+ Object size when registering in the SessionMap
 

# "A" indicates the value specified in the property (com.sun.faces.numberOfLogicalViews) that is used for setting the maximum value of a JSF logical page. The default value is 15.

Notes on using the explicit memory management functionality in a JSF application

HTTP sessions are not discarded (the invalidate method of the javax.servlet.http.HttpServletRequest interface is not called) in JSF. You must therefore discard HTTP sessions (call the invalidate method of the javax.servlet.http.HttpServletRequest interface) in user applications, or set an adequate session timeout.

The JSF can use the session failover functionality in the same way as for other Web applications with objects registered in the HTTP session. You need not perform any JSF specific settings for using this functionality.

Size of objects registered in an HTTP session by a JSF application

If you intend to use the session failover functionality, use the values listed in the following table to estimate the size of objects that the JSF application registers in an HTTP session.

Table 3-7 Size of objects registered in HTTP session by JSF application

Page	Operations that use memory	Memory used
Facelets page	Mandatory objects and all tags	1.3 KB
	Page generation part of one Form tag	0.2 KB#1
	If Expression Language is used#2	0.8 KB#3
JSP page	Mandatory objects and all the tags	2.2 KB
	Page generation part of one Form tag	2.0 KB#1
	If Expression Language is used#2	0.8 KB#3

#1

The size might vary depending upon how ManagedBean is created or the ID settings of the tag.

#2

You must estimate the size for each individual resource.

#3

The size might vary depending upon how the resources are set up.

Note that the memory size values described in the table are estimated values. Use the information retrieved after executing the application to calculate the actual memory size required for an HTTP session.

Notes on using the session failover functionality in a JSF application

With the session failover functionality, if there is information that cannot be serialized with the serialization, when inheriting attributes of an HTTP session, serialization fails and you cannot save the information. This applies also to JSF applications. Serialization fails in the following cases and you cannot use the session failover functionality:

• If you specify either the SessionScope annotation, or "session" in the managed-bean-scope tag of faces-config.xml, and ManagedBean includes the information that cannot be serialized
• If the information that cannot be serialized is registered in SessionMap

You need not consider any special points for using the redeploy functionality in JSF applications. You can use the functionality in the same way as in other Web applications.

Execution of the reload functionality from a command prompt also requires no special consideration. You can use the functionality in JSF applications in the same way as in other Web applications.

However, the files that are reloaded based on the update detection have the following limitations:

Update Detection of JSP files

The update detection of JSP files is the same as the update detection in other Web applications.

Update Detection of Facelets files

Facelets files are not subject to the update detection.

The following table describes the applicability of the reload functionality when updating files in Facelets.

Table 3-8 The applicability of the reload functionality when updating files in Facelets

Files subject to update detection	Applicability of the reload functionality
	app	web	jsp
Facelets file	N	N	N
Tag file	Y	Y	Y
ManagedBean compilation result	Y	Y	Y
Static content	N	N	N

Legend:

Y: Applicable

N: Not applicable

Servlets or JSP files that are loaded with a class loader are subject to monitoring and hence the J2EE server detects when files are updated, and then executes the reload functionality. However, a class loader does not load Facelets files. Accordingly, the J2EE server does not detect whether files have been updated, and as a result does not execute the reload functionality.

To automatically detect and apply the updates made to the Facelets files, specify javax.faces.FACELETS_REFRESH_PERIOD as the standard context parameter. Facelets files are monitored for updates at regular intervals as set in the parameter, and any update detected is applied. Note that you can use this functionality only for applications in the exploded archive format.

If you update a Facelets file after executing the page output of the file, the JSF detects updates when the page is accessed next time, and displays the KDJE59227-I message.

You can use the JSP precompile functionality to compile JSP files in a JSF application.

However, you must explicitly specify the tag library and the class library to be used in the -classpath option when you use the cjjspc command to compile JSP files in the JSF application.

The following example shows how to specify the -classpath option.

The following example shows how to specify the -classpath option in the cjjspc command for compiling JSP files in the JSF application (in Windows):

	
-classpath Cosminexus-application-server-installation-directory /CC/lib/cjsf.jar; Cosminexus-application-server-installation-directory /CC/lib/cjsf.jar

You cannot assign optional names to J2EE resources in the JSTL.

Specify the relative path from java:comp/env in the datasource attribute of the sql:setDataSource tag in the JSTL.