Why did Servlet.service() for servlet jsp throw this exception? - java

I get the following error, what could be the problem?
My context descriptor:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<servlet>
<servlet-name>UploadServlet</servlet-name>
<servlet-class>controller.UploadServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>UploadServlet</servlet-name>
<url-pattern>/UploadServlet</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at org.apache.jsp.index_jsp._jspInit(index_jsp.java:22)
at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:52)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:159)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Feb 23, 2010 11:35:28 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at org.apache.jsp.index_jsp._jspInit(index_jsp.java:22)
at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:52)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:159)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)

It can be caused by a classpath contamination. Check that you /WEB-INF/lib doesn't contain something like jsp-api-*.jar.

If your project is Maven-based, remember to set scope to provided for such dependencies as servlet-api, jsp-api. Otherwise, these jars will be exported to WEB-INF/lib and hence contaminate with those in Tomcat server. That causes painful problems.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>

I had this error; it happened somewhat spontaneously, and the page would halt in the browser in the middle of an HTML tag (not a section of code). It was baffling!
Turns out, I let a variable go out of scope and the garbage collector swept it away and then I tried to use it. Thus the seemingly-random timing.
To give a more concrete example... Inside a method, I had something like:
Foo[] foos = new Foo[20];
// fill up the "foos" array...
return Arrays.asList(foos); // this returns type List<Foo>
Now in my JSP page, I called that method and used the List object returned by it. The List object is backed by that "foos" array; but, the array went out of scope when I returned from the method (since it is a local variable). So shortly after returning, the garbage collector swept away the "foos" array, and my access to the List caused a NullPointerException since its underlying array was now wiped away.
I actually wondered, as I wrote the above method, whether that would happen.
The even deeper underlying problem was premature optimization. I wanted a list, but I knew I would have exactly 20 elements, so I figured I'd try to be more efficient than new ArrayList<Foo>(20) which only sets an initial size of 20 but can possibly be less efficient than the method I used. So of course, to fix it, I just created my ArrayList, filled it up, and returned it. No more strange error.

The problem is in your JSP, most likely you are calling a method on an object that is null at runtime.
It is happening in the _jspInit() call, which is a little more unusual... the problem code is probably a method declaration like <%! %>
Update: I've only reproduced this by overriding the _jspInit() method. Is that what you're doing? If so, it's not recommended - that's why it starts with an _.

I tried my best to follow the answers given above. But I have below reason for the same.
Note: This is for maven+eclipse+tomcat deployment and issue faced especially with spring mvc.
1- If you are including servlet and jsp dependency please mark them provided in scope.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>javax.servlet.jsp-api</artifactId>
<version>2.3.1</version>
<scope>provided</scope>
</dependency>
Possibly you might be including jstl as dependency. So, jsp-api.jar and servlet-api.jar will be included along. So, require to exclude the servlet-api and jsp-api being deployed as required lib in target or in "WEB-INF/lib" as given below.
<dependency>
<groupId>javax.servlet.jsp.jstl</groupId>
<artifactId>jstl-api</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>
</exclusions>
</dependency>

Related

Cannot resolve taglib with uri http://java.sun.com/jsp/jstl/core [duplicate]

