[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] Marek Novotny commented on JBSEAM-4898: --------------------------------------- Please fill the exact version of Seam and JSF. I also welcome test case, which ensures fastest solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] John Gilbert commented on JBSEAM-4898: -------------------------------------- I have attached 2 sample apps. The jsf2 profile builds the app with seam 2.3 and the jsf1 profile builds the app with seam 2.2. Build the jsf2 profile first and then deploy both apps at the same time. I am using AS 5.1. The apps have links to each other so you can switch back and forth. The page and conversation scopes are not working in 2.3. This is a sample of the facelets the retrieve the template and include view id from scoped factories. {code} <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" template="#{pageScopedTemplate}"> <ui:define name="body"> <ui:include src="#{pageScopedInclude}" /> </ui:define> </ui:composition> {code} Also, the ear build is current configured for expanded mode. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] John Gilbert commented on JBSEAM-4898: -------------------------------------- What I have found so far is that with the old facelets jar installed the following method does not find a strategy and just restores the tree. Without the old facelets jar it finds a strategy which re-applies the facelet. {code} com.sun.faces.application.StateManagerImpl{ public UIViewRoot restoreView(FacesContext context, String viewId, String renderKitId) { UIViewRoot result = null; StateManagementStrategy strategy = null; ViewDeclarationLanguage vdl = context.getApplication().getViewHandler(). getViewDeclarationLanguage(context, viewId); if (vdl != null) { strategy = vdl.getStateManagementStrategy(context, viewId); } if (null != strategy) { result = strategy.restoreView(context, viewId, renderKitId); } else { ResponseStateManager rsm = RenderKitUtils.getResponseStateManager(context, renderKitId); Object[] state = (Object[]) rsm.getState(context, viewId); if (state != null && state.length >= 2) { // We need to clone the tree, otherwise we run the risk // of being left in a state where the restored // UIComponent instances are in the session instead // of the TreeNode instances. This is a problem // for servers that persist session data since // UIComponent instances are not serializable. UIViewRoot viewRoot = null; if (state[0] != null) { viewRoot = restoreTree(context, renderKitId, ((Object[]) state[0]).clone()); } if (viewRoot != null && state[1] != null) { viewRoot.processRestoreState(context, state[1]); } result = viewRoot; } } return result; } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] John Gilbert commented on JBSEAM-4898: -------------------------------------- We have figured out a potential solution. This is all related to how Jsf2 changed RestoreView. First it rebuilds the tree from scratch and then visits the tree to restore the state. Since the state isn't restored it can't rebuild the tree. Previously it just restored the tree from the state. There are two pieces to the fix. First we moved the restore of the conversation to beforeRestore. This is similar to the logic in Weld. * SeamPhaseListener {code} /** * Set up the Seam contexts, except for the conversation * context */ protected void beforeRestoreView(FacesContext facesContext) { FacesLifecycle.beginRequest( facesContext.getExternalContext() ); // this is the same place that WELD restores the conversation Map parameters = facesContext.getExternalContext().getRequestParameterMap(); ConversationPropagation.instance().restoreConversationId(parameters); boolean conversationFound = Manager.instance().restoreConversation(); FacesLifecycle.resumeConversation( facesContext.getExternalContext() ); } /** * Restore the page and conversation contexts during a JSF request */ protected void afterRestoreView(FacesContext facesContext) { FacesLifecycle.resumePage(); Map parameters = facesContext.getExternalContext().getRequestParameterMap(); // ConversationPropagation.instance().restoreConversationId(parameters); boolean conversationFound = Manager.instance().restoreConversation(); // FacesLifecycle.resumeConversation( facesContext.getExternalContext() ); postRestorePage(facesContext, parameters, conversationFound); } {code} Second, we made the PageContent lazily initialize. this is similar to how Seam 3 does the ViewScopedContext. * Contexts {code} public static boolean isPageContextActive() { if (pageContext.get() == null) { // lazy initialize the page context during restore view // this is similar to the ViewScopedContext.isActive() in Seam 3 FacesContext facesContext = FacesContext.getCurrentInstance(); if (facesContext != null) { UIViewRoot viewRoot = facesContext.getViewRoot(); if (viewRoot != null) { pageContext.set( new PageContext() ); } } } return pageContext.get() != null; } {code} I will submit a patch next we after we wrap up our sprint to ensure there aren't any additional changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] John Gilbert updated JBSEAM-4898: --------------------------------- Attachment: JBSEAM-4898-patch.txt patch includes test changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] Marek Novotny resolved JBSEAM-4898. ----------------------------------- Assignee: Marek Novotny Fix Version/s: 2.3.0.BETA1 Resolution: Done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] Marek Novotny commented on JBSEAM-4898: --------------------------------------- reverted patch due influence on other parts of Seam -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] Marek Novotny commented on JBSEAM-4898: --------------------------------------- This whole issue is about correct initialization of PageContext and ConversationContext while RestoreView phase is processed. If the context initialization is moved from afterRestoreView to beforeRestoreView, a conversation is not correctly stored especially in case of nested conversation or long running conversation. The postback request is also affected. The whole point is that ViewMap, where are conversation ids stored is not always available in case of beforeRestoreView processing, ViewMap is initialized directly in RESTORE_VIEW. I have tried to use PostConstructViewMapEvent to start initialization of conversation and the contexts, bu this event certainly is not fired in Postback request, where it is recycled from previous UIViewRoot. I saw similar issues in WELD like WELD-157 or WELD-100. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBSEAM-4898?page=com.atlassian.jira.plugi... ] Marek Novotny resolved JBSEAM-4898. ----------------------------------- Resolution: Done Even JSF2 contains a bug, added workaround fixes your issue, I tried your test case on AS 5.1. There are still some issues with JSF2 on AS7, but I will create new issues for that -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira