Reputation: 717
I'm using this :
but when trying to run my application, I got the following exception:
java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1011)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:343)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:159)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getELContext(FacesContextImplBase.java:210)
at javax.faces.component.UIViewRoot.setLocale(UIViewRoot.java:1463)
at org.apache.myfaces.webapp.AbstractFacesInitializer._createFacesContext(AbstractFacesInitializer.java:477)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initStartupFacesContext(AbstractFacesInitializer.java:449)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:113)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4797)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5291)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Any ideas why?
Thanks,
Upvotes: 38
Views: 100159
Reputation: 1405
In my case this exception was caused on webapp shutdown by the presence of com.sun.faces.config.ConfigureListener
in web.xml
, running Mojarra 2.2.x under Tomcat 8.0. As described in this answer, this causes Tomcat to register that listener twice (both automatically and by virtue of the web.xml
entry) and hence, among other things, its contextDestroyed
method is executed twice, the second time producing the described exception (most probably because JSF was already shut down by the first listener registration).
I had no classpath conflict in my case: just one version of Mojarra (2.2.6) and no MyFaces.
Upvotes: 0
Reputation: 2246
In addition to what's already said, I faced this issue when importing a third party project, the reason was that two profiles were defined in the pom.xml, one for My Faces and another for Mojarra. If this is your case, you just need to select one of them with maven -P or in Project properties, Maven section, indicating the profile(s) to be used.
Upvotes: 0
Reputation:
For me {Tomcat 8, JSF 2.2, JRE 8}, the following steps worked:
Download JSTL jars API && IMPL and place it in your Tomcat lib.
Since downloading Majorra directly from eclipse in project facets configuration is recently impossible ; "Zip File is empty Exception", manually download jsf-api.jar and jsf-impl.jar and include them in a new user library added to build path(only once!).
This is my web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" id="WebApp_ID" version="3.1">
<display-name>TestJSF</display-name>
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<context-param>
<description>State saving method: 'client' or 'server' (=default). See JSF Specification 2.5.2</description>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>javax.servlet.jsp.jstl.fmt.localizationContext</param-name>
<param-value>resources.application</param-value>
</context-param>
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
</web-app>
Upvotes: 4
Reputation: 1109432
That may happen if your webapp's runtime classpath is polluted with multiple JSF impls/versions. The org.apache.myfaces
entries in the stack trace tells that you're using MyFaces. This problem thus suggests that you've another JSF implementation like Mojarra in the webapp's runtime classpath which is conflicting with it. It's recognizable by jsf-api.jar
, or jsf-impl.jar
, or javax.faces.jar
. If you remove all of them, then this problem should disappear.
Or, if you actually intented to use Mojarra instead of MyFaces (you did namely not explicitly state the intented JSF impl/version anywhere in your question, but you just generically stated the JSF spec as in "JSF 2.0", so perhaps you actually had no clue what you was all doing), then you should be removing myfaces-*.jar
files from your webapp.
Upvotes: 37
Reputation: 479
Complementing BalusC's answer, I recently got this error when trying to run an independent JAR with a Spring Boot application that has JSF as front-end with Spring-managed beans. Switching the packaging from JAR to WAR solved the problem.
Upvotes: 5