I don't know what I've done incorrectly, but I can't include JSTL. I have jstl-1.2.jar, but unfortunately I get exception:
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:315)
at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:148)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:429)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1439)
at org.apache.jasper.compiler.Parser.parse(Parser.java:137)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:170)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:332)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:312)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:299)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:586)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
I have:
pom.xml
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
web.xml
<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_2_5.xsd"
version="2.5">
index.jsp
<%# taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
<html>
<head></head>
<body></body>
</html>
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
That URI is for JSTL 1.0, but you're actually using JSTL 1.2 which uses URIs with an additional /jsp path (because JSTL, who invented EL expressions, was since version 1.1 integrated as part of JSP 2.0 (released way back in 2001!) in order to share/reuse the EL logic in plain JSP too).
So, fix the taglib URI accordingly based on JSTL 1.2 documentation:
<%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Further you need to make absolutely sure that you do not throw multiple different versioned JSTL JAR files together into the runtime classpath. This is a pretty common mistake among Tomcat users. The problem with Tomcat is that it does not offer JSTL out the box and thus you have to manually install it. This is not necessary in normal Jakarta EE servers. See also What exactly is Java EE?
In your specific case, your pom.xml basically tells you that you have jstl-1.2.jar and standard-1.1.2.jar together. This is wrong. You're basically mixing JSTL 1.2 API+impl from Oracle with JSTL 1.1 impl from Apache. You should stick to only one JSTL implementation and the API version must match the impl version.
Installing JSTL on Tomcat 10.1.x
In case you're already on Tomcat 10.1.x (the second Jakartified version, with jakarta.* package instead of javax.* package, but the first version with the updated jakarta.tags.* namespace URNs instead of http://java.sun.com/jsp/jstl/* namespace URLs), use JSTL 3.0 via this sole dependency using the default Maven scope of compile (because Tomcat doesn't provide it out the box!):
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>3.0.1</version>
</dependency>
Note that the API dependency is already transitively included via this impl dependency, so you do not need to explicitly declare it.
Non-Maven users can achieve the same by dropping the following two physical files in /WEB-INF/lib folder of the web application project (do absolutely not drop standard*.jar or any loose .tld files in there! remove them if necessary).
jakarta.servlet.jsp.jstl-3.0.1.jar (this is the JSTL 3.0.1 impl of EE4J)
jakarta.servlet.jsp.jstl-api-3.0.0.jar (this is the JSTL 3.0 API)
As said, the namespace URIs have been changed to become URNs instead of URLs. JSTL core is since JSTL version 3.0 available via an easier to remember namespace URI in URN format:
<%# taglib prefix="c" uri="jakarta.tags.core" %>
See also JSTL 3.0 documentation.
Installing JSTL on Tomcat 10.0.x
In case you're on Tomcat 10.0.x (the first Jakartified version, with jakarta.* package instead of javax.* package), use JSTL 2.0 via this sole dependency using the default Maven scope of compile (because Tomcat doesn't provide it out the box!):
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>2.0.0</version>
</dependency>
Note that the API dependency is already transitively included via this impl dependency, so you do not need to explicitly declare it.
Non-Maven users can achieve the same by dropping the following two physical files in /WEB-INF/lib folder of the web application project (do absolutely not drop standard*.jar or any loose .tld files in there! remove them if necessary).
jakarta.servlet.jsp.jstl-2.0.0.jar (this is the JSTL 2.0 impl of EE4J)
jakarta.servlet.jsp.jstl-api-2.0.0.jar (this is the JSTL 2.0 API)
Installing JSTL on Tomcat 9-
In case you're not on Tomcat 10 yet, but still on Tomcat 9 or older, use JSTL 1.2 via this sole dependency (this is compatible with Tomcat 9 / 8 / 7 / 6 / 5 but not older) using the default Maven scope of compile (because Tomcat doesn't provide it out the box!):
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>1.2.6</version>
</dependency>
Note that the API dependency is already transitively included via this impl dependency, so you do not need to explicitly declare it.
Non-Maven users can achieve the same by dropping the following two physical files in /WEB-INF/lib folder of the web application project (do absolutely not drop standard*.jar or any loose .tld files in there! remove them if necessary).
jakarta.servlet.jsp.jstl-1.2.6.jar (this is the JSTL 1.2 impl of EE4J)
jakarta.servlet.jsp.jstl-api-1.2.7.jar (this is the JSTL 1.2 API)
Installing JSTL on normal JEE server
In case you're actually using a normal Jakarta EE server such as WildFly, Payara, TomEE, GlassFish, WebSphere, OpenLiberty, WebLogic, etc instead of a barebones servletcontainer such as Tomcat, Jetty, Undertow, etc, then you do not need to explicitly install JSTL at all. Normal Jakarta EE servers already provide JSTL out the box. In other words, you don't need to add JSTL to pom.xml nor to drop any JAR/TLD files in webapp. Solely the provided scoped Jakarta EE coordinate is sufficient:
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version><!-- 10.0.0, 9.1.0, 9.0.0, 8.0.0, etc depending on your server --></version>
<scope>provided</scope>
</dependency>
Make sure web.xml version is right
Further you should also make sure that your web.xml is declared conform at least Servlet 2.4 and thus not as Servlet 2.3 or older. Otherwise EL expressions inside JSTL tags would in turn fail to work. Pick the highest version matching your target container and make sure that you don't have a <!DOCTYPE> anywhere in your web.xml as that would otherwise still trigger Servlet 2.3 modus. Here's a Servlet 6.0 (Tomcat 10.1.x) compatible example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd"
version="6.0">
<!-- Config here. -->
</web-app>
And here's a Servlet 5.0 (Tomcat 10.0.x) compatible example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
version="5.0">
<!-- Config here. -->
</web-app>
And here's a Servlet 4.0 (Tomcat 9) compatible example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<!-- Config here. -->
</web-app>
See also:
JSTL core taglib documentation (for the right taglib URIs)
EL expressions not evaluated in JSP
How to configure pom.xml for Tomcat 10+ or Tomcat 9-
#BalusC is completely right, but If you still encounter this exception, it means that something you have done wrong. The most important information you will find is on the SO JSTL Tag Info page.
Basically this is a summary of what you need to do to deal with this exception.
Check the servlet version in web.xml: <web-app version="2.5">
Check if JSTL version is supported for this servlet version: Servlet version 2.5 uses JSTL 1.2 or Servlet version 2.4 uses JSTL 1.1
Your servlet container must have the appropriate library, or you must include it manually in your application. For example: JSTL 1.2 requires jstl-1.2.jar
What to do with Tomcat 5 or 6:
You need to include appropriate jar(s) into your WEB-INF/lib directory (it will work only for your application) or to the tomcat/lib (will work globally for all applications).
The last thing is a taglib in your jsp files. For JSTL 1.2 correct one is this:
<%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
I found another reason for this type of error: in my case, someone set the conf/catalina.properties setting tomcat.util.scan.StandardJarScanFilter.jarsToSkip property to * to avoid log warning messages, thereby skipping the necessary scan by Tomcat. Changing this back to the Tomcat default and adding an appropriate list of jars to skip (not including jstl-1.2 or spring-webmvc) solved the problem.
Download jstl-1.2.jar
Add this directive to your page: <%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
Paste the JAR file in your WEB-INF/lib folder. This should work. (It
worked for me.)
jstl-1.2.jar --> <%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
jstl-1.1.jar --> <%# taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
also please check for the dependency jars that you have added javax.servlet.jar and javax.servlet.jsp.jstl-1.2.1.jar or not in your WEB-INF/lib folder. In my case these two solved the issue.
Add the jstl-1.2.jar into the tomcat/lib folder.
With this, your dependency error will be fixed again.
I just wanted to add the fix I found for this issue. I'm not sure why this worked. I had the correct version of jstl (1.2) and also the correct version of servlet-api (2.5)
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
I also had the correct address in my page as suggested in this thread, which is
<%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
What fixed this issue for me was removing the scope tag from my xml file in the pom for my jstl 1.2 dependency. Again not sure why that fixed it but just in case someone is doing the spring with JPA and Hibernate tutorial on pluralsight and has their pom setup this way, try removing the scope tag and see if that fixes it. Like I said it worked for me.
An answer for the year 2021
The question is still very popular, but all the answers are seriously outdated. All Java EE components were split off into various Jakarta projects and JSTL is no different. So here are the correct Maven dependencies as of today:
<dependency>
<groupId>jakarta.servlet.jsp.jstl</groupId>
<artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
<version>1.2.7</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>1.2.6</version>
</dependency>
Yes, the versions and groupIds do not match, but that's a quirk of the project's current state.
The most possible solutions for 2022
1 - Missing Libarires: download the library jstl/1.2 and Java Servlet API » 4.0.1
2 - Add these libraries to your project and also into the tomcat/lib folder.
3 - Add: <%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> first line of the page.
4 - if you are using maven add the following into pom.xml file :
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
I have mentioned that the Maven dependency in the pom.xml is wrong. It should be
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
Just had similar problem in Eclipse
fixed with:
rightclick on project->Properties->Deployment Assembly->add Maven Dependencies
something kicked it out before,
while I was editing my pom.xml
I had all needed jar files, taglib uri and web.xml was ok
I had disabled MAVEN and Spring tools completely. And I had to add the following jar's for making my environment work right.
spring-aop-4.0.3.RELEASE.jar
spring-beans-4.0.3.RELEASE.jar (tough to find this fix, other org.springframework<3.versions> just did not work.
spring-context-4.0.3.RELEASE.jar
spring-core-4.0.3.RELEASE.jar
spring-expression-4.0.3.RELEASE.jar
spring-web-4.0.3.RELEASE.jar
spring-webmvc-4.0.3.RELEASE.jar
jstl-1.2.jar
The worst of all was jstl-api-1.2.jar and javax-servlet.jsp.jst-api-1.2.1.jar. They just did not work.
jstl-1.2.jar worked well.
If you use Spring boot, consider to remove server.tomcat.additional-tld-skip-patterns=*.jar from Application.properties if there is any
All of the answers in this question helped me but I thought I'd add some additional information for posterity.
It turned out that I had a test dependency on gwt-test-utils which brought in the gwt-dev package. Unfortunately gwt-dev contains a full copy of Jetty, JSP, JSTL, etc. which was ahead of the proper packages on the classpath. So even though I had proper dependencies on the JSTL 1.2 it would loading the 1.0 version internal to gwt-dev. Grumble.
The solution for me was to not run with test scope so I don't pick up the gwt-test-utils package at runtime. Removing the gwt-dev package from the classpath in some other manner would also have fixed the problem.
If using Tomcat 10:
Download
jakarta.servlet.jsp.jstl-2.0.0.jar
jakarta.servlet.jsp.jstl-api-2.0.0.jar
Place in /WEB-INF/lib folder.
Don't forget to restart Tomcat!
This workedfor me
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
I had the same issue , I am using eclipse, just in case others experience the same issue:
In eclipse double click the tomcat server,
stop the server
untick the "server modules without publishing"
start the server.
Resolved same problem in Netbeans 12.3 and Tomcat 9.0:
1.Write in pom.xml:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId><version>1.2</version>
</dependency>
2.Add jstl-1.2.jar in project.
3.Install manually artifact(Choose jstl-1.2.jar - downloaded from the Internet )
2023 version
Nothing else worked for me except adding the below to pom.xml:
PS: I do realize that version 2.0.0 of jakarta.servlet.jsp.jstl contains some vulnerability, please use caution.
<!-- https://mvnrepository.com/artifact/jakarta.servlet.jsp.jstl/jakarta.servlet.jsp.jstl-api -->
<dependency>
<groupId>jakarta.servlet.jsp.jstl</groupId>
<artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
<version>2.0.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.glassfish.web/jakarta.servlet.jsp.jstl -->
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>2.0.0</version>
</dependency>
Resolved similar problem in IBM RAD 7.5 by selecting:
Projects properties
Project Facets
JSTL check-box

java.lang.ClassNotFoundException while uploading an encrypted PDF file

I am getting the following exception when I am trying to upload a password protected PDF file in my application:
How to solve this problem? I tried different itext versions but still the same error. Is there anyway I can solve this issue? Thanks.
java.lang.ClassNotFoundException: org.bouncycastle.asn1.DEREncodable
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at com.itextpdf.text.pdf.PdfEncryption.<init>(PdfEncryption.java:138)
at com.itextpdf.text.pdf.PdfReader.readDecryptedDocObj(PdfReader.java:762)
at com.itextpdf.text.pdf.PdfReader.readDocObj(PdfReader.java:1133)
at com.itextpdf.text.pdf.PdfReader.readPdf(PdfReader.java:511)
at com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:171)
at com.itextpdf.text.pdf.PdfReader.<init>(PdfReader.java:160)
at com.quepio.web.controller.TutoContentController.processChapterContent(TutoContentController.java:2582)
at com.quepio.web.controller.TutoContentController.saveOrUpdateContent(TutoContentController.java:1694)
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.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:440)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:428)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:933)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:867)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:855)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.quepio.web.TwoFactorAuthenticationFilter.doFilterInternal(TwoFactorAuthenticationFilter.java:54)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.quepio.web.FirstLoginFilter.doFilterInternal(FirstLoginFilter.java:108)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
I am using the following jars.
itext: 5.3.2
bcprov-jdk15on: 1.47
bcmail-jdk15on: 1.47
You have to look at the POM file that ships with iText: pom.xml
You'll discover that the current version of iText is 5.5.7:
<artifactId>itextpdf</artifactId>
<packaging>jar</packaging>
<name>iText, a Free Java-PDF library</name>
<version>5.5.7</version>
<description>iText, a free Java-PDF library</description>
Now scroll down to the dependencies and look for BouncyCastle:
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
<version>1.49</version>
<type>jar</type>
<scope>compile</scope>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>1.49</version>
<type>jar</type>
<scope>compile</scope>
<optional>true</optional>
</dependency>
As you can see, the BC version that works with 5.5.7 is BC 1.49.
The POM files are provided, so that developers don't have to resort to "trial and error." If you are familiar with Maven, just use the POM file and you don't have to worry about which BouncyCastle version to use. All the dependencies will be downloaded automatically through Maven.
Of course: you have to make sure that BC is also available in the CLASSPATH of your server. You also need to take special care to make sure that you have only one version of BouncyCastle. A ClassNotFoundException doesn't always mean that the class isn't present. It can also mean that there's an ambiguity. If you have a class named DEREncodable in one version of BC that is in your CLASSPATH and a class with the same name in another version of BC that is in your class path, the JVM won't know which class to use and will also throw a ClassNotFoundException.

