@SessionScoped bean injected into @ViewScoped bean losses iproperty values

[Alfonso Mateos，修改在8 年前。]

Hi guys,

I try this:

I've got a view named menu.xhtml, with this inside:

<p:commandButton value="test sessionscoped" ajax="false" immediate="true" action="#{massiveRecruitingBackingBean.showMenuSession()}"/>

From the referenced backing bean (that is @ViewScoped, I also tested it with a BackingBean @RequestScoped and a Model Bean @ViewScoped with an inner property that was movementsNavigationModelBean, but I expose the simplest case I tested):
@Inject
MovementsNavigationModelBean movementsNavigationModelBean;

public String showMenuSession() {
movementsNavigationModelBean.setProcessInstanceId("3333");
return "/views/menuSession.xhtml";
}

Inside the target view menuSession.xhtml:
<div class="ep-main-menu">

ProcessInstance stored in session scoped bean is (expected value is 3333): <h:outputLabel value="#{movementsNavigationModelBean.processInstanceId}"/>
</div>

When I debug the code I see that movementsNavigationModelBean beanis not null but property instance is gone in the view.
I'm using this reference for RequestScoped:

import javax.faces.bean.RequestScoped;

Not this:
import javax.enterprise.context.SessionScoped;

Can you give me any hint on what's my mistake or how to workaround this in case I can?
Thanks in advnce.

[Juan Gonzalez，修改在8 年前。]

Hi Alfonso,

did you tried using

@ManagedProperty

instead of

@Inject

?

[Alfonso Mateos，修改在8 年前。]

Hola Juan,

I continue in english so that everybody can follow the issue...
When I use @ManagedProperty it works but.... I face an issue that I did not find with @Inject: I drop my portlet in my site's private pages, and:

1.- deploy the portlet
2.- sign in
3.- go to page menu.xhtml, clic my commandButton and menuSession.xhtml is shown with the correct value from my @SessionScoped bean.
4.- go back to menu.xhtml

Now the tricky part:
5.- deploy my portlet again
6.- refresh my webpage
7.- click my commandButton

and then it does not even show menuSession view:

Error Interno del Servidor
Se ha producido un error al intentar acceder a la página solicitado.
http://localhost:18080/es/group/guest/home?p_auth=YY4di74x&p_p_id=epsilonmenu_WAR_epsilonliferayportlet&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=3&_epsilonmenu_WAR_epsilonliferayportlet__facesViewIdRender=%2Fviews%2Fmenu.xhtml

and I get the following error in my log (can't restore view):

Caused by: javax.portlet.faces.BridgeException: javax.faces.application.ViewExpiredException: viewId:/views/menu.xhtml - No se pudo restablecer la vista /views/menu.xhtml.
at com.liferay.faces.bridge.BridgePhaseActionImpl.execute(BridgePhaseActionImpl.java:87) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
... 183 more
Caused by: javax.faces.application.ViewExpiredException: viewId:/views/menu.xhtml - No se pudo restablecer la vista /views/menu.xhtml.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:205) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.21.jar:2.1.21]
at com.liferay.faces.bridge.BridgePhaseActionImpl.execute(BridgePhaseActionImpl.java:81) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
... 183 more

In order to avoid this error I tried to go the @Inject way.

Also, I tried the following:

- I put my @SessionBean bean as a property of a ModelBean, declared as @ViewScoped.
- From my backing bean I set my SessionBean's property value.
- Then in my menuSession.xhtml I try to show myModelBean.mySessionBean.myProperty and I get a cast exception:

10:05:44,959 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-/0.0.0.0:18080-6) Error Rendering View[/views/menu.xhtml]: com.sun.faces.mgbean.ManagedBeanCreationException: No se puede definir la propiedad movementsNavigationModelBean para el bean administrado massiveRecruitingModelBean
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:615) [jsf-impl-2.1.21.jar:2.1.21]
....
....
Caused by: javax.el.ELException: JBWEB006003: Cannot convert es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean@3d4fb695 of type class es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean to class es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:405) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:49) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:34) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at com.sun.faces.el.ELUtils.coerce(ELUtils.java:536) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.BeanBuilder$Expression.evaluate(BeanBuilder.java:592) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:606) [jsf-impl-2.1.21.jar:2.1.21]
... 281 more

