You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Marco Rinck (JIRA)" <de...@myfaces.apache.org> on 2010/11/30 21:44:20 UTC
[jira] Created: (MYFACES-2985) Viewscoped bean does not get
destroyed when navigating with faces-redirect to a non-jsf-page
Viewscoped bean does not get destroyed when navigating with faces-redirect to a non-jsf-page
--------------------------------------------------------------------------------------------
Key: MYFACES-2985
URL: https://issues.apache.org/jira/browse/MYFACES-2985
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.2
Environment: jdk 1.6.0_22, myfaces 2.0.2, jboss 4.2.3, windows and linux
Reporter: Marco Rinck
I have a jsf page wich is using (only) one viewscoped backing bean. When I want to navigate away from this jsf page to another non-jsf-page (in my case: jsp page) I wanted to use implicit navigation.
So the outcome of the action a commandbutton is "index.jsp". When I click this button I see the jsp page and the viewscoped bean is destroyed (checked with @Predestroy annotation and System.out.println), just fine. Of course, in this case the browser displays still the jsf page in address bar.
So when the outcome is "index.jsp?faces-redirect=true" the browser displays the jsp page and the correct url in address bar. BUT ... the viewscoped bean is NOT destroyed! When clicking a link on the jsp page back to the jsf page, this leads to another instance of the viewscoped bean and so on .. if user is switching back and forth between those 2 pages, I get more and more instances of the viewscoped bean where there should be only one.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2985) Viewscoped bean does not get
destroyed when navigating with faces-redirect to a non-jsf-page
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leonardo Uribe resolved MYFACES-2985.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.3-SNAPSHOT
Assignee: Leonardo Uribe
I tried the example and yes, we are not cleaning the viewMap when there is a redirect. In theory, this is done when FacesContext.setViewRoot is called, but in this case it is not necessary, so we need to force this cleanup. I also tried this one against mojarra 2.0.3 and it works there. Thanks for report this one.
> Viewscoped bean does not get destroyed when navigating with faces-redirect to a non-jsf-page
> --------------------------------------------------------------------------------------------
>
> Key: MYFACES-2985
> URL: https://issues.apache.org/jira/browse/MYFACES-2985
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.2
> Environment: jdk 1.6.0_22, myfaces 2.0.2, jboss 4.2.3, windows and linux
> Reporter: Marco Rinck
> Assignee: Leonardo Uribe
> Fix For: 2.0.3-SNAPSHOT
>
> Attachments: viewscope.zip
>
>
> I have a jsf page wich is using (only) one viewscoped backing bean. When I want to navigate away from this jsf page to another non-jsf-page (in my case: jsp page) I wanted to use implicit navigation.
> If the outcome of the action of a commandbutton is "index.jsp" and I click this button I see the jsp page and the viewscoped bean is destroyed just fine (checked with @Predestroy annotation and System.out.println). Of course, in this case the browser displays still the jsf page in address bar.
> If the outcome of the action is "index.jsp?faces-redirect=true" the browser displays the jsp page and the correct url in address bar. BUT ... the viewscoped bean is NOT destroyed! When clicking a link on the jsp page back to the jsf page, this leads to another instance of the viewscoped bean and so on .. if user is switching back and forth between those 2 pages, I get more and more instances of the viewscoped bean where there should be only one.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.