I wrote a web application with Eclipse Tomcat and it works on my local Tomcat 7, when I tried to publish it online on a Tomcat 7, I had the following error:
SEVERE: Servlet.service() for servlet [obliquid.servlet.Index] in context with path [/cp] threw exception [The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application]
Tomcat 7 has "Spec versions: Servlet 3.0, JSP 2.2, EL 2.2", so JSTL is not included?
When I tried to upload standard.jar and jstl.jar I had the following error:
org.apache.jasper.JasperException: /jsp/index.jsp (line: 3, column: 62) Unable to read TLD "META-INF/c.tld" from JAR file "jndi:/localhost/cp/WEB-INF/lib/standard.jar": org.apache.jasper.JasperException: Failed to load or instantiate TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV
I did some googling, but I couldn't sort it out, some said it could be caused by conflicting versions of the jars. Maybe I should not include those jars and use a different JSTL url? Mine is for JSTL 1.1 I think, is there a new URL for JSTL 1.2?
What should I do to solve the problem and make this application run?
I have been fighting with this for several hours.
Here is a complete solution.
I am using Tomcat 7, which is a Servlet 3.0-compliant server.
If you desire to use the Servlet 3.0 spec, you must have your web.xml as follows:
<web-app
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
If you're using Maven, your pom.xml should have these lines.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jstl-impl</artifactId>
<version>1.2</version>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>javax.servlet</groupId>
</exclusion>
<exclusion>
<artifactId>jsp-api</artifactId>
<groupId>javax.servlet.jsp</groupId>
</exclusion>
<exclusion>
<artifactId>jstl-api</artifactId>
<groupId>javax.servlet.jsp.jstl</groupId>
</exclusion>
</exclusions>
</dependency>
These dependencies are very important. JSTL 2.1 + Tomcat 7 + Servlet 3.0 is very broken unless you fix it by using these lines, especially the exclusion part. What is happening is the JSTL 2.1 Jars are actually pulling in the wrong versions of the Servlet spec--2.5. Unless you stop that from happening, you will be in a whole world of pain. A special thanks to Mr. Murray Todd Williams for these insights .
Finally, in case Maven can't find those JARS, you can make Eclipse happy by including three JARS with your project and doing the usual Project--> Properties--> Java Build Path and include them that way--though Maven should take care of it.
javax.servlet-api-3.0.1.jar
javax.servlet.jsp.jstl-1.2.1.jar
javax.servlet.jsp.jstl-api-1.2.1.jar
Please note! This exact configuration only applies if you are using the magic combination of:
A Servlet 3.0-compliant application server such as Tomcat 7
Your web.xml has the right namespace for the Servlet 3.0 spec
You have those three JARS and no other JSTL or Servlet JARS on your classpath.
Make sure you do not place copies of these JARs in your WEB-INF/lib directory because they would in that case be sent to the server thereby causing LinkageErrors.
In your JSP, you need to have this PRECISE line, formatted exactly as I have it or else Eclipse will whine that it doesn't recognize the c:blah tags:
<%#taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
What a danged PITA! This is MUCH harder to implement than any other version of JSTL. This is the only example of something getting much more complicated rather than simpler in later iterations.
Tomcat has never included JSTL.
You should put the jstl and standard jars in WEB-INF/lib (you've done that), and make sure you have the permissions to read them (chmod)
Your URI is correct and it should work (works here)
Your uri is correct for JSTL 1.2. You need to do two things :
Change your web.xml to use the latest web-app version.
It should look something like this or a later version;
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
Secondly put the correct version of jstl jars in your code. For 1.2 You can download them here.
This should give you two jars:
jstl-api.jar
jstl-impl.jar
Use these, instead of standard.jar and jstl.jar which were for previous version.
Let us know how this works for you.
For running on apache tomcat 7 adding these into your POM is probably appropriate. These jars don't reference javax.servlet jars like the glassfish ones do, so there is no need for exclusions.
<dependency>
<groupId>org.apache.taglibs</groupId>
<artifactId>taglibs-standard-spec</artifactId>
<version>1.2.1</version>
</dependency>
<dependency>
<groupId>org.apache.taglibs</groupId>
<artifactId>taglibs-standard-impl</artifactId>
<version>1.2.1</version>
</dependency>
For Tomcat, there is a simpler dependency solution for JSTL 1.1.2:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<!-- Apache Taglibs does not implement version 1.2 -->
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>c</artifactId>
<version>1.1.2</version>
<type>tld</type>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>fmt</artifactId>
<version>1.1.2</version>
<type>tld</type>
</dependency>
<dependency>
See here for more details (personal blog).
REM: More details as requested, one has to include JSTL dependencies to make them available on Tomcat. Yet, version 1.2 is not really necessary, since version 1.1.2 (delivered by Apache, like Tomcat) does the job too. Its only requirement is Servlet 2.4 and JSP 2.2, and the OP mention Servlet 3.0 and JSP 2.0, which is good enough.
There are two answers here that are mostly correct with regard to how to solve this problem when using Maven when dealing with this issue. However, both are not 100% complete.
Using Exclusions per #Tom Hunter's answer
This answer works. However, there will still be log messages from Tomcat regarding duplicate TLD definitions. This is because both the jstl and jstl-impl artifacts include the TLD definitions. To remove those messages, I think a better Maven setup is this:
<dependency>
<version>1.2</version>
<scope>runtime</scope>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>jstl-api</artifactId>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>javax.servlet</groupId>
</exclusion>
<exclusion>
<artifactId>jsp-api</artifactId>
<groupId>javax.servlet.jsp</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jstl-impl</artifactId>
<version>1.2</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>javax.servlet</groupId>
</exclusion>
<exclusion>
<artifactId>jsp-api</artifactId>
<groupId>javax.servlet.jsp</groupId>
</exclusion>
<exclusion>
<artifactId>jstl-api</artifactId>
<groupId>javax.servlet.jsp.jstl</groupId>
</exclusion>
</exclusions>
</dependency>
This includes only the jstl api classes with the necessary exclusions to avoid the problems explained in the rest of that answer.
Using newer POM versions per #George's answer
It took me a while to realize it, but there are newer versions of the JSTL pom's available. It's really confusing because these newer packages use similar, but slightly different naming conventions. These newer versions mark the javax.servlet, javax.jsp, etc dependencies as provided scope so that they do not need to be excluded. The 1.2.1 version depends on a 1.2.1 version of the jstl-api. And so this would work as well as above answer:
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>javax.servlet.jsp.jstl</artifactId>
<version>1.2.1</version>
<scope>runtime</scope>
</dependency>
This differs slightly from George's answer because I changed scope to runtime. George specified scope as provided. With a provided scope, the jars would have to be copied manually in to the Tomcat lib directory, or some other dependency would have to included the necessary implementation.
However, I could not find the 1.2.1 version of the impl in maven central, jboss repo, or any other repos. I ended up going around in circles and finally just used a local file based repo to store the jar. The dependency and jar are described here:
http://mvnrepository.com/artifact/org.glassfish.web/javax.servlet.jsp.jstl/1.2.1
None of these worked for me, I simply created the project without using Maven and adding the JAR files directly.
I suffered from the error: SEVERE: Servlet.service() for servlet [obliquid.servlet.Index] in context with path [/cp] threw exception [The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application] on Tomcat 7
The Solution:
copy jars jstl-1.2.jar and javax.servlet.jsp.jstl-api-1.2.1.jar straight to Tomcat Library Directory. Redeploy Tomcat Library in Eclipse again.
The following dependencies in the pom.xml seem to resolve the issue:
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>javax.servlet.jsp.jstl</artifactId>
<version>1.2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>javax.servlet.jsp.jstl-api</artifactId>
<version>1.2.1</version>
<scope>provided</scope>
</dependency>
That was a strange combination - two different groupIds - but it does work :). My expectation was to see the same group ID for both jars. I managed to redeploy without a problem to Tomcat 7.
Also, if you see "Unkown tag
Related
I have a spring boot application that works fine when I run it using the embedded server from Intellj. However, when I package it into .war file and deploy it on tomcat I get the following error:
org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/file-upload-0.0.1-SNAPSHOT]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:985)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857)
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:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: More than one fragment with the name [spring_web] was found. This is not legal with relative ordering. See section 8.2.2 2c of the Servlet specification for details. Consider using absolute ordering.
at org.apache.tomcat.util.descriptor.web.WebXml.orderWebFragments(WebXml.java:2200)
at
org.apache.tomcat.util.descriptor.web.WebXml.orderWebFragments(WebXml.java:2159)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1124)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:769)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:299)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5176)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 10 more
21-Jan-2019 01:51:04.709 SEVERE [localhost-startStop-1]
org.apache.catalina.startup.HostConfig.deployWAR Error deploying web application archive [C:\Users\dennismo\Dev\Projects\Production Prep\file-upload-module\webapps\file-upload-0.0.1-SNAPSHOT.war]
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/file-upload-0.0.1-SNAPSHOT]]
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:758)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:985)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
My project does not contain multiple web-fragment so I don't know what could be causing this problem.
pom.xml
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.0.RELEASE</version>
<relativePath/> <!-- lookup parent from salaryPaymentRequestRepo -->
</parent>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
<akka.version>2.5.17</akka.version>
</properties>
<repositories>
<repository>
<id>default</id>
<url>http://repo.maven.apache.org/maven2</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<version>1.4.197</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.univocity</groupId>
<artifactId>univocity-parsers</artifactId>
<version>2.7.6</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>2.9.0</version>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>26.0-jre</version>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.23.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
<version>3.11.0</version>
</dependency>
<dependency>
<groupId>ma.glasnost.orika</groupId>
<artifactId>orika-core</artifactId>
<version>1.4.2</version><!-- or latest version -->
<exclusions>
<exclusion>
<artifactId>javassist</artifactId>
<groupId>org.javassist</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-actor_2.12</artifactId>
<version>${akka.version}</version>
</dependency>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-stream_2.12</artifactId>
<version>${akka.version}</version>
</dependency>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-persistence_2.12</artifactId>
<version>${akka.version}</version>
</dependency>
<dependency>
<groupId>com.typesafe.akka</groupId>
<artifactId>akka-testkit_2.12</artifactId>
<version>${akka.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc7</artifactId>
<version>12.1.0.2</version>
<scope>system</scope>
<systemPath>${basedir}/src/main/resources/lib/ojdbc7-12.1.0.jar</systemPath>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
add <absolute-ordering /> tag to your web.xml just under the <display-name> tag.
should work.
Cleaning the server worked for me. Just do the following :
Right click on the server -> Clean.
Then redeploy the app on the server.
Sounds like you have two different versions of Spring, check your dependencies to see if you have a dependency to another Spring-version.
mvn dependency:tree -Dverbose -Dincludes=groupId:artifactId
I had the same problem when building a war file with maven because I did not clean before packaging and maven was including multiple versions of spring jar files from previous builds.
This error seems to happen after project's spring framework update, clearing the project history file in tomcat webapps may solve the problem.
This problem was solved by adding absolute ordering of deployment descriptors.
The tag <absolute-ordering/> was added to the web.xml
Reference:
https://www.oracle.com/technetwork/articles/javaee/javaee6overview-part2-136353.html
I had this occur after I updated the Spring Framework version in a Maven project. I was finally able to resolve the issue by running mvn clean, apparently the old Spring JARs were being picked up somewhere under target.
This error generally comes from that if we have two copy of spring in our container, which get loaded by different class loaders(in my case shared class loader and webapp class loader).
Check effective pom, if you have any bundle embed spring jars/classes, if so remove it, you should use the one installed as bundle from container.
If you manually adds all the Jars then you have to delete WEB-INF/lib/spring-web-5.2.9.RELEASE-sources.jar or similar jar file (may be your jar version will be different). Once you delete that jar tomcat will start working.
My project is Springboot based version (1.5.21.RELEASE) and generating war and deploying in physical tomcat.
I had gotten the same issue and got resolved with below approach.
Solution: Exclude tomcat-embed-websocket dependency from spring-boot-starter-web in the pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>${spring.boot.version}</version>
<exclusions>
**<exclusion>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-websocket</artifactId>
</exclusion>**
</exclusions>
</dependency>
Just an answer from newbbie to newbbies:
Make sure you place web.xml inside /WebContent/WEB-INF.
I placed it inadvertently in /WebContent (not /WEB-INF), and almost got crazy trying to unsuccessfully apply some of the proposed solutions, the error message was exactly the same.
For me this meant that I was including some "shaded jars" that bundled copies of spring within them. So all the same "spring version" but multiple copies of spring causes this.
You can check if this is the case by going to tomcat/webapps/your_webapp/WEB-INF/lib, unjarring all the jars, and searching for "spring_web"
ex:
# first unjar everything then
WEB-INF/lib $ grep spring_web . -r
spring-web-4.3.12.RELEASE/META-INF/web-fragment.xml
7: <name>spring_web</name>
some_other_shaded_jar/META-INF/web-fragment.xml
7: <name>spring_web</name>
If this is the case you'd need to use the absolute fix of the other answers or not include multiple copies of spring somehow.
Seems this is a change introduced in tomcat 7.0.93 FWIW (so it didn't throw this failure in earlier versions of tomcat 7)
Your web.xml should look like this (added <absolute-ordering/> inside the tag web-app tag)
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd" >
<web-app>
<display-name>Archetype Created Web Application</display-name>
<absolute-ordering/>
</web-app>
I had the same problem and solved it. Got similar errors but not used spring boot. I have used spring 3.x with java 8. If above solutions are not working change the jars and search whether those jars are compatible with the java version you are using or not. spring 3.x is not compatible with java 8.
I solved similar problem by removing all my apps (I had there two different apps) from webapps folder and then redeployed my war file.
I had to add this in web.xml to make it work :
<absolute-ordering>
<name>fragment_name_if_required</name>
<others></others>
</absolute-ordering>
All these answers are great but also check if "Apache CXF" lib is in your classpath, it apparently conflicts with Spring Web 5.2.3, for me I temporary removed because I'm actually not using it and now my project is running okay.
For me, this issue happened when Tomcat was not properly installed .I have reinstalled and updated the installation path at:
eclipse window->preferences->runtime ENV -> path of the newly installed tomcat
After setting the correct path, it worked fine.
For me , it was because of 2 spring-web jars i.e. spring-web-5.02-release.jar and spring-web-sources-5.02-release.jar in build path. By removing spring-web-sources-5.02-release.jar, issue is solved.
Had the same issue and wanted to get to the root cause. I knew spring-web jar's fragment is called 'spring_web'. However my source code did not have 'spring_web' fragment anywhere else. So I used a tool (jfind) to search for 'spring_web' through an expanded form of my EAR that was generated at build time. Surprisingly, 'spring_web' was found in another project's web-fragment jar that was generated at build time. On resolving this second occurrence, the issue was gone. So it seems to be due to duplicate 'spring_web' fragment and we need to have just one.
If you have previously built the project with another version and then changed the version and tried to build again, this exception is thrown. You can delete the target folder in your application. If you still get an exception, you can go to the project directory from the terminal and type mvn clean install
Remove all the unused dependencies from the lib folder.
Now try to rerun the application on the server.
Hope it will work now.
I was fighting with this few hours. Solution for me was to invalidate IntelliJ cache.
This problem showed up when I was in the process of upgrading spring framework.
Intellij was packaging two versions of the same library and that's why I was getting an error.
This happened to me when I changed the version of one of the dependencies in pom.xml, undeploying and deploying the webapp fixed it for me
See the below Line in error log:
Caused by: java.lang.IllegalArgumentException: More than one fragment with the name [spring_web] was found. This is not legal with relative ordering. See section 8.2.2 2c of the Servlet specification for details. Consider using absolute ordering.
which says to use absolute ordering.
So, you have to add <absolute-ordering/> tag in your web.xml file inside <web-app> tag.
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
I sometimes see these following declaration in pom.xml...
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<scope>provided</scope>
</dependency>
....
as you can see, spring-boot-starter-web was declared as well
as tomcat-embed-jasper.
isn't it spring-boot-starter-web already have an embedded tomcat?
why some developers still declare tomcat-embed-jasper along with boot-starter-web? or is there any reason?
As you said, the spring-boot-starter-web includes the spring-boot-starter-tomcat. You could check it here
The spring-boot-starter-tomcat includes the tomcat-embed-core. You could check it here
But, seems like tomcat-embed-core doesn't include tomcat-embed-jasper. In fact, is tomcat-embed-jasper who includes dependency with tomcat-embed-core. Check it here
Anyway, the tomcat-embed-jasper is marked as provided, so indicates that you expect the JDK or a container to provide the dependency at runtime. This scope is only available on the compilation and test classpath, and is not transitive.
In conclusion, the spring-boot-starter-web includes the tomcat embedded dependency but it doesn't includes the jasper embedded dependency, so that should be the reason to declare it separately.
Also, remember that using Spring IO Platform as parent you are able to manage dependencies easily. To know more about this you could read my post
Hope it helps,
Extended from jcgarcia's answer.
Even it is provided, but when you build as war, spring-boot-maven-plugin will include two more jar :
ecj-3.12.3.jar
tomcat-embed-jasper-8.5.23.jar
To those who are still facing this error in 2022 with Java Version 17, Maven Version 3.0.0 and Package Jar. I also ran into the same issue just now, seems like even though we set <scope>Provided</scope> Maven is not picking up the jar. What you can do instead is just take that completely off while adding the dependency and run the Maven to install dependencies again. It will fix it for sure. So your pom.xml file will go:-
From
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<scope>provided</scope>
</dependency>
To
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
</dependency>
I am facing an issue during deployment of a service in Tomcat 8. Getting following error :
Caused by: java.lang.NoSuchMethodError:
javax.servlet.ServletContext.getVirtualServerName()Ljava/lang/String;
at org.apache.tomcat.websocket.server.WsServerContainer.(WsServerContainer.java:149)
at org.apache.tomcat.websocket.server.WsSci.init(WsSci.java:131)
at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:47)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5244)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 10 more
Method getVirtualServerName was introduced in Servlet 3.1 and after extracting MANIFEST.MF from my servlet-api jar I got following details :
Specification-Title: Java API for Servlets
Specification-Version: 3.1
Specification-Vendor: Sun Microsystems, Inc.
Implementation-Title: javax.servlet
Which says that its having 3.1. So is there any other reason for this error? Please help
Check all your Maven (or equivalent) dependencies and make sure that you - or most likely another dependency - are not pulling in a pre-3.1 version of the javax.servlet / servlet-api that may be taking precedence over what's in your Tomcat 8. If you've manually deployed, make sure you haven't manually copied any servlet-api JARs into Tomcat itself.
See: https://stackoverflow.com/a/26232535/954442
The method getVirtualServerName has been added in ServletContext in Servlet 3.1. See the java doc's method getVirtualServerName.
This problem has 3 primary causes:
Your servlet version is older than 3.1.
Some other jar has the servlet with a version older than 3.1.
Your tomcat version is older than 8
to solve it, you can try the below way.
I. Check your pom.xml for the code below.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
if your pom.xml has the above code, it would still has that problem. you can do the second way.
II. to check your other jar has refer to the javax.servlet-api jar. for example, the org.apache.santuario has refer to the javax.servlet-api jar. the pom.xml:
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.3</version>
</dependency>
but when you look at the maven dependencies, it refer to the javax.servlet-api jar whose version is 2.3 older than 3.1.
so you should exclude the 2.3 version. pom.xml:
<!-- exclude servlet-api 2.3 jar-->
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.3</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- servlet-api 3.1 version has getVirtualServerName() -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
III. spring boot run the default tomcat 7. so define your tomcat version 8 instead of tomcat 7. so add the code your pom.xml:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
<tomcat.version>8.5.5</tomcat.version>
</properties>
I had this error on IntelliJ with maven after updating IntelliJ.
I could run the tests with maven but not from my IDE.
I solved the problem by removing the ./idea and project.iml files and reloading the project.
If you have used this dependency:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-jetty</artifactId>
<version>1.23.0</version>
</dependency>
Then please exclude as below:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-jetty</artifactId>
<version>1.23.0</version>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>org.mortbay.jetty</groupId>
</exclusion>
</exclusions>
</dependency>
Spring boot will run tomcat 7 per default, you have to override maven build tomcat.version in your pom.xml. See below to run tomcat 8.0.30
<properties>
<tomcat.version>8.0.30</tomcat.version>
</properties>
Should fix your problem.
Solved
On my mac with java 8 was facing issue with downloaded tomcat from site and unzip.
My issue got solved because there was a extra servlet-api.jar file which was getting picked up. It was coming from
/Library/Java/Extensions/servlet-api.jar
For finding it in your system you can use
sudo find / -name servlet-api.jar
Removed it by backing it up somewhere else.
I was following this for intallation
https://gist.github.com/ddanailov-nmdp/c97aba2ca926b9627f6b4f7174083a32
Assuming this problem appears when you ran the application in Eclipse.
Use Dependency Hierarchy view to search for servlet-api in pom.xm
After a huge pain & sifting through all these stackoverflow answers the only thing that ended up working for me was downgrading from tomcat8 to tomcat7. I know this isn't an ideal solution, and perhaps it was just a fresh install of tomcat that solved my problem. If all else fails give that a shot.
I attach gradle style dependencies code.
dependencies {
compileOnly("javax.servlet:javax.servlet-api:3.1.0")
This surely has something to do with the version of javax.servlet and version of Tomcat.
In my case, it went away when I declared javax.servlet dependency in gradle with no version. Like this -
compile('javax.servlet:servlet-api')
I'm currently working through the tutorial found on the Apache Struts website.
Currently, whenever I press submit on the form, or when I click the Bruce Philips hyperlink, I get a NoSuchMethodError.
javax.servlet.ServletException: Filter execution threw an exception
root cause
java.lang.NoSuchMethodError: ognl.SimpleNode.isEvalChain(Lognl/OgnlContext;)Z
com.opensymphony.xwork2.ognl.OgnlUtil.isEvalExpression(OgnlUtil.java:224)
com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:215)
com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:187)
com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:174)
com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:152)
....
I'm not too sure what the issue is either and I believe I've included everything the tutorial states. I've tried including the dependency in my pom.xml, but that makes no difference either.
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>Struts2PracticeSite</groupId>
<artifactId>Struts2PracticeSite</artifactId>
<packaging>war</packaging>
<version>0.0.1</version>
<build>
<finalName>Struts2PracticeSite</finalName>
</build>
<dependencies>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.3.8</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
</dependency>
</dependencies>
</project>
Any ideas on how I would fix this problem?
struts2.3.1.1 allows ognl3.0.2.jar + ognl3.0.2-source.jar + ognl3.0.1
at the same time
. struts2.3.1.2 can only have ognl3.0.4, but remove other versions
ognl3.0.4 is a must and can be the only ognl jar!
Remove ognl as a dependency as this is already a transient dependency of struts 2.3.8 itself and make sure if Eclipse properly deployed your applications, there are many problems with that.
Problem found... Turns out my server version is too old to handle struts 2. I was previously using Geronimo version 2.0.2, and it now runs fine on GlassFish 3.1.2.
Use these Jar Combinations for Struts 2 application
I believe the dependencies you need
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>${struts2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-tiles-plugin</artifactId>
<version>${struts2.version}</version>
</dependency>
there are also other dependencies but these are necessary for Struts2 Tiles application.