[ 
https://issues.apache.org/jira/browse/MYFACES-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504324#comment-13504324
 ] 

Leonardo Uribe commented on MYFACES-3656:
-----------------------------------------

I think the behavior described is expected (different to say that the behavior 
described is desired or intentionally done in that way). 

What's happening here is in MyFaces serialization is set to true by default 
(some old lines from JSF 1.0 spec says so, even if RI does not implement it in 
this way). In JSF 2.2 spec, SERIALIZE_STATE_IN_SESSION param will be 
standarized and set to false by default.

Serialization causes that all beans under view scope are in fact "recreated". 
If the param is set to false, the beans are stored into session and on further 
requests are used, looking like everything is ok, but that fact is not true 
because in a cluster configuration the same application will fail.

Only the first time the view scope bean is created, the references from 
managed-property takes effect, but if the bean is serialized/deserialized, the 
references are not restored back, because on the serialization step, even the 
application and session scope beans are serialized too.

This issue is similar to the one described in MYFACES-3581. In this case, a 
view scope bean is annotated with @EJB, but the effect is more or less the 
same. The same issue happens even with session scope beans instead window scope 
beans and when the session is stored in some place. 

How to solve it? I haven't found a decent solution to this issue. One could 
think on just restore the view scope bean and reapply @ManagedProperty 
annotations or entries found in faces-config.xml, but the problem is the view 
scope bean still is storing information that shouldn't be there from start 
(only marking the fields as transient will do the trick, any suggestion?). It 
is possible define an special mode were this hack or some variant is done, but 
it will be only in myfaces and it cannot be enabled by default (or can we? in 
theory RI behave the same as MyFaces but that does not mean we should be bug 
compatible, maybe an SPI interface to make it pluggable and allow CODI 
@ViewAccessScope and other alternatives do the same trick). In theory, it 
should be solved on the bean container level.

The suggested way to deal with this problem is use view scope beans only for 
store info related to the view, and use request scope beans to deal with 
@ManagedProperty stuff. In the request scope you have a reference for the view 
scope and other application/session scope beans. This means you'll have more 
beans and some extra references.

Maybe an extra interface for classes implementing LifecycleProvider2? 
BeanSerializationProvider? suggestions are welcome.
                
> ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
> --------------------------------------------------------------------
>
>                 Key: MYFACES-3656
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3656
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.0.15
>         Environment: WebSphere V8 and Tomcat 2.0.27
>            Reporter: Paul Nicolucci
>         Attachments: ViewScopeProblemMyFaces.war
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> My beans are defined as follows:
>    <managed-bean>
>               <managed-bean-name>appManagerBean</managed-bean-name>
>               
> <managed-bean-class>com.ibm.ws.jsf.beans.AppManagerBean</managed-bean-class>
>               <managed-bean-scope>application</managed-bean-scope>
>       </managed-bean>
>      
>       <managed-bean>
>               <managed-bean-name>emailBean</managed-bean-name>
>               
> <managed-bean-class>com.ibm.ws.jsf.beans.EmailBean</managed-bean-class>
>               <managed-bean-scope>session</managed-bean-scope>
>       </managed-bean>
>     <managed-bean>
>         <managed-bean-name>viewScopedBean</managed-bean-name>
>         
> <managed-bean-class>com.ibm.ws.jsf.beans.ViewScopedManagedBean</managed-bean-class>
>         <managed-bean-scope>view</managed-bean-scope>
>         
>         <managed-property>
>                       <property-name>emailBean</property-name>
>                       <value>#{emailBean}</value>
>               </managed-property>
>               <managed-property>
>                       <property-name>appManagerBean</property-name>
>                       <value>#{appManagerBean}</value>
>               </managed-property>
>           
>     </managed-bean>
> I've provided an application that reproduces this issue.  To reproduce follow 
> these steps:
> 1) install application 
> 2) drive a request into the following URL 
> <host>:<port>/<context-root>/ViewScopeTest1.jsf
> 3) leave the email field empty
> 4) press the submit button.
> 5) you should be taken to the error page
> 6) the following text should appear in the textArea but it does not "Invalid 
> Email: Email can Not be empty"
> The second test "ViewScopeTest2.jsf" is similar it does not contain the 
> binding attribute and just references a value from the ViewScoped bean and 
> the problem can again be reproduced.  
> It seems as though the AppManager errorMessage field is null but it has not 
> been reset.  I would think that the application scoped bean would still be 
> accessible even though the view scoped bean is out of scope.
> If you set the SERIALIZE_STATE_IN_SESSION to false and redeploy the 
> application then everything works as expected, which seems odd to me but if 
> you un-comment this from the web.xml you'll see we get the text on the error 
> page as expected.
> I've been working to debug this issue and can't seem to figure out where the 
> problem is in the MyFaces code.  I tested the same application on WAS and 
> Tomcat to ensure that it was not something specific to a server.  It seems as 
> though this is a implementation issue.
> Any help that folks can provide would be greatly appreciated!!  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to