Cannot integrate Jersey 2.16 into Tomcat 8.0.12 using servlet 3 plugability feature

In new project I decided to use latest Jersey (2.16) with Tomcat 8, but integration scheme described in documentation causes Tomcat to throw NPE:
java.lang.NullPointerException
org.apache.catalina.loader.WebappClassLoader.binaryNameToPath(WebappClassLoader.java:2503)
org.apache.catalina.loader.WebappClassLoader.findLoadedClass0(WebappClassLoader.java:2708)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1215)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1173)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:534)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1081)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:277)
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2381)
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2370)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:744)
Here is my web.xml
<servlet>
<servlet-name>bla.bla.core.jersey.config.JerseyServerConfig</servlet-name>
</servlet>
<servlet-mapping>
<servlet-name>bla.bla.core.jersey.config.JerseyServerConfig</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
Here is the listing of JerseyServerConfig:
package ru.huawei.rnd.bulksms.core.jersey.config;
import org.glassfish.jersey.server.ResourceConfig;
import ru.huawei.rnd.bulksms.core.jersey.constants.FILTERS_AND_INTERCEPTORS;
import ru.huawei.rnd.bulksms.core.jersey.constants.JERSEY_FEATURES;
public class JerseyServerConfig extends ResourceConfig {
public JerseyServerConfig() {
register(JERSEY_FEATURES.FORM_PROVIDER);
register(JERSEY_FEATURES.MULTIPART);
register(FILTERS_AND_INTERCEPTORS.USER_GZIP_FILTER);
register(FILTERS_AND_INTERCEPTORS.GZIP_ENCODER);
packages("bla.bla.rest");
}
}
So, it looks correct according to scheme described here in "4.7.2.2. Deployment using web.xml descriptor". But when I try to call any JAX-RS resource, bang, Tomcat throws NPE. And it seems it's because of missing servlet-class element in web.xml.
It appears you are using the jersey-container-servlet-core dependency. This will work in situations when we declare the servlet container. But when we want to take advantage of the features where Jersey is automatically loaded, we need the jersey-container-servlet
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey.version}</version>
</dependency>
This artifact has the JerseyServletContainerInitializer, which implements SerlvetContainerInitializer (for Servlet 3.x deployments).
Tested and got same results as you when using the former artifact, and works fine using the latter.

