title: Wildfly 8 SEAM2 redirect - javax.faces.context.PartialViewContextFactory
body: <p>I'm migrating an application running on legacy AS (with plenty of legacy stuff inside). The starting state was Java 1.7, JBoss 5.1GA, Hibernate 3, SEAM 2.2.2, jBPM 3.9 and some legacy richfaces.</p>
  
  <p>I managed to deploy it on Java 1.8, Wildfly 8.2 with Hibernate 4.3.7, SEAM 2.3.1 and RichFaces 4.5.6. Since SEAM 2.3 is capable of JSF2 I also upgraded JSF to 2.2 (Mojarra 2.2.8 implementation which is shipped wich Wildfly). Because of using SEAM I had to drop CDI (WELD) from the application server (commented WELD out in the standalone-full.xml). Also did a rewrite on jBPM to make it work with new Hibernate.</p>
  
  <p>The app seems to be deploying correctly, everything catches up fine (no errors). When I access the web interface, the login page loads just fine. I enter my login info and then - after successful login - there comes a redirect which is called from the depths of the app through a facade like this:</p>
  
  <pre><code>import org.jboss.seam.faces.Redirect;
  class C {
      public static void showPage(String page) {
          Redirect redirect = Redirect.instance();
          redirect.setViewId(page);       
          redirect.execute();
      }
  }
  </code></pre>
  
  <p>Called this way, the exception is thrown and webpage processing stops. The exception:</p>
  
  <pre><code>SEVERE [javax.faces] (default task-8) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
  SEVERE [javax.faces] (default task-8) Application was not properly initialized at startup, could not find Factory: javax.faces.context.PartialViewContextFactory. Attempting to find backup.
  ...
  Caused by: org.jboss.seam.faces.RedirectException: Could not find backup for factory javax.faces.context.PartialViewContextFactory. 
      at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:237) [jboss-seam.jar:2.3.1.Final]
      at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:190) [jboss-seam.jar:2.3.1.Final]
      at org.jboss.seam.faces.Redirect.execute(Redirect.java:154) [jboss-seam.jar:2.3.1.Final]
  </code></pre>
  
  <p><strong>However there are other redirects - all specified explicitly in pages.xml - which are working fine.</strong></p>
  
  <p>There are not any conflicting libraries (like widespread MyFaces vs. Mojarra problem), there is only Mojarra. Also ruled out those bugs:</p>
  
  <p><a href="https://issues.jboss.org/browse/WFLY-2594" rel="nofollow noreferrer">https://issues.jboss.org/browse/WFLY-2594</a></p>
  
  <p><a href="https://java.net/jira/browse/JAVASERVERFACES-3189" rel="nofollow noreferrer">https://java.net/jira/browse/JAVASERVERFACES-3189</a></p>
  
  <p>Does anyone know how to solve this? Please note that throwing out SEAM is unfortunately <strong>not</strong> an option here.</p>
  
  <p><strong>I will post more details (configuration, more info, ...) on request.</strong></p>
  
  <p><strong>UPDATE:</strong>
  I debugged a bit more - adding some logging directly into SEAM's FacesManager. The logging looks like this:</p>
  
  <pre><code>private void redirect(String viewId, FacesContext context, String url)
     {
        url = Pages.instance().encodeScheme(viewId, context, url);
        if ( log.isDebugEnabled() )
        {
           log.debug("redirecting to: " + url);
        }
        ExternalContext externalContext = context.getExternalContext();
        controllingRedirect = true;
        try
        {  
           log.debug("Trying to get context...");
           log.debug("Contexts.getEventContext(): "+Contexts.getEventContext());
           Contexts.getEventContext().set(REDIRECT_FROM_MANAGER, "");
           log.debug("REDIRECT_FROM_MANAGER set");
           log.debug("externalContext: "+externalContext);
           externalContext.redirect( externalContext.encodeActionURL(url) );
        }
        catch (IOException ioe)
        {
           throw new RedirectException(ioe);
        }
        catch (IllegalStateException ise)
        {
            log.debug("Caught illegal state exception.");
           throw new RedirectException(ise.getMessage());
        }
        finally
        {
           Contexts.getEventContext().remove(REDIRECT_FROM_MANAGER);
           controllingRedirect = false;
        }
        context.responseComplete();
     }
  </code></pre>
  
  <p>Logging output just before the exception occurs:</p>
  
  <pre><code>DEBUG [org.jboss.seam.faces.FacesManager] (default task-5) redirecting to: /idm/user/personal/personal.seam?cid=2
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-5) Trying to get context...
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-5) Contexts.getEventContext(): BasicContext(EVENT)
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-5) REDIRECT_FROM_MANAGER set
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-5) externalContext: org.richfaces.context.SkinningExternalContextFactory$ExternalContextWrapperImpl@1dcafb6
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-5) Caught illegal state exception.
  </code></pre>
  
  <p><strong>UPDATE 2:</strong></p>
  
  <p>So, I was fiddling with debug messages in SEAM and (so far) discovered this:</p>
  
  <pre><code>DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) viewId: /adminOrUser/home.xhtml
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) parameters: {}
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) includeConversationId: true
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) includePageParams: true
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) FacesContext.getCurrentInstance: com.sun.faces.context.FacesContextImpl@67667a
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) context.getApplication: com.sun.faces.application.ApplicationImpl@134d311
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) context.getApplication.getViewHandler: org.jboss.as.jsf.injection.weld.WildFlyConversationAwareViewHandler@151c033
  DEBUG [org.jboss.seam.faces.FacesManager] (default task-14) context.getApplication.getViewHandler.getRedirectURL: /idm/adminOrUser/home.seam
  </code></pre>
  
  <p>The interesting part is <code>org.jboss.as.jsf.injection.weld.WildFlyConversationAwareViewHandler</code> which somehow bugs me. Why is there a class which <strong>could</strong> belong to WELD even when I disabled it? I didn't have a chance to investigate further but my theory is that I somehow got WELD into the deployment indirectly and weld thing then cause problems (conflicts?) because app should rely on SEAM.</p>
  
  <p><strong>UPDATE 3:</strong></p>
  
  <p>The notion of WELD-related issue is probably correct. As JSF implementation Wildfly uses Mojarra(2.2.8) integrated into the AS as <code>jsf-impl-2.2.8-jbossorg-1.jar</code>. Looking into the <code>modules/system/layers/base/com/sun/jsf-impl/main/module.xml</code> in the AS there are WELD dependencies:</p>
  
  <pre><code>&lt;dependencies&gt;
      ...
      &lt;module name="org.jboss.weld.core"/&gt;
      &lt;module name="org.jboss.weld.spi"/&gt;
  &lt;/dependencies&gt;
  </code></pre>
  
  <p>So either WELD still gets into the deployment as the dependency or the JSF implementation depends on something which is currently turned off.</p>
  
  <p>When I turn the weld on I get following error:</p>
  
  <pre><code>ERROR [org.jboss.seam.exception.Exceptions] (default task-4) handled and logged exception: org.jboss.weld.context.NonexistentConversationException: WELD-000321: No conversation found to restore for id 2
      at org.jboss.weld.context.AbstractConversationContext.initialize(AbstractConversationContext.java:260) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
      at org.jboss.weld.context.http.LazyHttpConversationContextImpl.initialize(LazyHttpConversationContextImpl.java:68) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
      at org.jboss.weld.context.http.LazyHttpConversationContextImpl.checkContextInitialized(LazyHttpConversationContextImpl.java:96) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
      at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:460) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
      at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:111) [weld-core-jsf-2.2.6.Final.jar:2014-10-03 10:05]
      at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:189) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
      at com.sun.faces.application.view.MultiViewHandler.getRedirectURL(MultiViewHandler.java:468) [jsf-impl-2.2.8-jbossorg-1.jar:]
      at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:250) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
      at org.jboss.seam.jsf.SeamViewHandler.getRedirectURL(SeamViewHandler.java:133) [jboss-seam.jar:2.3.1.Final]
      at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:250) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
      at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:250) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
      at org.jboss.weld.jsf.ConversationAwareViewHandler.getRedirectURL(ConversationAwareViewHandler.java:142) [weld-core-jsf-2.2.6.Final.jar:2014-10-03 10:05]
      at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:250) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
      at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:182) [jboss-seam.jar:2.3.1.Final]
  </code></pre>
  
  <p>Which means the conversation with id=2 is not found in WELD-managed context. This is no wonder because cid is generated by SEAM and WELD does not know about it at all.</p>
  
  <p>There is a short doc about making JSF work with WELD:
  <a href="http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html#_jsf" rel="nofollow noreferrer">http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html#_jsf</a></p>
  
  <p>Second possibility is to leave WELD turned off and change the JSF implementation so the <code>jsf-impl-2.2.8-jbossorg-1.jar</code> will not be used:
  <a href="https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly" rel="nofollow noreferrer">https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly</a> <strong>(Update: this does not seem to be working.)</strong></p>
  
  <p>Also interesting/related reading to the topic can be found here: <a href="https://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-final-weld-core-jsf-is-still-referencing-jsf-2-2-api">JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API</a></p>