We are having an issue making a SOAP client call on tomcat 8 in a RedHat linux environment running openjdk version "1.8.0_201", while the same call works fine with a similar config on a Windows machine (tomcat 8, Oracle java 8) and AIX (Oracle java 8, tomcat 7).
Here is the stacktrace:
java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2401)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:859)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1333)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1185)
at org.apache.cxf.ws.addressing.impl.AddressingFeatureApplier.initializeProvider(AddressingFeatureApplier.java:36)
at org.apache.cxf.ws.addressing.WSAddressingFeature.initializeProvider(WSAddressingFeature.java:46)
at org.apache.cxf.feature.AbstractFeature.initialize(AbstractFeature.java:49)
at org.apache.cxf.frontend.ClientFactoryBean.applyFeatures(ClientFactoryBean.java:112)
at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:100)
at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:157)
at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:476)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:343)
at javax.xml.ws.Service.getPort(Service.java:160)
Using
cxf version 2.7.18
pom.xml snippet
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>${cxf.version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-jetty</artifactId>
<version>${cxf.version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>${cxf.version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-rs-client</artifactId>
<version>3.0.16</version>
</dependency>
An IncompatibleClassChangeError happens because some code was compiled against one version of an API, but at runtime an incompatible version of the API is being loaded.
(In this case, the "Implementing class" incompatibility means that a class has been declared as implements Something, but at runtime the Something turns out to be a class rather than an interface. This API change is not allowed.)
The problem is that the stacktrace you have included doesn't tell us what class the incompatibility occurs in, and what it is incompatible with. The only real clue is that CXF appears to be loading an "provider"
So what is the solution?
There is no silver bullet. You will need to do some digging to find out what the actual problem is:
Check the logs where you got the stacktrace from for other log messages that may tell you what was being loaded.
Check the versions of the various CXF JAR files on the runtime platform.
Check that you don't have different versions of the JARs in the webapp itself and in Tomcat's shared library directories.
Modify Tomcat logging configs to set up logging level for the org.apache.catalina.loader package to DEBUG. This will log the JAR file that each class is loaded from.
I was obtaining java.lang.IncompatibleClassChangeError due to importing different versions of the library and the plug-in used to generate the WSDL stubs
These dependencies made my application crash on booting
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-spring-boot-starter-jaxws</artifactId>
<version>3.3.0</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.4.3</version>
</dependency>
Modifying the version of the plug-in used (in dependencies and in the plug-in declaration), the application boots without error and the web service is correctly deployed and can process requests.
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-spring-boot-starter-jaxws</artifactId>
<version>3.3.0</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.3.0</version>
</dependency>
Related
I have an application in which the following modules are:
1- Jax-ws
2- JMS and its implementation by Activemq with the following dependency:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client</artifactId>
<version>2.4.0</version>
</dependency>
3- the version of JDK is 1.8
4- Its application server is Wildfly
I want to change and upgrade my application to JDK 17(LTS), due to this migration the javax package is replaced with jakarta package.
My question is:
1- What except Wildfly is which supports Jakarta-ws and jakarta-jms? because Wildfly is so heavy for my solution.
2- Before for JMS configuration, the following dependency were:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-all</artifactId>
<version>5.15.2</version>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client</artifactId>
<version>2.4.0</version>
</dependency>
after migration to JDK-17, which dependency should to add to implement jakarta-jms by activemq
Check out OpenLiberty, it is fully open source and supports Java 17 and Jakarta EE 8 and 9. Moreover its fully composable, so you can pick and choose what features (APIs) you need in the server.
WildFly can be easily reduced to your usage since you can easily disable what you don't need. You may want to take a look at Galleon as a way to provision your server tailored to your need.
I have the task to built a java JAR that works fine with JAVA 6. The functionality is not complex, it just needs to call a SOAP WS (the WSDL was provided to me) and then exit with 0 or -1 wether the WS return ok or not ok. Seems easy.
I'm using Eclipse IDE, so I was able to generate the client from the WSDL and the schema provided and I only had to built the parameter object from the arguments the JAR receives and do some validations on dates, quantities and stuff like that. I'm using Maven to manage the dependencies because at first, the auto generated client didn't work well and it kept throwing error as "class not found" or "class not def", so I added the following dependencies in order to solve all of these errors:
<dependencies>
<dependency>
<groupId>jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>rt</artifactId>
<version>2.3.2</version>
</dependency>
<dependency>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.3.1</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-ri</artifactId>
<version>2.3.0</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.ibm.informix</groupId>
<artifactId>ifxjdbc</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>com.ibm.informix</groupId>
<artifactId>ifxjdbcx</artifactId>
<version>1.6</version>
</dependency>
</dependencies>
I tested it on my local machine and it worked well, from Eclipse console and from my Windows CMD console...
The thing is this JAR is part of a bigger process, so my workmates are going to execute it on another machine. When I export it and they try to execute it throws a version error on some classes like ProviderImpl (which is a class I didn't create of course, it's some dependency):
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/xml/ws/spi/ProviderImpl : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:648)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:272)
at java.net.URLClassLoader.access$000(URLClassLoader.java:68)
at java.net.URLClassLoader$1.run(URLClassLoader.java:207)
at java.net.URLClassLoader$1.run(URLClassLoader.java:201)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:200)
at java.lang.ClassLoader.loadClass(ClassLoader.java:325)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:296)
at java.lang.ClassLoader.loadClass(ClassLoader.java:270)
at javax.xml.ws.spi.FactoryFinder.safeLoadClass(FactoryFinder.java:170)
at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:50)
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:110)
at javax.xml.ws.spi.Provider.provider(Provider.java:102)
at javax.xml.ws.Service.<init>(Service.java:76)
at com.mvc.model.services.webservices.proposals.ProposalsService_Service.<init>(ProposalsService_Service.java:39)
at mainpackage.MainClass.setEndpoint(MainClass.java:69)
at mainpackage.MainClass.main(MainClass.java:44)
This how I deduced that on my local environment, my jar was using the correct java version for its dependencies automatically (I have a couple of jdks installed and default one is newer than Java 6), but the production environment my team is on only have Java 6.
So my question is: how can I solve this? Why did the generate client from Eclipse used this class even if I have the build path of the project configured to Java 6?
I already tried using older versions, but it's impossible for the rt one because there are no Java 6 version or I couldn't find it. I also tried specifying the maven compiler version in the pom.xml, but it didn't do nothing for me. So i'm out of options, because they can't change the Java version of that environment.
Thank you everyone.
I'm trying to port an old Java 8 webapp containing JAX-WS based webservices to Java 11 and Tomcat 9 on Windows 10. Note that this app is not using Maven or any other dependency management and there are reasons against a conversion.
After adding the jaxws-rt library, I'm getting the following error:
java.lang.Error: javax.xml.soap.SOAPException: Unable to create SAAJ meta-factoryProvider com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl not found
at com.sun.xml.ws.api.SOAPVersion.<init>(SOAPVersion.java:193)
at com.sun.xml.ws.api.SOAPVersion.<clinit>(SOAPVersion.java:91)
at com.sun.xml.ws.api.BindingID.<clinit>(BindingID.java:342)
at com.sun.xml.ws.spi.ProviderImpl.createEndpoint(ProviderImpl.java:107)
at javax.xml.ws.Endpoint.create(Endpoint.java:162)
at javax.xml.ws.Endpoint.create(Endpoint.java:116)
...
The internal infix already shouldn't be there, as this seems to be a Java 8 package stripped from Java 11. I've tried the following:
adding the libs saaj-api-1.3.5.jar and saaj-impl-1.5.1.jar
starting Tomcat with -Djavax.xml.soap.SAAJMetaFactory=com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl, which point to a location in saaj-impl-1.5.1.jar
creating a file <MyWebapp>/META-INF/services/javax.xml.soap.SAAJMetaFactory with contents com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl (which btw. is also contained in saaj-impl-1.5.1.jar)
all to no avail. It keeps asking for that internal implementation which isn't there anymore.
How do I tell Java to use the correct implementation and, if possible, how can I find out who is causing this implementation to show up anyway?
This worked for me.
I needed to add following dependencies.
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>rt</artifactId>
<version>2.3.2</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.3.2</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-ri</artifactId>
<version>2.3.2</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.sun.xml.messaging.saaj</groupId>
<artifactId>saaj-impl</artifactId>
<version>1.5.1</version>
</dependency>
I also needed to set property.
System.setProperty("javax.xml.soap.MetaFactory","com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl");
I upgraded my application's spring version from 3.2.10 to 4.3.16, and also my http-client to 4.3.3 from 4.2.1. While running my application, I am getting error page.
Can you try including the following dependency in your pom?
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle-jaxrs</artifactId>
<version>2.6.0</version>
</dependency>
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