Those errors are gone if I logout + login again....
I don't know how to face this and get a solution....
Thanks in advance

[Juan Gonzalez，修改在8 年前。]

Alfonso Mateos:

Now the tricky part:
5.- deploy my portlet again

That's the real issue. When redeploying your portlet session will probably be gone, and your view state will be gone too.

Probably you can try with:

return "/views/menuSession.xhtml?faces-redirect=true"

or adding <redirect> for that navigation case in your faces-config.xml using @ManagedProperty approach.

[Alfonso Mateos，修改在8 年前。]

If I set return "/views/menuSession.xhtml?faces-redirect=true" from my backing bean I get the following error when I click my commandButton in menu.xhtml, even right after logging in:

10:39:37,531 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-/0.0.0.0:18080-1) Error Rendering View[/views/menuSession.xhtml]: java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called
at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:363) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at com.sun.faces.renderkit.html_basic.FormRenderer.getActionStr(FormRenderer.java:232) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.renderkit.html_basic.FormRenderer.encodeBegin(FormRenderer.java:134) [jsf-impl-2.1.21.jar:2.1.21]
at com.liferay.faces.util.render.RendererWrapper.encodeBegin(RendererWrapper.java:42) [liferay-faces-util-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
at com.liferay.faces.patches.faces1513.FormRendererPrimeFacesImpl.encodeBegin(FormRendererPrimeFacesImpl.java:71) [liferay-faces-1513-patch-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Nov 20, 2014 AD)]
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:826) [jsf-api-2.1.21.jar:2.1]
...
....

[Juan Gonzalez，修改在8 年前。]

Are you using CDI anywhere in your project? Did you use @ManagedProperty as I've said some posts before instead of @Inject?

[Alfonso Mateos，修改在8 年前。]

Yes, I'm using CDI in my project. In my BackingBean I've got several properties that are injected via @Inject, but they aren't @SessionScoped.
In that backing bean I made sure that the property representing my @SessionScoped bean is annotated with @ManagedProperty:

@ManagedProperty(name = "movementsNavigationModelBean", value = "#{movementsNavigationModelBean}")
private MovementsNavigationModelBean movementsNavigationModelBean;

public MovementsNavigationModelBean getMovementsNavigationModelBean() {
return movementsNavigationModelBean;
}

public void setMovementsNavigationModelBean(MovementsNavigationModelBean movementsNavigationModelBean) {
this.movementsNavigationModelBean = movementsNavigationModelBean;
}

Maybe I misstyped something?

[Juan Gonzalez，修改在8 年前。]

Ok, that CDI part is important enough here.

Please, use this jsf2-cdi-portlet from demos:

https://github.com/liferay/liferay-faces/tree/3.2.x/demos/bridge/jsf2-cdi-portlet

then try to add your custom logic there and post back here with the results. This is important as there are some library versions that should be kept.

I remember there were some known issues with CDI and @ConversationScoped, but try what I've said above first.

[Alfonso Mateos，修改在8 年前。]

Juan, I also added that context param and then I get:

Caused by: javax.faces.FacesException: No se puede definir la propiedad movementsNavigationModelBean para el bean administrado massiveRecruitingBackingBean
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:86) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.21.jar:2.1.21]
at com.liferay.faces.bridge.BridgePhaseActionImpl.execute(BridgePhaseActionImpl.java:81) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
... 183 more
Caused by: com.sun.faces.mgbean.ManagedBeanCreationException: No se puede definir la propiedad movementsNavigationModelBean para el bean administrado massiveRecruitingBackingBean
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:615) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.ManagedBeanBuilder.buildBean(ManagedBeanBuilder.java:133) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:104) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:408) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:268) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:244) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.21.jar:2.1.21]
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.apache.el.parser.AstValue.getTarget(AstValue.java:94) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.apache.el.parser.AstValue.invoke(AstValue.java:239) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.21.jar:2.1.21]
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.21.jar:2.1]
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.21.jar:2.1.21]
at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.21.jar:2.1]
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.21.jar:2.1]
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:927) [jsf-api-2.1.21.jar:2.1]
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.1.21.jar:2.1.21]
... 186 more
Caused by: javax.el.ELException: JBWEB006003: Cannot convert es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean@c7cf442 of type class es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean to class es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:405) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:49) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:34) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at com.sun.faces.el.ELUtils.coerce(ELUtils.java:536) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.BeanBuilder$Expression.evaluate(BeanBuilder.java:592) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:606) [jsf-impl-2.1.21.jar:2.1.21]
... 207 more

