Ich weiß nicht, was ich falsch gemacht habe, aber ich kann JSTL nicht einschließen. 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>
Antworten:
Dieser 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 einfache JSP auch).Korrigieren Sie den Taglib-URI entsprechend der JSTL-Dokumentation :
Außerdem müssen Sie unbedingt sicherstellen, dass Sie nicht mehrere verschiedene versionierte JSTL-JAR-Dateien zusammen in den Laufzeitklassenpfad werfen. Dies ist ein ziemlich häufiger Fehler bei Tomcat-Benutzern. Das Problem mit Tomcat ist, dass es JSTL nicht sofort anbietet und Sie es daher manuell installieren müssen. Dies ist auf normalen Java EE-Servern nicht erforderlich. Siehe auch Was genau ist Java EE?
In Ihrem speziellen Fall sagt Ihnen Ihre pom.xml im Grunde, dass Sie jstl-1.2.jar und standard-1.1.2.jar zusammen haben. Das ist falsch. Grundsätzlich mischen Sie JSTL 1.2 API + impl von Oracle mit JSTL 1.1 impl von Apache. Sie müssen entfernen jeder
standard-xxx.jar
. Nur nur dasjstl-1.2.jar
ist ausreichend.Nicht-Maven-Benutzer können dasselbe erreichen, indem sie die physische Datei jstl-1.2.jar im
/WEB-INF/lib
Ordner des Webanwendungsprojekts ablegen ( absolut nicht Fall standard.jar oder lose .tld-Dateien dort ab!). Entfernen Sie sie gegebenenfalls.Wenn Sie tatsächlich einen normalen Java EE-Server wie WildFly, Payara usw. anstelle eines Barebone-Servlet-Containers wie Tomcat, Jetty usw. verwenden, müssen Sie JSTL überhaupt nicht explizit installieren. Normale Java EE-Server bieten JSTL bereits sofort an. Mit anderen Worten, Sie müssen weder JSTL hinzufügen
pom.xml
noch JAR / TLD-Dateien in der Webanwendung löschen. Lediglich dieprovided
Java EE-Koordinate mit Gültigkeitsbereich ist ausreichend:Außerdem sollten Sie sicherstellen, dass Ihr
web.xml
Server mindestens Servlet 2.4 und damit nicht Servlet 2.3 oder älter entspricht. Andernfalls würden EL-Ausdrücke in JSTL-Tags wiederum nicht funktionieren. Wählen Sie die höchste Version aus, die zu Ihrem Zielcontainer passt, und stellen Sie sicher, dass Sie keine<!DOCTYPE>
in Ihrem Computer habenweb.xml
. Hier ist ein mit Servlet 4.0 (Tomcat 9) kompatibles Beispiel:Siehe auch:
web.xml
Beispiele)quelle
standard
taglib. Lesen Sie die Tag-Info-Seite für weitere Details.compile('javax.servlet:jstl:1.2')
@BalusC ist völlig richtig, aber wenn Sie immer noch auf diese Ausnahme stoßen, bedeutet dies, dass Sie etwas falsch gemacht haben. Die wichtigsten Informationen finden Sie in den SO JSTL-Tag- Informationen .
Grundsätzlich ist dies eine Zusammenfassung dessen, was Sie tun müssen, um mit dieser Ausnahme umzugehen.
Überprüfen Sie die Servlet-Version in web.xml:
<web-app version="2.5">
Überprü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
Ihr Servlet-Container muss über die entsprechende Bibliothek verfügen, oder Sie müssen sie manuell in Ihre Anwendung aufnehmen. Beispiel: JSTL 1.2 erfordert jstl-1.2.jar
Was tun mit Tomcat 5 oder 6:
Sie müssen geeignete JARs in Ihr WEB-INF / lib-Verzeichnis aufnehmen (dies funktioniert nur für Ihre Anwendung) oder in das Tomcat / lib (funktioniert global für alle Anwendungen).
Das Letzte ist eine Taglib in Ihren JSP-Dateien. Für JSTL 1.2 ist Folgendes richtig:
quelle
Ich habe einen weiteren Grund für diese Art von Fehler gefunden: In meinem Fall hat jemand die
conf/catalina.properties
Einstellungseigenschafttomcat.util.scan.StandardJarScanFilter.jarsToSkip
so festgelegt*
, dass Protokollwarnmeldungen vermieden werden, wodurch der erforderliche Scan durch Tomcat übersprungen wird. Das Problem wurde behoben, indem dies wieder auf die Tomcat-Standardeinstellung zurückgesetzt und eine entsprechende Liste der zu überspringenden Gläser hinzugefügt wurde (ohne jstl-1.2 oder spring-webmvc).quelle
tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*
in diecatalina.properties
Datei aufgenommen wurde. Arghh!jarsToSkip
Einstellung nicht ändern möchten , befindet sich darunter einejarsToScan
Einstellung, die alles überschreibtjarsToSkip
. Am Ende habentaglibs*.jar
wirjarsToScan
unsere hinzugefügt , wie unsere Taglibs warentaglibs-standard-impl-1.2.5.jar
undtaglibs-standard-spec-1.2.5.jar
.conf/catalina.properties
wechselte ichtomcat.util.scan.StandardJarScanFilter.jarsToSkip=*.jar
zutomcat.util.scan.StandardJarScanFilter.jarsToScan=jstl*.jar
und das hat es behoben.Überprüfen Sie auch, ob Sie Abhängigkeitsgläser hinzugefügt haben
javax.servlet.jar
undjavax.servlet.jsp.jstl-1.2.1.jar
nicht in Ihrem Ordner WEB-INF / lib. In meinem Fall haben diese beiden das Problem gelöst.quelle
Fügen Sie diese Anweisung Ihrer Seite hinzu:
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
Fügen Sie die JAR-Datei in Ihren Ordner WEB-INF / lib ein. Das sollte funktionieren. (Es hat bei mir funktioniert.)
quelle
Fügen Sie das
jstl-1.2.jar
in dentomcat/lib
Ordner.Damit wird Ihr Abhängigkeitsfehler wieder behoben.
quelle
Ich habe erwähnt, dass die Maven-Abhängigkeit in der pom.xml falsch ist. Es sollte sein
quelle
Ich wollte nur das Update hinzufügen, das ich für dieses Problem gefunden habe. Ich bin mir nicht sicher, warum das funktioniert hat. Ich hatte die richtige Version von jstl (1.2) und auch die richtige Version von servlet-api (2.5)
Ich hatte auch die richtige Adresse auf meiner Seite, wie in diesem Thread vorgeschlagen
Was dieses Problem für mich behoben hat, war das Entfernen des Scope-Tags aus meiner XML-Datei im POM für meine jstl 1.2-Abhängigkeit. Wieder nicht sicher, warum das behoben wurde, aber nur für den Fall, dass jemand den Frühling mit JPA und Hibernate Tutorial auf Pluralsight macht und sein Pom auf diese Weise eingerichtet hat, versuchen Sie, das Scope-Tag zu entfernen und prüfen Sie, ob dies das Problem behebt. Wie ich schon sagte, es hat bei mir funktioniert.
quelle
Ich hatte die Werkzeuge MAVEN und Spring vollständig deaktiviert. Und ich musste die folgenden Gläser hinzufügen, damit meine Umgebung richtig funktioniert.
Das Schlimmste von allem war
jstl-api-1.2.jar
undjavax-servlet.jsp.jst-api-1.2.1.jar
. Sie haben einfach nicht funktioniert.jstl-1.2.jar
gut gearbeitet.quelle
jstl-1.2
anstattjstl-1.2.1
für mich zu arbeiten, habe ich keine Ahnung warum.Wenn Sie Frühlings - Boot verwenden, sollten Sie entfernen
server.tomcat.additional-tld-skip-patterns=*.jar
aus ,Application.properties
wenn es irgendeinequelle
Alle Antworten in dieser Frage haben mir geholfen, aber ich dachte, ich würde einige zusätzliche Informationen für die Nachwelt hinzufügen.
Es stellte sich heraus, dass ich eine Testabhängigkeit hatte, von
gwt-test-utils
der dasgwt-dev
Paket kam.gwt-dev
Enthält leider eine vollständige Kopie von Jetty, JSP, JSTL usw., die vor den richtigen Paketen im Klassenpfad lag. Obwohl ich die richtigen Abhängigkeiten von JSTL 1.2 hatte, wurde die 1.0-Version intern geladengwt-dev
. Murren.Die Lösung für mich war, nicht mit Testumfang zu laufen, damit ich das
gwt-test-utils
Paket zur Laufzeit nicht abhole. Das Entfernen desgwt-dev
Pakets aus dem Klassenpfad auf andere Weise hätte das Problem ebenfalls behoben.quelle
Hatte gerade ein ähnliches Problem in Eclipse behoben mit:
etwas hat es schon mal rausgeschmissen, als ich meine pom.xml bearbeitet habe
Ich hatte alle benötigten JAR-Dateien, Taglib Uri und web.xml war in Ordnung
quelle
Eine Antwort für das Jahr 2020
Die Frage ist immer noch sehr beliebt, aber alle Antworten sind ernsthaft veraltet. Alle Java EE-Komponenten wurden in verschiedene Jakarta-Projekte aufgeteilt, und JSTL ist nicht anders. Hier sind die korrekten Maven-Abhängigkeiten von heute:
Ja, die Versionen und Gruppen-IDs stimmen nicht überein, aber das ist eine Eigenart des aktuellen Projektstatus .
quelle
Das hat bei mir funktioniert
quelle
Ich hatte das gleiche Problem, ich verwende Eclipse, nur für den Fall, dass andere das gleiche Problem haben:
In Eclipse doppelklicken Sie auf den Tomcat-Server,
stoppen Sie den Server und
deaktivieren Sie die Option "Servermodule ohne Veröffentlichung".
Starten Sie den Server.
quelle
Ein ähnliches Problem in IBM RAD 7.5 wurde behoben, indem Folgendes ausgewählt wurde:
quelle