1

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
Community
  • 1
  • 1
Jeef
  • 26,861
  • 21
  • 78
  • 156
  • Exception tells that application attempted to load JSF 2.2 impl against a JSF 2.0/2.1 API. That factory is new since JSF 2.2 and obviously not recognized by a JSF 2.0/2.1 API. What version is that JSF JAR in Tomcat's /lib? Is there a different versioned JSF JAR in WAR's /WEB-INF/lib or very perhaps (but very awkward) JRE's /lib? Those have higher precedence in classloading and that'd explain all the trouble. – BalusC Jun 24 '15 at 18:37
  • Maybe ... its in the JRE lib ... because all are 2.1 – Jeef Jun 24 '15 at 18:47
  • You mentioned that there are 2 additional JARs for JSF and JSTL. You however appear to have 2 whole JARs for JSF alone. This implies you don't exactly know what you're talking about. Are there more JARs in /lib and /WEB-INF/lib? If so, please just list them all. From those in /lib, just list the manually added ones. As to JSF 2.2, look once again at server log. It clearly says it's initilaizing Mojarra 2.2.5. This is definitely not right given those Mojarra 2.1.x JARs (regardless, you'd better get rid of those in server's /lib, and stick to WAR's /WEB-INF/lib just to be on safe side). – BalusC Jun 24 '15 at 18:48
  • I concur that i do not know what i'm talking about. I'll update the post shortly. – Jeef Jun 24 '15 at 18:50
  • Any idea how to track down the JRE libs? (its on linux) – Jeef Jun 24 '15 at 18:55

3 Answers3

3

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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Do i leave the tomcat/lib wars? – Jeef Jun 24 '15 at 19:04
  • You can, but I recommend to keep them default. – BalusC Jun 24 '15 at 19:05
  • Can i do the removal in the pom file? (provided) – Jeef Jun 24 '15 at 19:05
  • If you can't manipulate the target server, then simply mark all libraries already provided by the target server as `provided` in WAR's pom. So, among others those JSF 2.1 API/impl. And, you'd better align out the versions to match those in target server. – BalusC Jun 24 '15 at 19:07
  • I upgraded to 2.2 for everything. Thanks so much you helped me get it working. – Jeef Jun 24 '15 at 20:10
1

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.

fra
  • 83
  • 1
  • 11
0

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