JSF correct use of jsf-api dependency - maven

Ok, I am a little confused on the differences between jsf-api implementations.
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.2.8</version>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.1</version>
</dependency>
I am not sure what the differences are between these two. I thought they do the same thing and allow the javax.faces imports but now I have confused myself. Can anyone please explain these two differences? Thanks :)

There was somes changes with the groupId of the Maven JSF-API dependency since the first version. For JSF 2.2 (current version as I'm writing this), you should use the following recommended dependency, if you are running in a container supporting JSF:
<dependency>
<groupId>javax.faces</groupId>
<artifactId>javax.faces-api</artifactId>
<version>2.2</version>
<scope>provided</scope>
</dependency>
If your container does not support JSF (like Tomcat), use the following dependency if you want to use Mojarra (the default JSF implementation):
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.2.8</version>
</dependency>
Other recommmendation and information are available on the official page of JSF.

Related

Where can I find JSTL version 1.2.3 or newer?

I am using jstl-1.1.2 jar in my application. Veracode shows high vulnerability for using this tag library. Veracode shows vulnerability for versions until 1.2.3. During my research I could only find version 1.2. Is there a version 1.2.3 for this jar? Or is there anything I can do to remediate this vulnerability?
What are my options? Please suggest.
My Maven dependency looks like:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
</dependency>
Maven repository shows v.1.2 is available (Jun 23, 2011):
<!-- https://mvnrepository.com/artifact/javax.servlet/jstl -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
Also, JSTL was moved to another place, v.1.2 (May 14, 2015)
<!-- https://mvnrepository.com/artifact/javax.servlet.jsp.jstl/jstl -->
<dependency>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
Similarly, Maven repository shows v.1.2.5 for taglibs is available:
<!-- https://mvnrepository.com/artifact/org.apache.taglibs/taglibs-standard-impl -->
<dependency>
<groupId>org.apache.taglibs</groupId>
<artifactId>taglibs-standard-impl</artifactId>
<version>1.2.5</version>
</dependency>
So, only the taglibs can be updated to v.1.2.5 to mitigate this vulnerability:
Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. Apache Standard Taglibs before 1.2.3 allows remote attackers to execute arbitrary code or conduct external XML entity (XXE) attacks via a crafted XSLT extension in a <x:parse> or <x:transform> JSTL XML tag.

activemq-all forces me to use log4j slf4j implementation

I would like to use the logback slf4j implementation in my application, but activemq-all is spoiling the classpath by including the log4j implementation classes. I'm not the only one facing that problem, as witnessed by for instance multiple SLF4J bindings Error with activemq-all-5.6.0.jar. According to that post I have to replace activemq-all by
org.apache.activemq:activemq-camel
org.apache.activemq:activemq-core
org.apache.activemq:activemq-console
org.apache.activemq:activemq-jaas
org.apache.activemq:activemq-optional
org.apache.activemq:kahadb
org.apache.geronimo.specs:geronimo-jms_1.1_spec
org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec
org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec
org.apache.geronimo.specs:geronimo-annotation_1.0_spec.
The problem is that I don't have the complete maven dependencies (group id, artifact id, version) for these artifacts. Can someone provide me with a ready-to-use replacement for
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-all</artifactId>
<version>5.9.0</version>
</dependency>
You can use active mq core library. Please note that active mq is backward compatible for client.
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-core</artifactId>
<version>5.4.3</version>
<exclusions>
<exclusion>
<artifactId>org.slf4j</artifactId>
<groupId>slf4j-log4j12</groupId>
</exclusion>
<exclusion>
<artifactId>log4j</artifactId>
<groupId>log4j</groupId>
</exclusion>
</exclusions>
</dependency>
In a nutshell, you have already listed group id/artifact id separated by a colon for the artifact you found. Please note that these satisfy some usecase with ActiveMQ 5.6. For instance activemq-core is not really valid any more - use activemq-client and activemq-broker instead.
Currently, these artifact are bundled in activemq-all. But you may want to check out the pom.xml for your version of choice (this list might change over time). You probably won't need all of them unless you are about to embedd a broker with all transports, plugins and configurations within your applications.
<artifactSet>
<includes>
<include>${project.groupId}:activemq-client</include>
<include>${project.groupId}:activemq-openwire-legacy</include>
<include>${project.groupId}:activemq-camel</include>
<include>${project.groupId}:activemq-jaas</include>
<include>${project.groupId}:activemq-broker</include>
<include>${project.groupId}:activemq-console</include>
<include>${project.groupId}:activemq-shiro</include>
<include>${project.groupId}:activemq-spring</include>
<include>${project.groupId}:activemq-pool</include>
<include>${project.groupId}:activemq-jms-pool</include>
<include>${project.groupId}:activemq-amqp</include>
<include>${project.groupId}:activemq-http</include>
<include>${project.groupId}:activemq-mqtt</include>
<include>${project.groupId}:activemq-stomp</include>
<include>${project.groupId}:activemq-kahadb-store</include>
<include>${project.groupId}:activemq-leveldb-store</include>
<include>${project.groupId}:activemq-jdbc-store</include>
<include>org.apache.activemq.protobuf:activemq-protobuf</include>
<include>org.fusesource.hawtbuf:hawtbuf</include>
<include>org.jasypt:jasypt</include>
<include>org.apache.geronimo.specs:geronimo-jms_1.1_spec</include>
<include>org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec</include>
<include>org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec</include>
<include>org.apache.geronimo.specs:geronimo-annotation_1.0_spec</include>
<include>org.slf4j:slf4j-api</include>
<include>org.slf4j:slf4j-log4j12</include>
<include>log4j:log4j</include>
</includes>
</artifactSet>
Ok, the version number for org.apache.activemq should simply be the release you want to use. For the geronimo specs, this is not so obvious.
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jms_1.1_spec</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-j2ee-management_1.1_spec</artifactId>
<version>1.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-annotation_1.0_spec</artifactId>
<version>1.1.1</version>
</dependency>
I was also facing this same issue with activemq-all API and I replaced this dependency with this below dependency and it worked for me.
<!-- https://mvnrepository.com/artifact/org.apache.activemq/activemq-spring -->
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-spring</artifactId>
<version>5.14.3</version>
</dependency>
Hope this can help others.

Standard way of adding JSLT 1.2.1 in a Maven Project?

What is the standard pom for adding the 1.2.1 JSTL taglib in a maven project. Any recommendations as to when/if can this be scoped as provided ? Any server peculiarities (interested in Jboss 7, Glassfish 4 and/or Tomcat 7)
EDIT: Added:
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>javax.servlet.jsp.jstl</artifactId>
<version>1.2.1</version>
<scope>provided</scope>
</dependency>
This adds:
Notice it transitively adds the 1.2 api.
I am using provided as I am using Jboss which should provide it: Basic question complicated solution - Tomcat to JBoss. Still this is the 1.2 api apparently
$ find . -name *jstl*.jar
./modules/javax/servlet/jstl/api/main/jboss-jstl-api_1.2_spec-1.0.2.Final.jar
(contains implementation also). So would the correct way be to add the jstl jars to the pom (not in provided scope) and mark the servlet-api (I'm on 3 anyway) as provided somehow ?
Ended up using :
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
<!-- Add the jstl-api dependency explicitly - otherwise jstl-api 1.2 is added -->
<dependency>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>javax.servlet.jsp.jstl-api</artifactId>
<version>1.2.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>javax.servlet.jsp.jstl</artifactId>
<version>1.2.1</version>
<exclusions>
<!-- jstl-api was adding selvlet-api 2.5 and jsp-api-->
<exclusion>
<artifactId>jstl-api</artifactId>
<groupId>javax.servlet.jsp.jstl</groupId>
</exclusion>
</exclusions>
</dependency>
Not sure if I should add the jstl-api dependency - please comment (I would accept a more authoritative answer actually). Result:
See:
Autocomplete with JSP, JSTL 1.2.1 and Servlet 3.0 in Tomcat 7 with Eclipse Kepler
Fix maven JSTL 1.2.1 dependency so maven-war-plugin doesn't package JARs that offend Tomcat 7
JBoss 7.1 - Migration to JSF 2.2 - includes how to upgrate your jstl to 1.2.1
For 1.2:
Running JSTL 1.2 on Tomcat 7 using Maven

multiple SLF4J bindings Error with activemq-all-5.6.0.jar

When I upgrade to activemq-all-5.6.0
I get this error during server startup
SLF4J: Class path contains multiple SLF4J bindings
I don't have this issue when using activemq-all-5.5.1
On checking I do find that there StaticLoggerBinder.class in both activemq-all-5.6.0.jar and slf4j-log4j12-1.5.10.jar which is causing the issue
Please do help in debugging this issue
My pom.xml is as follows
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.10</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.5.10</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.10</version>
<scope>runtime</scope>
</dependency>
The active mq dependency is like this
Old Version 5.5.1 (This works)
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-all</artifactId>
<version>5.5.1</version>
</dependency>
New Version 5.6.0 (This gives the error)
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-all</artifactId>
<version>5.6.0</version>
</dependency>
Thanks in advance.
The ActiveMQ guys use the Maven Shade Plugin to create the activemq-all "ueber" jar. Somewhere between version 5.5.1 and 5.6.0 they added the org.slf4j:slf4j-log4j12 dependency - hence your problem.
Unfortunately because they used the shade plugin you can not use exclusions in your activemq-all dependency definition in your POM.
Instead you will need to completely replace the activemq-all dependency with all the required individual dependencies (except of course the org.sl4j-log4j12 one).
The following page details all the required dependencies:
http://activemq.apache.org/initial-configuration.html#InitialConfiguration-RequiredJARs
Alternatively the following is the list of all dependencies (required and optional) included in the activemq-all jar (taken from the configuration of the shade plugin in the activemq-all pom):
org.apache.activemq:activemq-camel
org.apache.activemq:activemq-core
org.apache.activemq:activemq-console
org.apache.activemq:activemq-jaas
org.apache.activemq:activemq-optional
org.apache.activemq:kahadb
org.apache.geronimo.specs:geronimo-jms_1.1_spec
org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec
org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec
org.apache.geronimo.specs:geronimo-annotation_1.0_spec
org.slf4j:slf4j-api
org.slf4j:slf4j-log4j12
log4j:log4j
Hope that helps.
I had the same problem while using Spring. What helped me was replacing the dependency of activemq-all with:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-spring</artifactId>
<version>5.14.3</version>
</dependency>
Hope this will help anyone...

How to properly install and configure JSF libraries via Maven?

I'm trying to deploy a JSF based application to Tomcat 6. The way my build system is setup, the WAR itself doesn't have any libraries in it, because this server is serving a total of 43 apps. Instead, the libraries are copied into a shared library folder and shared among the apps. When I deploy, I get this error
SEVERE: Error deploying configuration descriptor SSOAdmin.xml
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/faces/webapp/FacesServlet
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1667)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:108)
at org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:58)
at org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1078)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4611)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:675)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:601)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1315)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1061)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
at org.apache.catalina.core.StandardService.start(StandardService.java:525)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Now in my research, I see that this is supposed to be solved by downloading the JSF source code and compiling it myself. That is a horrible solution in my case. That will cause huge problems on my team with the various configurations we have to contend with. Is there another fix for this?
Here is my pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.nms.sso</groupId>
<artifactId>SSOAdmin</artifactId>
<version>09142011-BETA</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<!-- <dependency> -->
<!-- <groupId>com.sun.faces</groupId> -->
<!-- <artifactId>jsf-api</artifactId> -->
<!-- <scope>${myExeScope}</scope> -->
<!-- </dependency> -->
<!-- <dependency> -->
<!-- <groupId>com.sun.faces</groupId> -->
<!-- <artifactId>jsf-impl</artifactId> -->
<!-- <scope>${myExeScope}</scope> -->
<!-- </dependency> -->
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.faces</groupId>
<artifactId>javax.faces-api</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>net.sf.jt400</groupId>
<artifactId>jt400</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>nmsc</groupId>
<artifactId>nmsc_api</artifactId>
<version>09142011-BETA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-ace</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.icefaces</groupId>
<artifactId>icefaces-compat</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.javassist</groupId>
<artifactId>javassist</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.jibx</groupId>
<artifactId>jibx-extras</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.jibx</groupId>
<artifactId>jibx-run</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<scope>${myExeScope}</scope>
</dependency>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<scope>${myExeScope}</scope>
</dependency>
</dependencies>
<parent>
<groupId>nmsc</groupId>
<artifactId>nmsc_lib</artifactId>
<version>0.0.1-SNAPSHOT</version>
<relativePath>../libs</relativePath>
</parent>
<build>
<finalName>SSOAdmin</finalName>
</build>
<name>SSOAdmin Maven Webapp</name>
</project>
There has got to be a solution here. I can't for a second believe that the Maven distributable for JSF is only good for compiling and not good for deployment.
When you're facing a "weird" exception suggesting that classes/methods/files/components/tags are absent or different while they are seemingly explicitly included in the web application such as the ones below,
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/faces/webapp/FacesServlet
java.util.MissingResourceException: Can't find javax.faces.LogStrings bundle
com.sun.faces.vendor.WebContainerInjectionProvider cannot be cast to com.sun.faces.spi.InjectionProvider
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED
The tag named inputFile from namespace http://xmlns.jcp.org/jsf/html has a null handler-class defined.
java.lang.NullPointerException at javax.faces.CurrentThreadToServletContext.getFallbackFactory
java.lang.AbstractMethodError at javax.faces.application.ViewHandlerWrapper.getWebsocketURL
java.lang.NullPointerException at com.sun.faces.config.InitFacesContext.cleanupInitMaps
or when you're facing "weird" runtime behavior such as broken HTTP sessions (jsessionid appears in link URLs over all place), and/or broken Faces view scope (it behaves as request scoped), and/or broken CSS/JS/image resources, then the chance is big that the webapp's runtime classpath is polluted with duplicate different versioned JAR files.
In your specific case with the ClassFormatError on the FacesServlet, it means that the JAR file containing the mentioned class has been found for the first time is actually a "blueprint" API JAR file, intented for implementation vendors (such as developers working for Mojarra and MyFaces). It contains class files with only class and method signatures, without any code bodies and resource files. That's exactly what "absent code attribute" means. It's purely intented for javadocs and compilation.
Always mark server-provided libraries as provided
All dependencies marked "Java Specifications" in Maven and having -api suffix in the artifact ID are those blueprint APIs. You should absolutely not have them in the runtime classpath. You should always mark them <scope>provided</scope> if you really need to have it in your pom. A well known example is the Jakarta EE (Web) API (formerly known as Java EE):
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version><!-- 8.0.0 or 9.0.0 or 9.1.0 or 10.0.0 or newer --></version>
<scope>provided</scope>
</dependency>
If the provided scope is absent, then this JAR will end up in webapp's /WEB-INF/lib, causing all trouble you're facing now. This JAR also contains the blueprint class of FacesServlet.
In your specific case, you have an unnecessary Faces API dependency:
<dependency>
<groupId>jakarta.faces</groupId>
<artifactId>jakarta.faces-api</artifactId>
</dependency>
This is causing trouble because this contains the blueprint class of FacesServlet. Removing it and relying on a provided Jakarta EE (Web) API as shown above should solve it.
Tomcat as being a barebones JSP/Servlet container already provides JSP, Servlet and EL (and since 8 also WebSocket) out the box. So you should mark at least jsp-api, servlet-api, and el-api as provided. Tomcat only doesn't provide Faces (and JSTL) out the box. So you'd need to install it via the webapp.
Full fledged Jakarta EE servers such as WildFly, TomEE, GlassFish, Payara, WebSphere, etc already provide the entire Jakarta EE API out the box, including Faces. So you do absolutely not need to install Faces via the webapp. It would only result in conflicts if the server already provides a different implementation and/or version out the box. The only dependency you need is the jakartaee-api exactly as shown here above.
See also How to properly configure Jakarta EE libraries in Maven pom.xml for Tomcat? for more elaborate explanation and examples of pom.xml for Tomcat 10 and 9.
Installing Faces on Tomcat 10 or newer
Tomcat 10.0.x is the first version using jakarta.* package instead of javax.* package. You'll for Tomcat 10.0.x thus need a minimum of Faces 3.0 instead of 2.3 because the javax.* package has been renamed to jakarta.* since Faces 3.0 only. In case you have Tomcat 10.1.x, then you need a minimum Faces version of 4.0.
There are two Faces implementations: Mojarra and MyFaces. You should choose to install one of them and thus not both.
Installing Mojarra 3.0 on Tomcat 10 or newer:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>jakarta.faces</artifactId>
<version><!-- Check https://eclipse-ee4j.github.io/mojarra --></version>
</dependency>
You can also check org.glassfish:jakarta.faces repository for current latest 3.0.x release version (which is currently 3.0.3). See also Mojarra installation instructions for other necessary dependencies (CDI, BV, JSONP).
Installing MyFaces 3.0 on Tomcat 10 or newer:
<dependency>
<groupId>org.apache.myfaces.core</groupId>
<artifactId>myfaces-impl</artifactId>
<version><!-- Check http://myfaces.apache.org --></version>
</dependency>
You can also check org.apache.myfaces.core:myfaces-impl repository for current latest 3.0.x release version (which is currently 3.0.2).
Don't forget to install JSTL API along, by the way. This is also absent in Tomcat.
<dependency>
<groupId>jakarta.servlet.jsp.jstl</groupId>
<artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
<version>2.0.0</version>
</dependency>
Also note that since Faces 2.3, CDI has become a required dependency. This is available out the box in normal Jakarta EE servers but not on servletcontainers such as Tomcat. In this case head to How to install and use CDI on Tomcat?
Installing Faces on Tomcat 9 or older
You can only use at maximum Faces 2.3 on Tomcat 9 or older because it is the latest version still using javax.* package.
Installing Mojarra 2.3 on Tomcat 9 or older:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>jakarta.faces</artifactId>
<version><!-- Check https://eclipse-ee4j.github.io/mojarra --></version>
</dependency>
You can also check org.glassfish:jakarta.faces repository for current latest 2.3.x release version (which is currently 2.3.18). See also Mojarra installation instructions for other necessary dependencies (CDI, BV, JSONP).
Installing MyFaces 2.3 on Tomcat 9 or older:
<dependency>
<groupId>org.apache.myfaces.core</groupId>
<artifactId>myfaces-impl</artifactId>
<version><!-- Check http://myfaces.apache.org --></version>
</dependency>
You can also check org.apache.myfaces.core:myfaces-impl repository for current latest 2.3.x release version (which is currently 2.3.9).
Note that Tomcat 6 as being Servlet 2.5 container supports at maximum Faces 2.1.
Don't forget to install JSTL API along, by the way. This is also absent in Tomcat.
<dependency>
<groupId>jakarta.servlet.jsp.jstl</groupId>
<artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
<version>1.2.7</version>
</dependency>
Also note that since Faces 2.3, CDI has become a required dependency. This is available out the box in normal Jakarta EE servers but not on servletcontainers such as Tomcat. In this case head to How to install and use CDI on Tomcat?
See also:
What exactly is Java EE / Jakarta EE?
How to install JSTL on Tomcat via Maven?
How to install CDI on Tomcat via Maven?
FacesServlet returns blank/unparsed page

Resources