java.lang.IllegalArgumentException: javax.faces.lifecycle.ClientWindowFactory

10.5k views Asked by At

We've been running a web app on a development server and recently somebody built a production server for us (with supposedly) the exact same tomcat config including the JSF libraries in the /lib directory. When I try to deploy my app the new server is throwing a rather confusing error message that I'd love some help understanding.

catalina.out

Both Production and Devel logs look similar up to this point:

24-Jun-2015 13:16:47.880 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive /opt/fleetforecaster/ff-tomcat/webapps/ROOT.war
24-Jun-2015 13:16:47.903 WARNING [localhost-startStop-1] org.apache.catalina.startup.SetContextPropertiesRule.begin [SetContextPropertiesRule]{Context} Setting property 'antiJARLocking' to 'true' did not find a matching property.
24-Jun-2015 13:16:47.911 WARNING [localhost-startStop-1] org.apache.tomcat.util.digester.SetPropertiesRule.begin [SetPropertiesRule]{Context/Realm} Setting property 'debug' to '99' did not find a matching property.
24-Jun-2015 13:16:52.059 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
24-Jun-2015 13:16:52.180 INFO [localhost-startStop-1] null.null Initializing Mojarra 2.2.5 ( 20140108-1427 https://svn.java.net/svn/mojarra~svn/tags/2.2.5@12761) for context ''
24-Jun-2015 13:16:52.401 INFO [localhost-startStop-1] null.null JSF1048: PostConstruct/PreDestroy annotations present.  ManagedBeans methods marked with these annotations will have said annotations processed.
24-Jun-2015 13:16:52.429 SEVERE [localhost-startStop-1] null.null Unknow type constant pool 18 at position 20
24-Jun-2015 13:16:52.430 SEVERE [localhost-startStop-1] null.null Unknow type constant pool 0 at position 21
24-Jun-2015 13:16:52.431 SEVERE [localhost-startStop-1] null.null Unknow type constant pool 0 at position 22
24-Jun-2015 13:16:52.435 SEVERE [localhost-startStop-1] null.null Unknow type constant pool 18 at position 63
24-Jun-2015 13:16:52.436 SEVERE [localhost-startStop-1] null.null Unknow type constant pool 0 at position 64
24-Jun-2015 13:16:52.437 SEVERE [localhost-startStop-1] null.null Unknow type constant pool 0 at position 65

At which point the prod server starts throwing errors:

24-Jun-2015 13:16:52.606 SEVERE [localhost-startStop-1] null.null Critical error during deployment:
 com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! javax.faces.lifecycle.ClientWindowFactory
    at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:449)
    at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5167)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
    at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
    at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1768)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: javax.faces.lifecycle.ClientWindowFactory
    at javax.faces.FactoryFinder.validateFactoryName(FactoryFinder.java:674)
    at javax.faces.FactoryFinder.setFactory(FactoryFinder.java:368)
    at com.sun.faces.config.processor.FactoryConfigProcessor.setFactory(FactoryConfigProcessor.java:317)
    at com.sun.faces.config.processor.FactoryConfigProcessor.processFactories(FactoryConfigProcessor.java:274)
    at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:216)
    at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:435)
    ... 14 more

Followed by a second error block:

24-Jun-2015 13:16:52.609 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file
24-Jun-2015 13:16:52.621 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [] startup failed due to previous errors
24-Jun-2015 13:16:52.628 SEVERE [localhost-startStop-1] null.null Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory. Attempting to find backup.
24-Jun-2015 13:16:52.628 SEVERE [localhost-startStop-1] null.null Unexpected exception when attempting to tear down the Mojarra runtime
 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 com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:142)
    at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:310)
    at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4774)
    at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5390)
    at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:160)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
    at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
    at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1768)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Both servers (as far as I can tell) are configured the same - they have 2 additional libs in the /lib directory for JSF and JSTL.

Any idea what these error messages mean? I must assume its something related to the tomcat install as the exact same war runs fine on one sever but not the other.

Also there is a line that says:

    24-Jun-2015 13:16:52.609 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file

Where exactly do i find the "appropriate container log file"

Both servers - tomcat/lib

jsf-api-2.1.7.jar jsf-impl-2.1.7.jar

Both servers - WEB-INF/lib

atmosphere-runtime-2.3.0.jar
commons-codec-1.5.jar
commons-fileupload-1.3.1.jar
commons-io-2.2.jar
commons-lang-2.6.jar
commons-logging-1.2.jar
dom4j-1.6.1.jar
javaee-web-api-7.0.jar
javax.faces-2.2.5.jar
javax.inject-1.jar
javax.servlet-api-3.0.1.jar
joda-time-2.3.jar
jsf-api-2.1.13.jar
jsf-impl-2.1.13.jar
jstl-1.2.jar
mysql-connector-java-5.1.30.jar
poi-3.10-FINAL.jar
poi-ooxml-3.9.jar
poi-ooxml-schemas-3.9.jar
primefaces-5.1.jar
slf4j-api-1.7.7.jar
stax-api-1.0.1.jar
trove4j-3.0.3.jar
xml-apis-1.0.b2.jar
xmlbeans-2.3.0.jar
3

There are 3 answers

5
BalusC On BEST ANSWER

The webapp's runtime classpath is a mess.

Get rid of those JARs in /WEB-INF/lib

  • javaee-web-api-7.0.jar
  • javax.faces-2.2.5.jar
  • javax.servlet-api-3.0.1.jar

The first one is intented to be used to compile a WAR/EAR targeting a Java EE 7 container. It isn't intented to be installed along a WAR targeting a barebones JSP/Servlet container like Tomcat. It would get confused and think that it's actually a Java EE 7 container (oh joy).

The second one is Mojarra 2.2.5 (API and impl bundled in single-JAR flavor) and the cause of the initial trouble you're seeing. You're basically loading a JSF 2.2 implementation against a JSF 2.1 API already earlier loaded via Tomcat's /lib. The javax.faces.lifecycle.ClientWindowFactory is new since JSF 2.2 (see also @since in javadoc) and not recognized by JSF 2.1 API.

The third one is supposed to be already provided by Tomcat itself. Note that Java EE 7 JAR also contains JSF 2.2 and Servlet 3.1 APIs. So that's after all actually a triple conflict for JSF and Servlet APIs (one API from Tomcat's /lib, one API from WAR's /WEB-INF/lib, and one API from Java EE 7 JAR bundle; that's not good).

Regardless, I recommend to clean up Tomcat's /lib as well and keep it as default. Just stick to JARs in WAR's /WEB-INF/lib. And, if you actually intend to build a JSF 2.2 targeted web application (first doublecheck version in faces-config.xml if it matches), then keep in the javax.faces-2.2.5.jar and get rid of those jsf-api-2.1.13.jar and jsf-impl-2.1.13.jar files.

0
fra On

Very weird behavior on my side, I had the exact same issue with wildfly 14.

It suddenly started to work again, when i renamed one of my beans called as a validator in a httpInputText. I renamed it from "my_Bean" to "myBean" removing the underscore "_".

I do not have a beans.xml under web-inf. And i did not used maven dependency for CDI. Doing this trick worked. Hope it will fix some of the issues for other people.

0
Renato Camargos On

I had this same error but using WildFly. Don't know why but, I couldn't see the CDI facet option to add to my project. So in order to suppress this error message I had to create the beans.xml manually inside WEB-INF folder.

That was the content:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        bean-discovery-mode="all" version="1.1" 
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
        http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"/>

cheers