Posts Tagged RichFaces
Close ModalPanel if no error
It has been a very long time I wrote this code, but I thought I would share it with you as it is quite useful.
If like me, you are an adept of RichFaces, you might have already seen and used the modal panel functionality. By default, a modal panel is used to display a message, but what if you actually want to display a form within it? How nice would it be if, for example, you could put your login form in a modal panel instead of opening a new page?
With the following steps, you will be able to achieve this:
- First, get the maximum severity in the message queue:
<a4j:outputPanel ajaxRendered="true"> <h:form style="display:none" id="maximumSeverityForm"> <h:inputHidden id="maximumSeverity" value="#{facesContext.maximumSeverity.ordinal}"/> </h:form> </a4j:outputPanel>This form has to be placed on all your pages using an include for example. This form will basically get refreshed on every postback and will contain the maximum severity in the message queue or null if the queue is empty.
- Create a JavaScript method which reads the
maximumSeverityhidden field:function ajaxRequestContainsErrors() { return document.getElementById("maximumSeverityForm:maximumSeverity").value > 0; }This method has to also be included in all the pages.
- Finally, use the following code for the “Submit” button in your form:
<a4j:commandButton action="#{userBean.loginAction}" value="Submit" oncomplete="if (!ajaxRequestContainsErrors()) {Richfaces.hideModalPanel('loginModalPanel');}"/>This button is actually checking if there is no error before closing the modal panel.
Upgrade to RichFaces 3.3.3.Final
From time to time, it is good to upgrade the application libraries to the latest stable version. Especially the frontend libraries as the browsers are constantly involving and new ones are coming on the market.
This is why I wanted to upgrade the RichFaces library on one of my web application which was still using the version 3.3.0.GA with JSF/MyFaces 1.2.5.
The RichFaces dependency was looking like the following in my pom.xml file:
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
<version>3.3.0.GA</version>
<scope>compile</scope>
</dependency>
The upgrade should be straightforward.
But when changing to the version 3.3.3.Final, I got the following error:
2010-10-13 15:56:14.959::WARN: Error starting handlers java.lang.NoClassDefFoundError: org/ajax4jsf/component/SequenceDataAdaptor at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:366) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:337) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:366) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:337) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:366) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:337) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:132) at org.apache.myfaces.shared_impl.util.ClassUtils.simpleClassForName(ClassUtils.java:158) at org.apache.myfaces.application.ApplicationImpl.addComponent(ApplicationImpl.java:564) at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:650) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:277) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:131) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:64) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:83) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:72) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540) at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:110) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) at org.mortbay.jetty.Server.doStart(Server.java:222) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:357) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:293) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:203) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:182) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.lang.ClassNotFoundException: org.ajax4jsf.component.SequenceDataAdaptor at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:375) at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:337) ... 82 more
What happened here? I simply changed the version number and it now does NOT work! 
Looking at the exception, it seems that it cannot find the class org.ajax4jsf.component.SequenceDataAdaptor which is part of the richfaces-impl library. Why not?
Well, in fact, it is quite simple! It appears that from the version 3.3.3 of RichFaces, you now have to specifically add the richfaces-impl dependency to your pom.xml file such as:
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
<version>3.3.3.Final</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.richfaces.framework</groupId>
<artifactId>richfaces-impl</artifactId>
<version>3.3.3.Final</version>
<scope>compile</scope>
</dependency>
Why do we have to manually add this dependency? This is because the new version of RichFaces allows you to use JSF 2.0 instead of JSF 1.2. To do that, simply add the library richfaces-impl-jsf2 instead of richfaces-impl in your pom.xml file.
Please click on the following link for the JBoss manual about this configuration:
http://community.jboss.org/wiki/HowtoaddRichFaces33xtomavenbasedproject
The selfRendered attribute
This is an interesting problem related to the RichFaces rich:suggestionbox tag.
Let’s take the following code:
<rich:suggestionbox for="q" minChars="1"
suggestionAction="#{myBean.mySuggestionAction}" var="result"
limitToList="true">
<h:column>
<h:outputText value="#{result}" />
</h:column>
</rich:suggestionbox>
If you use the code above as it is, the whole page is going to be processed each time the suggestionAction is called. And because the minChars attribute is set to 1, the action is going to be called each time the user enters a character! 
For obvious reason, such as performance issue, this is not ideal.
To avoid this behaviour, you simply need to set the attribute selfRendered to true as shown below:
<rich:suggestionbox for="q" minChars="1"
suggestionAction="#{myBean.mySuggestionAction}" var="result"
limitToList="true" selfRendered="true">
<h:column>
<h:outputText value="#{result}" />
</h:column>
</rich:suggestionbox>
Here is the description of the selfRendered attribute from RichFaces documentation:
If “true”, forces active Ajax region render response directly from stored components tree, bypasses page processing. Can be used for increase performance. Also, must be set to ‘true’ inside iteration components, such as dataTable.
Don’t hesitate to add this attribute to increase the performance of your website. 
loadBundle’s behaviour with JSTL tags
Let’s start with a bit of knowledge.
f:loadBundle is a JSF tag which loads a resource bundle and saves it as a variable in the request scope. The RichFaces a4j:loadBundle tag is a substitution for the f:loadBundle tag and allows to use reference to bundle messages during the Ajax re-rendering.
When I discovered the RichFaces tag, I immediately replaced all the f:loadBundle tags by a4j:loadBundle. Was I right? I thought at first, but then I got a problem.
The problem was appearing when I started mixing RichFaces and JSF tags.
For example, let’s take the following resource bundle:
active=true
And the following code:
<a4j:loadBundle basename="Messages" var="msg" />
Active is #{msg.active} --
<c:if test="#{msg.active}">
Hello World!
</c:if>
This displays ‘Active is true --‘.
What is wrong there? The active message is true but the c:if condition failed! 
Let’s now try the following:
<a4j:loadBundle basename="Messages" var="msg" />
Active is #{msg.active} --
<c:if test="#{empty msg.active}">
Hello World!
</c:if>
This displays ‘Active is true -- Hello World!‘.
What does that mean? It seems that JSTL doesn’t get the value of the active message but gets an empty string instead!
In conclusion, if the resource bundle is loading using the RichFaces tag, the messages will be not visible by the JSTL tags.
To fix this problem, you will have to also load the resource bundle using the JSF tag:
<a4j:loadBundle basename="Messages" var="msg" />
<f:loadBundle basename="Messages" var="msg" />
Active is #{msg.active} --
<c:if test="#{msg.active}">
Hello World!
</c:if>
As expected, this displays ‘Active is true -- Hello World!‘. 
How to configure JSF to get the browser Back button working
Lately, I had a problem with one of my JSF applications which is using RichFaces.
The problem was happening when the user was hitting the browser Back button. Well, you would say that it is a usual problem in web development. But still, because we cannot disable the browser Back button, the web application needs to work fine if the user decides to click on it!
Anyway, let’s get back on topic. As I said, the problem occurred if the user was clicking on the Back button but the funniest thing is it was happening when he was clicking twice on it! Why did it work fine when clicking once but not twice?
The solution is quite simple actually.
It was coming from one of the options in MyFaces configuration: com.sun.faces.numberOfViewsInSession.
Here is a quick explanation of this option:
com.sun.faces.numberOfViewsInSession
Specifies the number of views that are stored in the session when Server-Side State Saving is used. If set to true while client-side state saving is being used, reduces the number of bytes sent to the client by compressing the state before it is encoded and written as a hidden field. The default for this parameter is 15.
So basically, JSF is storing each page previously viewed by the user in session. And, as you can see from the description above, JSF will stored a maximum of 15 pages by default. However, it was set to 1 in my application, which means only ONE page would be stored…
This was obviously the reason why the application was working fine if the user was clicking only once on the Back button but not twice! 
For the same reason, you should also check the option org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION which is default to 20:
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
Defines the number of the latest views that are stored in session. This option is only applicable if the state saving method is set to server. The default for this parameter is 20.
For more information about JSF options, please have a look at the following page:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rweb_jsfengine.html
The message tags of MyFaces and RichFaces
Working on an application using MyFaces and RichFaces, I had no choice but understand what is the difference between the message tag provided by Myfaces (h:message) and the message tag overridden by RichFaces (rich:message).
These tags allow to display information about the first FacesMessage that is assigned to the component referenced by the “for” attribute. The difference is that the RichFaces tag has some extra functionalities such as Ajax rendering, error markers and predefined css class names.
Have a look at the following page for more details: http://livedemo.exadel.com/richfaces-demo/richfaces/message.jsf
This is all nice and well but it is not the only difference. Indeed, the HTML code generated by both these frameworks will also be different!
First of all, let’s see how the tag <h:message styleClass="errormsg" for="element"/> will be transformed. If there is no message to display, nothing will be generated (which is a good behaviour). However, if a message is present, the tag will be replaced by the following HTML code:
<span class="errormsg">Required.</span>
So far, so good!
But now let’s check what code RichFaces is generating for the tag <rich:message styleClass="errormsg" for="element"/>.
The following is the code created if there is NO message to render:
<span class="rich-message errormsg" id="form:j_id255">
<span class="rich-message-label"></span>
</span>
And here is the code which will replace the RichFaces tag if there is a message to display:
<span class="rich-message errormsg" id="form:j_id255">
<span class="rich-message-label">Required.</span>
</span>
As you can see, the main difference is that RichFaces is wrapping the original span tag into another span tag. But, it is also generating some code even if there is no message to display! You would ask why is it doing that? The response is simple. The wrapper span element is necessary for RichFaces to Ajax-render the message tag if an error message has to be displayed for the targeting element.
So make sure you don’t put any padding or margin style in your custom CSS class which I called ‘errormsg’ in my example. Otherwise, you might have a gap when you were expecting nothing… (this happened to me)
limitToList attribute prevents flashing
If you have some elements (or even the whole page) that flash/twinkle using RichFaces, it probably means that these elements are AJAX-rendering. The question is by whom and how to fix it?
A lot of tags in RichFaces can AJAX-render elements such as:
<a4j:form>
<a4j:jsFunction name="updateName" reRender="showname">
<a4j:actionparam name="param1" assignTo="#{userBean.name}" />
</a4j:jsFunction>
</a4j:form>
On the above example, the JavaScript function updateName will AJAX-render the element which has the ID showname.
In some cases, you would have some elements that would AJAX-render without asking them to do so!
I still didn’t figure it out why. (if anybody has an idea, please don’t hesitate to tell me!)
But, I found a way to prevent this!
You simply can add the following attribute to your tag:
limitToList="true"
You even can add it to the tags that don’t have a reRender attribute.
For example:
<a4j:form>
<a4j:poll id="poll" interval="1000" limitToList="true" />
</a4j:form>
Onclick event is not fired on IE
I am pretty sure everybody knows that Internet Explorer has “a few” bugs… 
You didn’t? Alright, better to stay on your little cloud and leave this blog right away!
For the others, I will talk about the JavaScript event onclick which is not fired when the following requirements are matched:
- In a form;
- There is only ONE input text element;
- There is one button which has an
onclickevent assigned; - You press the ‘Enter’ button inside the input text element.
For a better understanding, let’s now take the following example:
<html>
<head><title>Test</title><head>
<body>
<form>
<input type="text" id="t1"/>
<input type="submit" onclick="alert('onclick fired!'); return true;"/>
</form>
</body>
</html>
As you can see, there is nothing difficult in this code.
Well, that doesn’t mean Internet Explorer can handle it… 
The bug occurs if you press the ‘Enter’ button inside the input text element using Internet Explorer. Indeed, the onclick event is not fired and the text ‘onclick fired!’ is not display to the user! However, it works perfectly fine on Firefox and Safari.
The funny thing is this code works on Internet Explorer if you add another input text, even if it is hidden!
Why? Don’t ask me! 
Anyway, the following example works on IE:
<html>
<head><title>Test</title><head>
<body>
<form>
<input type="text" id="t1"/>
<input type="text" style="display:none"/>
<input type="submit" onclick="alert('onclick fired!'); return true;"/>
</form>
</body>
</html>
Why are we assigning an onclick event to the submit button?
It could be for a lot of reasons, but the main one is probably to validate the form before submitting the data.
By the way, RichFaces is very often using this event on the submit buttons.
So remember to add a hidden input text to your form if you want to allow users to use the ‘Return’ key.
No saved view state
How many of you did already get the following error when working with JSF?
I would be surprised if none of you got it at least once!
HTTP ERROR: 500
/web/home.htmlNo saved view state could be found for the view identifier: /web/home.html
RequestURI=/web/home.html
Caused by:
javax.faces.application.ViewExpiredException: /web/home.htmlNo saved view state could be found for the view identifier: /web/home.html
at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
...
This very common error happens because your session has timed out. As you probably already know, JSF is storing the view state of your page in session. Obviously, when the session has timed out, it can’t restore the view state and so throws a ViewExpiredException.
The solution for this problem is to add the following lines in your web.xml file:
<context-param>
<param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
<param-value>true</param-value>
</context-param>
When this initialization parameter is turned on, it changes ViewHandler.restoreView() to build the view before asking the StateManager for help.
However, if you are using RichFaces, for some reason this is breaking a few Ajax components!
To be honest with you, I didn’t investigate in depth why these components don’t work with this parameter set to true.
What I did instead is to make sure the session actually never times out!
To do that, I am polling the server every 29 minutes (as my session time out is set to 30 minutes). Obviously, you can poll the server only every 59 minutes if you set your session time out to 60 minutes.
Here is the code I used to poll the server every 29 minutes:
<h:form>
<a4j:poll id="poll" interval="1740000" limitToList="true" />
</h:form>
Note that the interval attribute is in milliseconds (29 minutes x 60 x 1000 = 1,740,000 milliseconds).
This solution is far from being perfect! Indeed, if, for example, a user doesn’t close his browser during the night, it means that we will have to keep the session opened during hours!
But, as far as I am concerned, it is still better than to throw an exception at the user face.
RichFaces is too greedy
For my first post, let’s talk a little bit about RichFaces.
RichFaces is a very powerful JSF library which allows you to easily integrate Ajax capabilities into your website. To see all the components RichFaces has to offer, please click on the following link: http://livedemo.exadel.com/richfaces-demo/richfaces/actionparam.jsf
I am now using this framework for about two years and I quite like how easy it is to use! However, at the start, I was only using it in small projects with less than two hundred of unique visitors a day.
That is why I didn’t discover earlier that RichFaces was using so much memory! Indeed, I am now working on a project that has nearly 50,000 unique visitors a day. When we decided to rebuild it using JSF and RichFaces, I didn’t think that 6Gb of RAM wouldn’t be enough to keep it running!
People who knows JSF would say: “Why don’t you use ‘client’ as state saving method?”. Well, because of the complexity of my pages, the size of these pages increases so much that it can easily reach 2Mb (which is not acceptable). So, I need to keep the view state on server side.
Still in JSF, there is a way of compressing the view state before saving it in session (part of the web.xml file):
<context-param>
<param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.COMPRESS_STATE_IN_SESSION</param-name>
<param-value>true</param-value>
</context-param>
Strangely enough, the second parameter (COMPRESS_STATE_IN_SESSION) doesn’t work with RichFaces. After investigating the code, it seems that the RichFaces state manager (org.ajax4jsf.application.AjaxStateManager) doesn’t support compression at all!
Why not? Well, I didn’t find a good reason so I decided to compress it myself. The solution is to extend the AjaxStateManager and compress the view state before saving it in session and uncompress it when retrieving it from the session. Pretty easy!!!
Enough talking, here is the code of this custom state manager:
package org.ajax4jsf.application;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.ObjectStreamClass;
import java.io.OutputStream;
import java.util.HashMap;
import java.util.Map;
import java.util.zip.GZIPInputStream;
import java.util.zip.GZIPOutputStream;
import javax.faces.FacesException;
import javax.faces.application.StateManager;
import javax.faces.component.UIViewRoot;
import javax.faces.context.FacesContext;
import javax.faces.render.ResponseStateManager;
import org.ajax4jsf.context.ContextInitParameters;
/**
* Overrides the Ajax state manager to enable the state compression.
* @author Stéphane Moreau
*/
public class MyAjaxStateManager extends AjaxStateManager {
/**
* Only applicable if state saving method is "server" (= default) and if
* <code>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</code> is
* <code>true</code> (= default).
* If <code>true</code> (default) the serialized state will be compressed before
* it is written to the session.
* If <code>false</code> the state will not be compressed.
*/
private static final String COMPRESS_SERVER_STATE_PARAM = "org.apache.myfaces.COMPRESS_STATE_IN_SESSION";
/**
* Default value for <code>org.apache.myfaces.COMPRESS_STATE_IN_SESSION</code>
* context parameter.
*/
private static final boolean DEFAULT_COMPRESS_SERVER_STATE_PARAM = true;
private static final int UNCOMPRESSED_FLAG = 0;
private static final int COMPRESSED_FLAG = 1;
private final ComponentsLoader componentLoader;
public MyAjaxStateManager(StateManager stateManager) {
super(stateManager);
componentLoader = new ComponentsLoaderImpl();
}
/**
* Reads the value of the <code>org.apache.myfaces.COMPRESS_STATE_IN_SESSION</code>
* context parameter.
* @see COMPRESS_SERVER_STATE_PARAM
* @param context <code>FacesContext</code> for the request we are processing.
* @return boolean true, if the server state steam should be compressed
*/
protected static boolean isCompressStateInSession(FacesContext context) {
String value = context.getExternalContext().getInitParameter(
COMPRESS_SERVER_STATE_PARAM);
boolean compress = DEFAULT_COMPRESS_SERVER_STATE_PARAM;
if (value != null) {
compress = Boolean.valueOf(value);
}
return compress;
}
@Override
protected Object[] buildViewState(FacesContext context) {
Object[] viewStateArray = null;
UIViewRoot viewRoot = context.getViewRoot();
if (null != viewRoot && !viewRoot.isTransient()) {
TreeStructureNode treeStructure = (TreeStructureNode) getTreeStructureToSave(context);
Object state = getComponentStateToSave(context);
if (isSavingStateInClient(context)) {
viewStateArray = new Object[]{treeStructure, state};
} else {
viewStateArray = saveStateInSession(context, treeStructure,
handleSaveState(context, state));
}
}
return viewStateArray;
}
@Override
public UIViewRoot restoreView(FacesContext context, String viewId,
String renderKitId) {
UIViewRoot viewRoot = null;
ResponseStateManager responseStateManager = getRenderKit(context,
renderKitId).getResponseStateManager();
TreeStructureNode treeStructure = null;
Object[] state = null;
Object[] serializedView = null;
if (isSavingStateInClient(context)) {
serializedView = (Object[]) responseStateManager.getState(context,
viewId);
if (null != serializedView) {
treeStructure = (TreeStructureNode) serializedView[0];
state = (Object[]) serializedView[1];
}
} else {
serializedView = restoreStateFromSession(context, viewId,
renderKitId);
if (null != serializedView) {
treeStructure = (TreeStructureNode) serializedView[0];
state = (Object[]) handleRestoreState(context, serializedView[1]);
}
}
if (null != treeStructure) {
viewRoot = (UIViewRoot) treeStructure.restore(componentLoader);
if (null != viewRoot && null != state) {
viewRoot.processRestoreState(context, state[0]);
restoreAdditionalState(context, state[1]);
}
}
return viewRoot;
}
private static final Object handleSaveState(FacesContext context, Object state) {
if (ContextInitParameters.isSerializeServerState(context)) {
ByteArrayOutputStream baos = new ByteArrayOutputStream(1024);
ObjectOutputStream oas = null;
try {
OutputStream os = baos;
if(isCompressStateInSession(context))
{
os.write(COMPRESSED_FLAG);
os = new GZIPOutputStream(os, 1024);
}
else
{
os.write(UNCOMPRESSED_FLAG);
}
oas = new ObjectOutputStream(os);
oas.writeObject(state);
oas.flush();
} catch (Exception e) {
throw new FacesException(e);
} finally {
if (oas != null) {
try {
oas.close();
} catch (IOException ignored) { }
}
}
return baos.toByteArray();
} else {
return state;
}
}
private static final Map<String,Class<?>> PRIMITIVE_CLASSES =
new HashMap<String,Class<?>>(9, 1.0F);
static {
PRIMITIVE_CLASSES.put("boolean", boolean.class);
PRIMITIVE_CLASSES.put("byte", byte.class);
PRIMITIVE_CLASSES.put("char", char.class);
PRIMITIVE_CLASSES.put("short", short.class);
PRIMITIVE_CLASSES.put("int", int.class);
PRIMITIVE_CLASSES.put("long", long.class);
PRIMITIVE_CLASSES.put("float", float.class);
PRIMITIVE_CLASSES.put("double", double.class);
PRIMITIVE_CLASSES.put("void", void.class);
}
private static final Object handleRestoreState(FacesContext context, Object state) {
if (ContextInitParameters.isSerializeServerState(context)) {
ObjectInputStream ois = null;
try {
ByteArrayInputStream bais = new ByteArrayInputStream((byte[]) state);
InputStream is = bais;
if(is.read() == COMPRESSED_FLAG) {
is = new GZIPInputStream(is);
}
ois = new ObjectInputStream(is) {
@Override
protected Class<?> resolveClass(ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
String name = desc.getName();
try {
return Class.forName(name, true,
Thread.currentThread().getContextClassLoader());
} catch (ClassNotFoundException cnfe) {
Class<?> clazz = PRIMITIVE_CLASSES.get(name);
if (clazz != null) {
return clazz;
} else {
throw cnfe;
}
}
}
};
return ois.readObject();
} catch (Exception e) {
throw new FacesException(e);
} finally {
if (ois != null) {
try {
ois.close();
} catch (IOException ignored) { }
}
}
} else {
return state;
}
}
}
To enable it, just add the following lines in your faces config file:
<application>
<state-manager>org.ajax4jsf.application.SearchMedicaStateManager</state-manager>
</application>
With this state manager, my web application is now using less than 1Gb of memory and is working perfectly fine!