We started with that example you mention a year ago and now our portlets are fully supporting CDI, the problem arised when we used that @SessionScoped bean

[Juan Gonzalez，修改在8 年前。]

I don't quite understand why do you want your portlets to behave the same after portlet deploying while having some session state on it.

Probably the best you could do is undeploy your previous portlet (by removing webapps/<YOUR_PORTLET> and then deploy your new one, so we ensure no session state or other classloading issues shows up.

[Alfonso Mateos，修改在8 年前。]

Well, the reason is that if I've got users using my system and then I deploy a new version of my portlet the end user will see a weird error (view expired, cannot cast whatever) that I don't know how to avoid.... And I don't understand why, I understand that a @SessionScoped bean will last as long as my user session is alive, isn't it? On the other hand that SessionBean is defined inside my war...

Maybe an "elegant" way to deal with the user would do it, if the underlying reason cannot be solved...

By the way, I already undeploy my portlet right BEFORE deploying it...

[Juan Gonzalez，修改在8 年前。]

Alfonso Mateos:

And I don't understand why, I understand that a @SessionScoped bean will last as long as my user session is alive, isn't it?

That's true but when redeploying a new @SessionScoped bean that can lead to unexpected issues, even if the bean state isn't changed. If you want high availability there are some ways for achieving that (cluster with some planned node restarts etc).

Additionally, you should be aware that many libraries aren't ready (and it's not mandatory) for redeployments, and this can cause many classloading issues, like the one you posted before with CDI.

[Alfonso Mateos，修改在8 年前。]

Juan, can you:

- Tell me an explanation on why these errors arise when I use @SessionScoped beans, but not with other scopes.
- If there's some way to avoid that this message is shown to the user (i.e. to force the user to sign in again in case that a redeploy is being performed, or forcing some session expiration if a @SessionBean is called from a portlet...)

I also played with:
<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/views/menu.xhtml</param-value>
</context-param>

But it did not seem to solve it, and with
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>

This avoided the error but then my primefaces controls didn't work fine (incorrect date format), and on top of that I read that this can impact performance.

I keep waiting for your advise :-)
Thanks a lot!

[Juan Gonzalez，修改在8 年前。]

Hi Alfonso,

at this point I need a test portlet to reproduce the issue and have more context on your problem, as seems there are multiple variables to take into account.

Can you create a simple one with some steps? Then I will try to provide some other way to achieve what you want, if possible.

Thanks!

[Alfonso Mateos，修改在8 年前。]

Hi Juan,

Here is the sample code, with the same versions of dependencies I'm using, I'm using Liferay 6.2. In order to reproduce the problem:

1.- Build and deploy the project called "portlets" (clean package install liferay:deploy)
2.- SignOut + Sign In in liferay (just in case)
3.- Create a private page for your site named "home" (it can be another name). My final url is http://localhost:18080/es/group/guest/home
4.- Add the portlet "Menú" from the category "Epsilon PoC".
5.- Test that the portlet works fine: just click the only button you'll see "test sessionscoped" and then you should see:
El valor de ProcessInstance guardado en session es (se espera 3333):
3333
6.- Rebuild and redeploy the portlet again.
7.- Navigate back to http://localhost:18080/es/group/guest/home, and reload the page. Don't sign out and sign in after redeploying.
8.- Click the button "test sessionscoped". You'll see that an internal error has occurred, and if you take a look into the log you'll find something like this:
09:57:34,334 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/epsilon-liferay-portlet].[epsilonmenupoc Servlet]] (http-/0.0.0.0:18080-2) JBWEB000236: Servlet.service() for servlet epsilonmenupoc Servlet threw exception: javax.portlet.faces.BridgeException: javax.portlet.faces.BridgeException: javax.faces.FacesException: No se puede definir la propiedad movementsNavigationModelBean para el bean administrado massiveRecruitingBackingBean
...
...
Caused by: javax.el.ELException: JBWEB006003: Cannot convert es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean@7bd34b76 of type class es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean to class es.gc.epsilon.core.liferay.navigation.MovementsNavigationModelBean
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:405) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:49) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:34) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
at com.sun.faces.el.ELUtils.coerce(ELUtils.java:536) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.BeanBuilder$Expression.evaluate(BeanBuilder.java:592) [jsf-impl-2.1.21.jar:2.1.21]
at com.sun.faces.mgbean.ManagedBeanBuilder$BakedBeanProperty.set(ManagedBeanBuilder.java:606) [jsf-impl-2.1.21.jar:2.1.21]
... 199 more
9.- Sign out + sign in now
10.- Go back to http://localhost:18080/es/group/guest/home again
11.- Try to click the button "test sessionscoped" and you'll see it working fine again.

