wake-up-neo.com

Wie installiere ich JSTL? Der absolute Uri: http://Java.Sun.com/jstl/core kann nicht aufgelöst werden

Ich weiß nicht, was ich falsch gemacht habe, aber ich kann JSTL nicht einbeziehen. Ich habe jstl-1.2.jar, aber leider bekomme ich eine Ausnahme: 

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)

Ich habe:

  • 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>
    
111
smas

org.Apache.jasper.JasperException: Der absolute Uri: http://Java.Sun.com/jstl/core kann weder in web.xml noch in den mit dieser Anwendung bereitgestellten JAR-Dateien aufgelöst werden

Diese URI ist für JSTL 1.0, aber Sie verwenden tatsächlich JSTL 1.2, das URIs mit einem zusätzlichen /jsp-Pfad verwendet (da JSTL, der EL-Ausdrücke erfunden hat, seit Version 1.1 als Teil von JSP integriert wurde, um die EL-Logik gemeinsam zu nutzen/wiederzuverwenden in einfacher JSP auch).

Korrigieren Sie also den Taglib-URI entsprechend:

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

Darüber hinaus spezifiziert Ihr POM auch die Implementierung von Apaches JSTL 1.1 über taglibs:standard. Dies ist unnötig und sogar gefährlich, wenn Sie bereits JSTL 1.2 API + über javax.servlet:jstl eingebunden haben, da sich 1.1 und 1.2 offensichtlich in Konflikt miteinander befinden. Nur only Die folgende JSTL 1.2-Abhängigkeit sollte dies tun, um JSTL in Ihrer Tomcat-zielgerichteten Webanwendung zu installieren (setzen Sie not den <scope> auf provided, da Tomcat es nicht standardmäßig zur Verfügung stellt!). ):

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
</dependency>

Nicht-Maven-Benutzer können dasselbe erreichen, indem sie die einzelne Datei jstl-1.2.jar im Ordner /WEB-INF/lib des Webanwendungsprojekts ablegen (_ not drop standard.jar oder lose .tld-Dateien dort!). ).

Falls Sie tatsächlich einen normalen Java EE-Server wie WildFly, Payara usw. anstelle eines Barebones-Servletcontainers wie Tomcat, Jetty usw. verwenden, müssen Sie JSTL nicht explizit installieren. Auf normalen Java EE-Servern ist JSTL bereits standardmäßig verfügbar. Mit anderen Worten, Sie müssen weder JSTL zu pom.xml hinzufügen noch JAR/TLD-Dateien in webapp ablegen. Lediglich die Java EE-Koordinate mit provided-Bereich reicht aus:

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version><!-- 8.0, 7.0, etc depending on your server --></version>
    <scope>provided</scope>
</dependency>

Außerdem sollten Sie sicherstellen, dass Ihr web.xml für mindestens Servlet 2.4 als konform deklariert ist und daher nicht als Servlet 2.3 oder älter gilt. Andernfalls funktionieren EL-Ausdrücke in JSTL-Tags nicht. Wählen Sie die höchste Version aus, die mit Ihrem Zielcontainer übereinstimmt, und stellen Sie sicher, dass sich an Ihrem <!DOCTYPE> nirgendwo ein web.xml befindet. Hier ist ein mit Servlet 4.0 (Tomcat 9) kompatibles Beispiel:

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

Siehe auch:

159
BalusC

@BalusC hat vollkommen recht, aber wenn Sie immer noch auf diese Ausnahme stoßen, bedeutet dies, dass Sie etwas falsch gemacht haben. Die wichtigsten Informationen finden Sie auf der Seite SO JSTL-Tag-Info

Im Grunde ist dies eine Zusammenfassung dessen, was Sie tun müssen, um mit dieser Ausnahme umzugehen.

  1. Überprüfen Sie die Servlet-Version in web.xml: <web-app version="2.5">

  2. Prüfen Sie, ob die JSTL-Version für diese Servlet-Version unterstützt wird: Servlet-Version 2.5 verwendet JSTL 1.2 oder Servlet-Version 2.4 verwendet JSTL 1.1.

  3. Ihr Servlet-Container muss über die entsprechende Bibliothek verfügen, oder Sie müssen sie manuell in Ihre Anwendung aufnehmen. Zum Beispiel: JSTL 1.2 erfordert jstl-1.2.jar

Was ist mit Tomcat 5 oder 6 zu tun: 

Sie müssen entsprechende JAR (s) in Ihr WEB-INF/lib-Verzeichnis (es funktioniert nur für Ihre Anwendung) oder in Tomcat/lib (wird global für alle Anwendungen funktionieren) enthalten.

Die letzte Sache ist eine Taglib in Ihren JSP-Dateien. Für JSTL 1.2 ist dies richtig:

<%@ taglib prefix="c" uri="http://Java.Sun.com/jsp/jstl/core" %>
34
smas
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" %>

