Tomcat 7 and JSTL

Question

I wrote a web application with Eclipse Tomcat, and it works on my local Tomcat 7, when I tried to publish it on the Internet on Tomcat 7, I had the following error:

SEVERE: Servlet.service () for the servlet [obliquid.servlet.Index] in the context of the path [/ cp] an exception was thrown [Absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved either in web.xml or jar files with this application]

Tomcat 7 has "version versions: Servlet 3.0, JSP 2.2, EL 2.2," so is JSTL not included?

When I tried to load standard.jar and jstl.jar, I had the following error:

org.apache.jasper.JasperException: /jsp/index.jsp (row: 3, column: 62) Unable to read TLD "META-INF / c.tld" from the JAR file "jndi: / localhost / cp / WEB-INF / lib / standard.jar ": org.apache.jasper.JasperException: could not load or create an instance of the TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV

I did some search queries, but I couldn’t figure it out, some said that this could be caused by conflicting versions of jars. Maybe I should not include these banks and use another JSTL url? Mine for JSTL 1.1 I think there is a new URL for JSTL 1.2?

What should I do to solve the problem and run this application?

Answer 1

Tomcat never included JSTL.

You should put jstl and standard banks in WEB-INF/lib (you did this) and make sure that you have permissions to read them (chmod)

Your URI is correct and it should work (works here)

Answer 2

I struggled with this for several hours. Here is the complete solution.

• I am using Tomcat 7, which is a server compatible with Servlet 3.0.

• If you want to use the Servlet 3.0 specification, 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 are 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 using these lines, especially the exception part. What happens, the JSTL 2.1 Jars actually pulls the wrong version of the Servlet specification - 2.5. If you do not stop this, you will find yourself in a whole world of pain. Special thanks to Sir. Murray Todd Williams for these ideas .

• Finally, in case Maven cannot find these JARS, you can make Eclipse happy by including three JARS in your project and doing the usual Project -> Properties -> Java Build Path and including them this way - although Maven should take care of this.

   javax.servlet-api-3.0.1.jar javax.servlet.jsp.jstl-1.2.1.jar javax.servlet.jsp.jstl-api-1.2.1.jar 

• Note! This exact configuration only applies if you use a magic combination:

  • Servlet-compatible application server such as Tomcat 7

  • Your web.xml has the correct namespace for the Servlet 3.0 specification

  • You have three JARS and other JSTL or Servlet JARS in your class path.

• Make sure that you do not place copies of these JARs in the WEB-INF / lib directory, because in this case they will be sent to the server, which will cause LinkageErrors.

• In your JSP you need to have this PRECISE string formatted exactly the same as I have, otherwise Eclipse will whine that it does not recognize c: blah tags:

   <%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> 

• What a remote PITA! This is much harder to implement than any other version of JSTL. This is the only example that in later iterations, something becomes much more complicated than simpler.

Answer 3

Your uri is correct for JSTL 1.2. You need to do two things:

Modify web.xml to use the latest version of the web application.

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 banks:

• JSTL-api.jar
• JSTL-impl.jar

Use these instead of standard.jar and jstl.jar , which were for the previous version.

Let us know how it works for you.

Answer 4

For working with apache tomcat 7, adding this data to your POM is probably appropriate. These jars do not reference javax.servlet jars, such as glass fish, so there is no need for exceptions.

 <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> 

Answer 5

For Tomcat for JSTL 1.1.2 there is a simpler solution for dependencies:

 <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> 

For details, see here for personal use.

REM: More on request, you need to enable JSTL dependencies to make them available for Tomcat. However, version 1.2 is not really needed, since version 1.1.2 (provided by Apache, such as Tomcat) also does the job. His only requirement is Servlet 2.4 and JSP 2.2, while the OP mentions Servlet 3.0 and JSP 2.0, which is good enough.

Answer 6

There are two answers here that are mostly correct regarding how to solve this problem when using Maven to solve this problem. However, both of them are not 100% full.

Using exceptions for each @ Answer to Hunter's question

This answer works. However, there will still be log messages from Tomcat regarding duplicate TLD definitions. This is because both jstl and jstl-impl artifacts include TLD definitions. To remove these posts, I think it's best to configure Maven:

 <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 jstl api classes with the necessary exceptions to avoid the problems explained in the rest of this answer.

Using newer versions of POM for @George answer

It took me a while to figure this out, but there are newer versions of the JSTL pom. This is really confusing because these new packages use similar, but slightly different naming conventions. These new versions note the dependencies of javax.servlet, javax.jsp, etc. As a provided area, so they need not be excluded. Version 1.2.1 depends on version 1.2.1 of jstl-api. And so it will work the same as above:

 <dependency> <groupId>org.glassfish.web</groupId> <artifactId>javax.servlet.jsp.jstl</artifactId> <version>1.2.1</version> <scope>runtime</scope> </dependency> 

This is slightly different from George's answer because I changed the scope to run time. George indicated the scope. With the provided area, the banks must be manually copied to the Tomcat lib directory, or some other dependency should have included the necessary implementation.

However, I could not find version 1.2.1 for implication in maven central, jboss repo or any other repositories. I ended up around and finally just used the local file based repository to store the jar. Dependency and jar are described here:

• http://mvnrepository.com/artifact/org.glassfish.web/javax.servlet.jsp.jstl/1.2.1

Answer 7

None of them worked for me, I just created a project without using Maven and adding JAR files directly.

Answer 8

I suffered from an error: SEVERE: Servlet.service () for the servlet [obliquid.servlet.Index] in the context of the path [/ cp] threw an exception [Absolute uri: http://java.sun.com/jsp/jstl/core not may be allowed in the web.xml file or jar files deployed with this application] on Tomcat 7

Solution: copy jars jstl-1.2.jar and javax.servlet.jsp.jstl-api-1.2.1.jar directly into the Tomcat library library. Update Tomcat Library in Eclipse again.

Answer 9

The following problems in pom.xml seem to fix the problem:

 <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> 

It was a strange combination - two different groups, but it works :). I expected to see the same group id for both cans. I managed to redo Tomcat 7 without any problems.

Also, if you see the Unkown Tag