You will find a few classes related with IPC but they aren't in use now in this sample, the only classes that are really being used are MassiveRecruitingBackingBean and MovementsNavigationModelBean. The rest of them are just to show that we use IPC in our project, just in case can have implications in the solutions that you may find in order to "hide" this error to the end user or to find a graceful error handling.

[Juan Gonzalez，修改在8 年前。]

Hi Alfonso,

I still can't deploy your test portlet but after a brief look I guess I know what the problem is. Can you change:

#{massiveRecruitingBackingBean.movementsNavigationModelBean.processInstanceId}

to

#{movementsNavigationModelBean.processInstanceId}

in menuSession.xhtml

and retest?

Thanks.

[Juan Gonzalez，修改在8 年前。]

BTW seems that your @ViewScoped bean:

MassiveRecruitingBackingBean

should have other stateless scope, such as @RequestScoped, as you aren't using any of its state anywhere, and the only one which is used is already a stateful @SessionScoped bean reference.

This kind of approaches can cause weird issues, and usually isn't the right one.

[Alfonso Mateos，修改在8 年前。]

Hi Juan,

I made those two modifications:

Annotating MassiveRecruitingBackingBean with @RequestScoped
<h:outputLabel value="#{movementsNavigationModelBean.processInstanceId}"/> inside menuSession.xhtml

But I still get the same behavior.
Which problem did you find when trying to deploy my example? Maybe I could simplify the code even more....
We'd like to be able to deliver an elegant behavior to our end users, even when redeploying...

About scopes, we usually set BackingBean and ModelBean as @ViewScoped, from your comments I understand that BackingBean should better be @RequestScoped but ModelBean should be @RequestScoped, am I right?

If so, our intention is to be able to read our @SessionNavigationScope either from our BackingBean or our ModelBean, but in the end the goal is to have our @SessionScoped bean properties values into our ModelBean and then render them into our view.

Thanks a lot for your dedication and interest in this problem :-)

[Juan Gonzalez，修改在8 年前。]

Alfonso Mateos:

I made those two modifications:

Annotating MassiveRecruitingBackingBean with @RequestScoped
<h:outputLabel value="#{movementsNavigationModelBean.processInstanceId}"/> inside menuSession.xhtml

But I still get the same behavior.

Do you mean that the same stacktrace shows up, or is another one? Can you paste here the new error?

Alfonso Mateos:

About scopes, we usually set BackingBean and ModelBean as @ViewScoped, from your comments I understand that BackingBean should better be @RequestScoped but ModelBean should be @RequestScoped, am I right?

If so, our intention is to be able to read our @SessionNavigationScope either from our BackingBean or our ModelBean, but in the end the goal is to have our @SessionScoped bean properties values into our ModelBean and then render them into our view.

Backing beans usually gets some temporary "flag" information to navigate to one place or another or execute some logic. For this purpose @RequestScoped is enough.

Model beans are often used for encapsulating some form into a DTO. You can use @RequestScoped here too unless you have some AJAX behaviour together with some "rendered" logic, in this case is better to use @ViewScoped so it works properly.

As a general rule, @ViewScoped should be used in just few cases and always trying to move as much state from those @ViewScoped beans to @RequestScoped if possible, as this information will reside in session (or in client markup depending in some web.xml) and can cause JVM heap issues in future.

Alfonso Mateos:

Thanks a lot for your dedication and interest in this problem :-)

No problem, hopefully we can fix this.

[Juan Gonzalez，修改在8 年前。]

BTW other approach would be changing:

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>

but this will lead to increase the html size, depending on number of components in your views and what do you store there (@ViewScoped).