Überprüfen Sie auch, ob die Abhängigkeitsgläser, die Sie javax.servlet.jar und javax.servlet.jsp.jstl-1.2.1.jar hinzugefügt haben, in Ihrem Ordner WEB-INF/lib nicht vorhanden sind. In meinem Fall haben diese beiden das Problem gelöst.

13
streethawk

Ich habe einen anderen Grund für diese Art von Fehler gefunden: In meinem Fall hat jemand die Einstellung Tomcat.util.scan.StandardJarScanFilter.jarsToSkip der Eigenschaft catalina.properties auf * gesetzt, um Protokollwarnmeldungen zu vermeiden, wodurch der erforderliche Scan von Tomcat übersprungen wird. Wenn Sie dies wieder in den Tomcat-Standard zurücksetzen und eine geeignete Liste von zu überspringenden Gläsern hinzufügen (ohne jstl-1.2 oder spring-webmvc), wurde das Problem behoben.

10
resnbl
  1. Jstl-1.2.jar herunterladen
  2. Fügen Sie diese Direktive zu Ihrer Seite hinzu: <%@ taglib uri="http://Java.Sun.com/jsp/jstl/core" prefix="c" %>

  3. Fügen Sie die JAR-Datei in Ihren Ordner WEB-INF/lib ein. Das sollte funktionieren. (Es arbeitete für mich.)

8

Fügen Sie den jstl-1.2.jar in den Tomcat/lib-Ordner ein.

Damit wird Ihr Abhängigkeitsfehler wieder behoben.

6
Hadi Rasouli

Ich habe erwähnt, dass die Maven-Abhängigkeit in der pom.xml falsch ist. Es sollte sein

    <dependency>
        <groupId>jstl</groupId>
        <artifactId>jstl</artifactId>
        <version>1.2</version>
    </dependency>
3
LoBo

Ich hatte MAVEN und Spring Tools komplett deaktiviert. Und ich musste das folgende Glas hinzufügen, damit meine Umgebung richtig funktioniert.

  • spring-aop-4.0.3.RELEASE.jar
  • spring-Beans-4.0.3.RELEASE.jar (schwer zu finden, dieses Update, andere org.springframework <3.versions> hat einfach nicht funktioniert.
  • 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

Am schlimmsten war jstl-api-1.2.jar und javax-servlet.jsp.jst-api-1.2.1.jar. Sie haben einfach nicht gearbeitet. 

`jstl-1.2.jar hat gut funktioniert.

2
Siddharth

Ich wollte nur das Update hinzufügen, das ich für dieses Problem gefunden habe. Ich bin nicht sicher, warum das funktioniert hat. Ich hatte die korrekte Version von JSTL (1.2) und auch die korrekte Version von 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>

Ich hatte auch die richtige Adresse auf meiner Seite, wie in diesem Thread vorgeschlagen 

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

Das Problem, das für mich behoben wurde, bestand darin, das scope-Tag aus meiner xml-Datei im pom für meine jstl 1.2-Abhängigkeit zu entfernen. Nochmals nicht sicher, warum das Problem behoben wurde, aber nur für den Fall, dass jemand den Frühling mit JPA und Hibernate-Tutorial zu Pluralsight durchführt und sein Pom-Setup auf diese Weise eingerichtet hat. Wie ich schon sagte, es hat bei mir funktioniert. 

2
gnattyp

Wenn Sie Spring Boot verwenden, sollten Sie in Betracht ziehen, server.Tomcat.additional-tld-skip-patterns=*.jar aus Application.properties zu entfernen, falls vorhanden

0
Askar

Hatte gerade ein ähnliches Problem in Eclipse Behoben mit:

rightclick on project->Properties->Deployment Assembly->add Maven Dependencies

etwas hat es vorher rausgeschmissen, während ich meine pom.xml editierte

Ich hatte alle JAR-Dateien, Taglib Uri und web.xml war ok

0
w3Charlie

Alle Antworten in dieser Frage haben mir geholfen, aber ich dachte, ich würde zusätzliche Informationen für die Nachwelt hinzufügen.

Es stellte sich heraus, dass ich eine Testabhängigkeit von gwt-test-utils hatte, die das gwt-dev-Paket mitbrachte. Leider enthält gwt-dev eine vollständige Kopie von Jetty, JSP, JSTL usw., die den richtigen Paketen im Klassenpfad voraus waren. Auch wenn ich die richtigen Abhängigkeiten von der JSTL 1.2 hatte, würde ich die Version 1.0 intern in gwt-dev laden. Murren.

Die Lösung für mich war, nicht mit dem Testumfang zu laufen, also nehme ich das gwt-test-utils-Paket nicht zur Laufzeit ab. Das gwt-dev-Paket auf andere Weise aus dem Klassenpfad zu entfernen, hätte das Problem ebenfalls behoben.

0
Gray