HTTP Status 500 - The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved [duplicate]

I don't know what I've done incorrectly, but I can't include JSTL. I have jstl-1.2.jar, but unfortunately I get exception:
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:315)
at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:148)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:429)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1439)
at org.apache.jasper.compiler.Parser.parse(Parser.java:137)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:170)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:332)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:312)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:299)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:586)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
I have:
pom.xml
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
web.xml
<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_2_5.xsd"
version="2.5">
index.jsp
<%# taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
<html>
<head></head>
<body></body>
</html>
org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
That URI is for JSTL 1.0, but you're actually using JSTL 1.2 which uses URIs with an additional /jsp path (because JSTL, who invented EL expressions, was since version 1.1 integrated as part of JSP 2.0 (released way back in 2001!) in order to share/reuse the EL logic in plain JSP too).
So, fix the taglib URI accordingly based on JSTL 1.2 documentation:
<%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Further you need to make absolutely sure that you do not throw multiple different versioned JSTL JAR files together into the runtime classpath. This is a pretty common mistake among Tomcat users. The problem with Tomcat is that it does not offer JSTL out the box and thus you have to manually install it. This is not necessary in normal Jakarta EE servers. See also What exactly is Java EE?
In your specific case, your pom.xml basically tells you that you have jstl-1.2.jar and standard-1.1.2.jar together. This is wrong. You're basically mixing JSTL 1.2 API+impl from Oracle with JSTL 1.1 impl from Apache. You should stick to only one JSTL implementation and the API version must match the impl version.
Installing JSTL on Tomcat 10.1.x
In case you're already on Tomcat 10.1.x (the second Jakartified version, with jakarta.* package instead of javax.* package, but the first version with the updated jakarta.tags.* namespace URNs instead of http://java.sun.com/jsp/jstl/* namespace URLs), use JSTL 3.0 via this sole dependency using the default Maven scope of compile (because Tomcat doesn't provide it out the box!):
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>3.0.1</version>
</dependency>
Note that the API dependency is already transitively included via this impl dependency, so you do not need to explicitly declare it.
Non-Maven users can achieve the same by dropping the following two physical files in /WEB-INF/lib folder of the web application project (do absolutely not drop standard*.jar or any loose .tld files in there! remove them if necessary).
jakarta.servlet.jsp.jstl-3.0.1.jar (this is the JSTL 3.0.1 impl of EE4J)
jakarta.servlet.jsp.jstl-api-3.0.0.jar (this is the JSTL 3.0 API)
As said, the namespace URIs have been changed to become URNs instead of URLs. JSTL core is since JSTL version 3.0 available via an easier to remember namespace URI in URN format:
<%# taglib prefix="c" uri="jakarta.tags.core" %>
See also JSTL 3.0 documentation.
Installing JSTL on Tomcat 10.0.x
In case you're on Tomcat 10.0.x (the first Jakartified version, with jakarta.* package instead of javax.* package), use JSTL 2.0 via this sole dependency using the default Maven scope of compile (because Tomcat doesn't provide it out the box!):
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>2.0.0</version>
</dependency>
Note that the API dependency is already transitively included via this impl dependency, so you do not need to explicitly declare it.
Non-Maven users can achieve the same by dropping the following two physical files in /WEB-INF/lib folder of the web application project (do absolutely not drop standard*.jar or any loose .tld files in there! remove them if necessary).
jakarta.servlet.jsp.jstl-2.0.0.jar (this is the JSTL 2.0 impl of EE4J)
jakarta.servlet.jsp.jstl-api-2.0.0.jar (this is the JSTL 2.0 API)
Installing JSTL on Tomcat 9-
In case you're not on Tomcat 10 yet, but still on Tomcat 9 or older, use JSTL 1.2 via this sole dependency (this is compatible with Tomcat 9 / 8 / 7 / 6 / 5 but not older) using the default Maven scope of compile (because Tomcat doesn't provide it out the box!):
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>1.2.6</version>
</dependency>
Note that the API dependency is already transitively included via this impl dependency, so you do not need to explicitly declare it.
Non-Maven users can achieve the same by dropping the following two physical files in /WEB-INF/lib folder of the web application project (do absolutely not drop standard*.jar or any loose .tld files in there! remove them if necessary).
jakarta.servlet.jsp.jstl-1.2.6.jar (this is the JSTL 1.2 impl of EE4J)
jakarta.servlet.jsp.jstl-api-1.2.7.jar (this is the JSTL 1.2 API)
Installing JSTL on normal JEE server
In case you're actually using a normal Jakarta EE server such as WildFly, Payara, TomEE, GlassFish, WebSphere, OpenLiberty, WebLogic, etc instead of a barebones servletcontainer such as Tomcat, Jetty, Undertow, etc, then you do not need to explicitly install JSTL at all. Normal Jakarta EE servers already provide JSTL out the box. In other words, you don't need to add JSTL to pom.xml nor to drop any JAR/TLD files in webapp. Solely the provided scoped Jakarta EE coordinate is sufficient:
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version><!-- 10.0.0, 9.1.0, 9.0.0, 8.0.0, etc depending on your server --></version>
<scope>provided</scope>
</dependency>
Make sure web.xml version is right
Further you should also make sure that your web.xml is declared conform at least Servlet 2.4 and thus not as Servlet 2.3 or older. Otherwise EL expressions inside JSTL tags would in turn fail to work. Pick the highest version matching your target container and make sure that you don't have a <!DOCTYPE> anywhere in your web.xml as that would otherwise still trigger Servlet 2.3 modus. Here's a Servlet 6.0 (Tomcat 10.1.x) compatible example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd"
version="6.0">
<!-- Config here. -->
</web-app>
And here's a Servlet 5.0 (Tomcat 10.0.x) compatible example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
version="5.0">
<!-- Config here. -->
</web-app>
And here's a Servlet 4.0 (Tomcat 9) compatible example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<!-- Config here. -->
</web-app>
See also:
JSTL core taglib documentation (for the right taglib URIs)
EL expressions not evaluated in JSP
How to configure pom.xml for Tomcat 10+ or Tomcat 9-
#BalusC is completely right, but If you still encounter this exception, it means that something you have done wrong. The most important information you will find is on the SO JSTL Tag Info page.
Basically this is a summary of what you need to do to deal with this exception.
Check the servlet version in web.xml: <web-app version="2.5">
Check if JSTL version is supported for this servlet version: Servlet version 2.5 uses JSTL 1.2 or Servlet version 2.4 uses JSTL 1.1
Your servlet container must have the appropriate library, or you must include it manually in your application. For example: JSTL 1.2 requires jstl-1.2.jar
What to do with Tomcat 5 or 6:
You need to include appropriate jar(s) into your WEB-INF/lib directory (it will work only for your application) or to the tomcat/lib (will work globally for all applications).
The last thing is a taglib in your jsp files. For JSTL 1.2 correct one is this:
<%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
I found another reason for this type of error: in my case, someone set the conf/catalina.properties setting tomcat.util.scan.StandardJarScanFilter.jarsToSkip property to * to avoid log warning messages, thereby skipping the necessary scan by Tomcat. Changing this back to the Tomcat default and adding an appropriate list of jars to skip (not including jstl-1.2 or spring-webmvc) solved the problem.
Download jstl-1.2.jar
Add this directive to your page: <%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
Paste the JAR file in your WEB-INF/lib folder. This should work. (It
worked for me.)
jstl-1.2.jar --> <%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
jstl-1.1.jar --> <%# taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
also please check for the dependency jars that you have added javax.servlet.jar and javax.servlet.jsp.jstl-1.2.1.jar or not in your WEB-INF/lib folder. In my case these two solved the issue.
Add the jstl-1.2.jar into the tomcat/lib folder.
With this, your dependency error will be fixed again.
I just wanted to add the fix I found for this issue. I'm not sure why this worked. I had the correct version of jstl (1.2) and also the correct version of servlet-api (2.5)
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
I also had the correct address in my page as suggested in this thread, which is
<%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
What fixed this issue for me was removing the scope tag from my xml file in the pom for my jstl 1.2 dependency. Again not sure why that fixed it but just in case someone is doing the spring with JPA and Hibernate tutorial on pluralsight and has their pom setup this way, try removing the scope tag and see if that fixes it. Like I said it worked for me.
An answer for the year 2021
The question is still very popular, but all the answers are seriously outdated. All Java EE components were split off into various Jakarta projects and JSTL is no different. So here are the correct Maven dependencies as of today:
<dependency>
<groupId>jakarta.servlet.jsp.jstl</groupId>
<artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
<version>1.2.7</version>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>1.2.6</version>
</dependency>
Yes, the versions and groupIds do not match, but that's a quirk of the project's current state.
The most possible solutions for 2022
1 - Missing Libarires: download the library jstl/1.2 and Java Servlet API » 4.0.1
2 - Add these libraries to your project and also into the tomcat/lib folder.
3 - Add: <%# taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> first line of the page.
4 - if you are using maven add the following into pom.xml file :
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
I have mentioned that the Maven dependency in the pom.xml is wrong. It should be
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
Just had similar problem in Eclipse
fixed with:
rightclick on project->Properties->Deployment Assembly->add Maven Dependencies
something kicked it out before,
while I was editing my pom.xml
I had all needed jar files, taglib uri and web.xml was ok
I had disabled MAVEN and Spring tools completely. And I had to add the following jar's for making my environment work right.
spring-aop-4.0.3.RELEASE.jar
spring-beans-4.0.3.RELEASE.jar (tough to find this fix, other org.springframework<3.versions> just did not work.
spring-context-4.0.3.RELEASE.jar
spring-core-4.0.3.RELEASE.jar
spring-expression-4.0.3.RELEASE.jar
spring-web-4.0.3.RELEASE.jar
spring-webmvc-4.0.3.RELEASE.jar
jstl-1.2.jar
The worst of all was jstl-api-1.2.jar and javax-servlet.jsp.jst-api-1.2.1.jar. They just did not work.
jstl-1.2.jar worked well.
If you use Spring boot, consider to remove server.tomcat.additional-tld-skip-patterns=*.jar from Application.properties if there is any
All of the answers in this question helped me but I thought I'd add some additional information for posterity.
It turned out that I had a test dependency on gwt-test-utils which brought in the gwt-dev package. Unfortunately gwt-dev contains a full copy of Jetty, JSP, JSTL, etc. which was ahead of the proper packages on the classpath. So even though I had proper dependencies on the JSTL 1.2 it would loading the 1.0 version internal to gwt-dev. Grumble.
The solution for me was to not run with test scope so I don't pick up the gwt-test-utils package at runtime. Removing the gwt-dev package from the classpath in some other manner would also have fixed the problem.
If using Tomcat 10:
Download
jakarta.servlet.jsp.jstl-2.0.0.jar
jakarta.servlet.jsp.jstl-api-2.0.0.jar
Place in /WEB-INF/lib folder.
Don't forget to restart Tomcat!
This workedfor me
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
I had the same issue , I am using eclipse, just in case others experience the same issue:
In eclipse double click the tomcat server,
stop the server
untick the "server modules without publishing"
start the server.
Resolved same problem in Netbeans 12.3 and Tomcat 9.0:
1.Write in pom.xml:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId><version>1.2</version>
</dependency>
2.Add jstl-1.2.jar in project.
3.Install manually artifact(Choose jstl-1.2.jar - downloaded from the Internet )
2023 version
Nothing else worked for me except adding the below to pom.xml:
PS: I do realize that version 2.0.0 of jakarta.servlet.jsp.jstl contains some vulnerability, please use caution.
<!-- https://mvnrepository.com/artifact/jakarta.servlet.jsp.jstl/jakarta.servlet.jsp.jstl-api -->
<dependency>
<groupId>jakarta.servlet.jsp.jstl</groupId>
<artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
<version>2.0.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.glassfish.web/jakarta.servlet.jsp.jstl -->
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>2.0.0</version>
</dependency>
Resolved similar problem in IBM RAD 7.5 by selecting:
Projects properties
Project Facets
JSTL check-box

Seam Export Datatable in Excel format

I am trying to export a richdata table to excel using seam, and following
http://docs.jboss.org/seam/2.1.0.GA/reference/en-US/html/excel.html#excel.intro
It instructs " To include the Microsoft® Excel® spreadsheet application support in your application, included jboss-seam-excel.jar in your WEB-INF/libdirectory along with the jxl.jar JAR file."
I found below two dependencies online for the jars..
War pom.xml
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-excel</artifactId>
<version>2.2.0.GA</version>
</dependency>
<dependency>
<groupId>net.sourceforge.jexcelapi</groupId>
<artifactId>jxl</artifactId>
<version>2.6.12</version>
</dependency>
web.xml
<servlet>
<servlet-name>Document Store Servlet</servlet-name>
<servlet-class>org.jboss.seam.document.DocumentStoreServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Document Store Servlet</servlet-name>
<url-pattern>*.xls</url-pattern>
</servlet-mapping>
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>seam-excel</param-value>
</context-param>
Components.xml
<components
xmlns:excel="http://jboss.com/products/seam/excel"
xmlns:document="http://jboss.com/products/seam/document"
http://jboss.com/products/seam/excel http://jboss.com/products/seam/excel-2.1.xsd
http://jboss.com/products/seam/document http://jboss.com/products/seam/document-2.1.xsd">
<excel:document-store use-extensions="true"/>
<document:document-store use-extensions="true"/>
</components>
Earlier I was also having the below in components.xml
<excel:excelFactory>
   <property name="implementations">
      <key>myExcelExporter</key>
      <value>my.excel.exporter.ExcelExport</value>
   </property>
</excel:excelFactory>
This was causing deployment exception, also no one mentioned it in their code, I got rid of this and the deployment exception.
jboss-seam-excel-2.1.2.jar and jxl-2.6.12.jar are deployed under WEB-INF/lib
But, I did not find.. org.jboss.seam.excel.DocumentStoreServlet anywhere, so using org.jboss.seam.document.DocumentStoreServlet in web.xml
However, I am getting property not found exception right at the time of login, below is the complete error stack trace.. loginAction.stationID has nothing to do with my changes…
17:04:24,934 |WARNING| [lifecycle:81] /login.xhtml #52,138 value="#{loginAction.stationID}": Target Unreachable, identifier 'loginAction' resolved to null ||||
javax.el.PropertyNotFoundException: /login.xhtml #52,138 value="#{loginAction.stationID}": Target Unreachable, identifier 'loginAction' resolved to null
at com.sun.facelets.el.TagValueExpression.getType(TagValueExpression.java:62)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:92)
at javax.faces.component.UIInput.getConvertedValue(UIInput.java:942)
at javax.faces.component.UIInput.validate(UIInput.java:868)
at javax.faces.component.UIInput.executeValidate(UIInput.java:1072)
at javax.faces.component.UIInput.processValidators(UIInput.java:672)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1058)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1058)
at javax.faces.component.UIForm.processValidators(UIForm.java:235)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1058)
at org.ajax4jsf.component.AjaxViewRoot$3.invokeContextCallback(AjaxViewRoot.java:439)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:238)
at org.ajax4jsf.component.AjaxViewRoot.processValidators(AjaxViewRoot.java:455)
at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:510)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.billmelater.csa.filters.NewSessionFilter.doFilter(NewSessionFilter.java:89)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.billmelater.csa.filters.Perf4JFilter.doFilter(Perf4JFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:680)
17:04:24,942 |SEVERE| [lifecycle:104] JSF1054: (Phase ID: PROCESS_VALIDATIONS 3, View ID: /login.xhtml) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl#42a46d79] ||||
Deployment Exception : Could not create Component: org.jboss.seam.excel.excelFactory
**Could not create Component: org.jboss.seam.excel.excelFactory**
PropertyNotFoundException happens when I add seam excel dependency.
I saw this in the dependency tree..mvn dependency:tree and found this..
[INFO] +- org.jboss.seam:jboss-seam-excel:jar:2.2.0.GA:compile
[INFO] |  \- org.jboss.seam:jboss-seam:ejb:2.2.0.GA:compile
[INFO] |     +- xstream:xstream:jar:1.1.3:compile
[INFO] |     +- xpp3:xpp3_min:jar:1.1.3.4.O:compile
[INFO] |     \- org.jboss.el:jboss-el:jar:1.0_02.CR4:compile
[INFO] +- net.sourceforge.jexcelapi:jxl:jar:2.6.12:compile`
The excel jar comes with jboss-seam ejb and jboss-el etc.. I think org.jboss.el:jboss-el is colliding with the one in my project already.. also.. jboss-seam:ejb:2.2.0.GA.., tried putting the below exclusion in maven.. but dint work either..
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-excel</artifactId>
<version>2.2.0.GA</version>
<exclusions>
<exclusion>
<groupId>ejb</groupId>
<artifactId>ejb</artifactId>
</exclusion>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Which JBoss version are you using? I'm assuming JBoss 5
Check this reference:
https://community.jboss.org/thread/186791
This is for an older version, but also helpful:
https://community.jboss.org/thread/184757
I cut and pasted the code below since I don't have access to code right now, but if it's not right it will be close.
You'll need a reference in web.xml
<servlet-name>Document Store Servlet Excel</servlet-name>
<servlet-class>org.jboss.seam.excel.DocumentStoreServlet</servlet-class>
<servlet-mapping>
<servlet-name>Document Store Servlet Excel</servlet-name>
<url-pattern>*.xls</url-pattern>
</servlet-mapping>
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>seam-excel</param-value>
</context-param>
jboss-web.xml
<jboss-web>
<class-loading java2ClassLoadingCompliance="false">
<loader-repository>
seam.jboss.org:loader=seam-excel
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
and components.xml
<components xmlns:excel="http://jboss.com/products/seam/excel"
xmlns:document="http://jboss.com/products/seam/document"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.com/products/seam/document http://jboss.com/products/seam/document-2.1.xsd
http://jboss.com/products/seam/excel http://jboss.com/products/seam/excel-2.1.xsd">
<document:document-store use-extensions="true"></document:document-store>
</components>
As I thought, I was not excluding dependencies properly, and the were colliding with other dependencies.
Here is the right version...
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-excel</artifactId>
<version>2.2.0.GA</version>
<exclusions>
<exclusion>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
</exclusion>
<exclusion>
<groupId>org.jboss.el</groupId>
<artifactId>jboss-el</artifactId>
</exclusion>
</exclusions>
</dependency>
Hope this helps others in future. I must say this feature is very poorly documented and one must go to several forums to know what exactly is needed. I will stop working on the POI approach to export excel :).

Categories