Answers for "Deploying an existing WAR" The latest answers for the question "Deploying an existing WAR" Answer by Ann Paungam I had received more information about the app and log contents via email. Here are the findings to help others that might encounter this. From the maven pom.xml file, this app had a Tomcat-specific plugin used to tailor the app specifically to Tomcat, such as using a Sun implementation of JSF. I believe as a default, Tomcat does not provide JSF features. In Bluemix, by default JSF 2.0 (using MyFaces) and CDI features are enabled for Liberty. To customize the default features (eg: Sun instead of MyFace), a packaged server containing the customizations can be deployed instead of a WAR (see [][1] ). Specific to this problem, to customize the server package using the Sun implementation of JSF: 1. the Sun JSF libraries should be placed in WEB-INF/lib (currently isn't included in the provided app). More info here 2. jsf-2.0 feature should be disabled in server.xml 3. Because @ManagedBean annotation is used in this app (instead of @Named for CDI), it seems the cdi-1.0 feature needs to be disabled in server.xml as well. CDI being enabled will try to handle the injection while @ManagedBean is a JSF annotation. 4. Note that with the annotations working, the faces-config.xml isn't required to list the managed beans [1]: Thu, 19 Feb 2015 14:10:35 GMT Ann Paungam Answer by Ann Paungam Based on the error message and logging info, it appears that there may be a mismatch with the specified source level and the running JVM level. The logging message indicates that the Web Project/WEB-INF/ibm-web-ext.xmi file sets the JSP to be compiled for Java v5.0. What level of Tomcat and JVM are you using in your local/WTP environment? In the Bluemix environment, the current Java level for the Liberty buildpack is Java v7.0 (the default environment for Java applications without specifying the buildpack -b option). Tue, 27 Jan 2015 14:59:30 GMT Ann Paungam