[jboss-jira] [JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps

[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-2594: ---------------------------------- As a workaround for a GlassFish issue, the _com.sun.faces.config.FacesInitializer#onStartup_ method currently has the following code that adds the ConfigureListener to the ServletContext: {code} // The following line is temporary until we can solve an ordering // issue in V3. Right now the JSP container looks for a mapping // of the FacesServlet in the web.xml. If it's not present, then // it assumes that the application isn't a faces application. In this // case the JSP container will not register the ConfigureListener // definition from our TLD nor will it parse cause or JSP TLDs to // be parsed. servletContext.addListener(com.sun.faces.config.ConfigureListener.class); {code} When running with WildFly, this causes the ConfigureListener to erroneously get registered twice when deploying JSF applications that don't contain a mapping of the FacesServlet in their web.xml. The InjectionProvider is set properly in the InitFacesContext the first time ConfigureListener.contextInitialized() is called. However, when ConfigureListener.contextInitialized() is erroneously called a second time, the InjectionProvider won't get set again resulting in the SEVERE messages in the logs when undeploying. I've created a patch that fixes this issue by making the ConfigManager.hasBeenInitialized() checks happen earlier in ConfigureListener.contextInitialized() and ConfigureListener.contextDestroyed(). See https://java.net/jira/browse/JAVASERVERFACES-3189. -- 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