Jak zainstalować JSTL? Nie można rozpoznać bezwzględnego adresu URL: http://java.sun.com/jstl/core

Question 1

Nie wiem, co zrobiłem niepoprawnie, ale nie mogę dołączyć JSTL. Mam jstl-1.2.jar, ale niestety mam wyjątek:

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)

Mam:

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>

Question 2

org.apache.jasper.JasperException: bezwzględnego adresu Uri: http://java.sun.com/jstl/core nie można rozwiązać ani w pliku web.xml ani w plikach jar wdrożonych z tą aplikacją

Ten identyfikator URI jest przeznaczony dla JSTL 1.0, ale w rzeczywistości używasz JSTL 1.2, który używa URI z dodatkową /jspścieżką (ponieważ JSTL, który wynalazł wyrażenia EL, był od wersji 1.1 zintegrowany jako część JSP w celu współużytkowania / ponownego użycia logiki EL w zwykły JSP).

Więc odpowiednio popraw identyfikator URI taglib na podstawie dokumentacji JSTL :

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

Ponadto należy absolutnie upewnić się , że nie wrzucasz jednocześnie wielu różnych wersji plików JSTL JAR do ścieżki klas środowiska wykonawczego. To dość powszechny błąd wśród użytkowników Tomcat. Problem z Tomcat polega na tym, że nie oferuje on JSTL po wyjęciu z pudełka i dlatego musisz go ręcznie zainstalować. Nie jest to konieczne w przypadku zwykłych serwerów Java EE. Zobacz także Czym dokładnie jest Java EE?

W twoim konkretnym przypadku twój pom.xml w zasadzie mówi ci, że masz razem jstl-1.2.jar i standard-1.1.2.jar. To jest źle. Zasadniczo łączysz JSTL 1.2 API + impl z Oracle z JSTL 1.1 impl z Apache. Musisz usunąć wszystkie standard-xxx.jar. Wystarczy tylkojstl-1.2.jar jest wystarczająca.

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

Użytkownicy spoza Mavena mogą osiągnąć to samo, upuszczając fizyczny plik jstl-1.2.jar w /WEB-INF/libfolderze projektu aplikacji internetowej ( absolutnie nie wrzucaj tam standard.jar ani żadnych luźnych plików .tld!). Usuń je, jeśli to konieczne.

Jeśli faktycznie używasz normalnego serwera Java EE, takiego jak WildFly, Payara, itp. Zamiast podstawowego serwletu serwletu, takiego jak Tomcat, Jetty itp., Nie musisz w ogóle jawnie instalować JSTL. Normalne serwery Java EE już dostarczają JSTL po wyjęciu z pudełka. Innymi słowy, nie musisz dodawać JSTL pom.xmlani upuszczać żadnych plików JAR / TLD w aplikacji internetowej. Jedynie providedwspółrzędna Java EE z określonym zakresem jest wystarczająca:

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

Ponadto należy również upewnić się, że web.xmldeklarowana jest zgodność co najmniej z serwletem 2.4, a więc nie jako serwlet 2.3 lub starszy. W przeciwnym razie wyrażenia EL wewnątrz znaczników JSTL nie zadziałałyby. Wybierz najwyższą wersję pasującą do kontenera docelowego i upewnij się, że nie masz <!DOCTYPE>nigdzie w swoim web.xml. Oto przykład zgodny z serwletem 4.0 (Tomcat 9):

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

Zobacz też:

Dokumentacja JSTL core taglib (dla odpowiednich identyfikatorów URI taglib)
Strona informacyjna o znaczniku JSTL (linki do pobrania JSTL i web.xmlprzykłady)

Question 3

@BalusC ma całkowitą rację, ale jeśli nadal napotykasz ten wyjątek, oznacza to, że zrobiłeś coś źle. Najważniejsze informacje, które znajdziesz, znajdują się na stronie SO JSTL Tag Info .

Zasadniczo jest to podsumowanie tego, co musisz zrobić, aby poradzić sobie z tym wyjątkiem.

Sprawdź wersję serwletu w web.xml: <web-app version="2.5">
Sprawdź, czy wersja JSTL jest obsługiwana dla tej wersji serwletu: Servlet w wersji 2.5 używa JSTL 1.2 lub Servlet w wersji 2.4 używa JSTL 1.1
Twój kontener serwletów musi mieć odpowiednią bibliotekę lub musisz dołączyć go ręcznie do aplikacji. Na przykład: JSTL 1.2 wymaga jstl-1.2.jar

Co zrobić z Tomcat 5 lub 6:

Musisz dołączyć odpowiednie pliki jar do katalogu WEB-INF / lib (będzie działać tylko dla twojej aplikacji) lub do tomcat / lib (będzie działać globalnie dla wszystkich aplikacji).

Ostatnią rzeczą jest taglib w twoich plikach jsp. Dla JSTL 1.2 poprawne jest to:

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

Question 4

Znalazłem inny powód tego typu błędu: w moim przypadku ktoś ustawił właściwość conf/catalina.propertiesustawienia, aby uniknąć komunikatów ostrzegawczych dziennika, pomijając w ten sposób niezbędne skanowanie przez Tomcat. Zmiana tego z powrotem na domyślne Tomcat i dodanie odpowiedniej listy plików JAR do pominięcia (bez jstl-1.2 lub spring-webmvc) rozwiązało problem.tomcat.util.scan.StandardJarScanFilter.jarsToSkip*

Question 5

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

sprawdź także pliki jarów zależności, które dodałeś javax.servlet.jari javax.servlet.jsp.jstl-1.2.1.jarczy nie znajdują się w folderze WEB-INF / lib. W moim przypadku ta dwójka rozwiązała problem.

Question 6

Pobierz plik jstl-1.2.jar
Dodaj tę dyrektywę do swojej strony: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
Wklej plik JAR do folderu WEB-INF / lib. To powinno działać. (U mnie to zadziałało.)

Question 7

Dodaj jstl-1.2.jardo tomcat/libfolderu.

Dzięki temu Twój błąd zależności zostanie ponownie naprawiony.

Question 8

Wspomniałem, że zależność Mavena w pom.xml jest nieprawidłowa. Powinno być

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

Question 9

Chciałem tylko dodać poprawkę, którą znalazłem dla tego problemu. Nie wiem, dlaczego to zadziałało. Miałem poprawną wersję jstl (1.2), a także poprawną wersję 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>

Miałem też poprawny adres na mojej stronie, jak sugerowano w tym wątku, czyli

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

Rozwiązaniem tego problemu było usunięcie tagu scope z mojego pliku xml w pom dla mojej zależności od jstl 1.2. Ponownie nie jestem pewien, dlaczego to naprawiło, ale na wypadek, gdyby ktoś robił wiosnę z samouczkiem JPA i Hibernacją na temat liczby mnogiej i ma konfigurację pom w ten sposób, spróbuj usunąć tag zakresu i sprawdź, czy to naprawi. Tak jak powiedziałem, to zadziałało dla mnie.

Question 10

Całkowicie wyłączyłem narzędzia MAVEN i Spring. Musiałem dodać następujące słoiki, aby moje środowisko działało poprawnie.

spring-aop-4.0.3.RELEASE.jar
spring-beans-4.0.3.RELEASE.jar (trudno znaleźć tę poprawkę, inne org.springframework <3.versions> po prostu nie działały.
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
wiosna-webmvc-4.0.3.RELEASE.jar
jstl-1.2.jar

Najgorsze było jstl-api-1.2.jari javax-servlet.jsp.jst-api-1.2.1.jar. Po prostu nie działały.

jstl-1.2.jar działało dobrze.

Question 11

Jeśli używasz butów Spring, rozważ usunięcie server.tomcat.additional-tld-skip-patterns=*.jarz, Application.propertiesjeśli takie istnieją

Question 12

Wszystkie odpowiedzi na to pytanie pomogły mi, ale pomyślałem, że dodam dodatkowe informacje dla potomności.

Okazało się, że miałem testową zależność od gwt-test-utilsktórej przyniosłem gwt-devpaczkę. Niestety gwt-devzawiera pełną kopię Jetty, JSP, JSTL itp., Która wyprzedziła odpowiednie pakiety w ścieżce klas. Więc mimo że miałem odpowiednie zależności od JSTL 1.2, załadowałbym wewnętrzną wersję 1.0 do gwt-dev. Narzekać.

Rozwiązaniem dla mnie było nie uruchamianie z zakresem testowym, więc nie odbieram gwt-test-utilspakietu w czasie wykonywania. Usunięcie gwt-devpakietu ze ścieżki klas w inny sposób również rozwiązałoby problem.

Question 13

Właśnie miałem podobny problem w Eclipse naprawiony z:

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

coś go wcześniej wyrzuciło, kiedy edytowałem plik pom.xml

Miałem wszystkie potrzebne pliki jar, taglib uri i web.xml były w porządku

Question 14

Odpowiedź na rok 2020

Pytanie jest nadal bardzo popularne, ale wszystkie odpowiedzi są poważnie nieaktualne. Wszystkie komponenty Java EE zostały podzielone na różne projekty Dżakarty i nie inaczej jest z JSTL. Oto poprawne zależności Mavena na dzień dzisiejszy:

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

Tak, wersje i groupIds nie są zgodne, ale jest to dziwactwo obecnego stanu projektu .

Question 15

To zadziałało dla mnie

    <groupId>jstl</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>

Question 16

Miałem ten sam problem, używam eclipse, na wypadek, gdyby inni napotkali ten sam problem:
W eclipse kliknij dwukrotnie serwer tomcat,
zatrzymaj serwer,
odznacz opcję „moduły serwera bez publikacji”
uruchom serwer.

Question 17

Rozwiązano podobny problem w IBM RAD 7.5, wybierając:

Właściwości projektów
Aspekty projektu
Pole wyboru JSTL

Answer 1

Nie wiem, co zrobiłem niepoprawnie, ale nie mogę dołączyć JSTL. Mam jstl-1.2.jar, ale niestety mam wyjątek:

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)

Mam:

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>

Answer 2

4

Musiałem dodać również zależność taglibs obok jstl i po prostu działałem.

Christian Vielma

Answer 3

org.apache.jasper.JasperException: bezwzględnego adresu Uri: http://java.sun.com/jstl/core nie można rozwiązać ani w pliku web.xml ani w plikach jar wdrożonych z tą aplikacją

Ten identyfikator URI jest przeznaczony dla JSTL 1.0, ale w rzeczywistości używasz JSTL 1.2, który używa URI z dodatkową /jspścieżką (ponieważ JSTL, który wynalazł wyrażenia EL, był od wersji 1.1 zintegrowany jako część JSP w celu współużytkowania / ponownego użycia logiki EL w zwykły JSP).

Więc odpowiednio popraw identyfikator URI taglib na podstawie dokumentacji JSTL :

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

Ponadto należy absolutnie upewnić się , że nie wrzucasz jednocześnie wielu różnych wersji plików JSTL JAR do ścieżki klas środowiska wykonawczego. To dość powszechny błąd wśród użytkowników Tomcat. Problem z Tomcat polega na tym, że nie oferuje on JSTL po wyjęciu z pudełka i dlatego musisz go ręcznie zainstalować. Nie jest to konieczne w przypadku zwykłych serwerów Java EE. Zobacz także Czym dokładnie jest Java EE?

W twoim konkretnym przypadku twój pom.xml w zasadzie mówi ci, że masz razem jstl-1.2.jar i standard-1.1.2.jar. To jest źle. Zasadniczo łączysz JSTL 1.2 API + impl z Oracle z JSTL 1.1 impl z Apache. Musisz usunąć wszystkie standard-xxx.jar. Wystarczy tylkojstl-1.2.jar jest wystarczająca.

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

Użytkownicy spoza Mavena mogą osiągnąć to samo, upuszczając fizyczny plik jstl-1.2.jar w /WEB-INF/libfolderze projektu aplikacji internetowej ( absolutnie nie wrzucaj tam standard.jar ani żadnych luźnych plików .tld!). Usuń je, jeśli to konieczne.

Jeśli faktycznie używasz normalnego serwera Java EE, takiego jak WildFly, Payara, itp. Zamiast podstawowego serwletu serwletu, takiego jak Tomcat, Jetty itp., Nie musisz w ogóle jawnie instalować JSTL. Normalne serwery Java EE już dostarczają JSTL po wyjęciu z pudełka. Innymi słowy, nie musisz dodawać JSTL pom.xmlani upuszczać żadnych plików JAR / TLD w aplikacji internetowej. Jedynie providedwspółrzędna Java EE z określonym zakresem jest wystarczająca:

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

Ponadto należy również upewnić się, że web.xmldeklarowana jest zgodność co najmniej z serwletem 2.4, a więc nie jako serwlet 2.3 lub starszy. W przeciwnym razie wyrażenia EL wewnątrz znaczników JSTL nie zadziałałyby. Wybierz najwyższą wersję pasującą do kontenera docelowego i upewnij się, że nie masz <!DOCTYPE>nigdzie w swoim web.xml. Oto przykład zgodny z serwletem 4.0 (Tomcat 9):

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

Zobacz też:

Dokumentacja JSTL core taglib (dla odpowiednich identyfikatorów URI taglib)
Strona informacyjna o znaczniku JSTL (linki do pobrania JSTL i web.xmlprzykłady)

Answer 4

Zmieniłem na / jsp i: org.apache.jasper.JasperException: Bezwzględny uri: java.sun.com/jsp/jstl/core nie może być rozwiązany w żadnym z web.xml ....

lukastymo

Answer 5

4

Wtedy twoja ścieżka klas to bałagan. Oczyść to. Nie wiem, co robi maven i czy to sprytne, ale dla JSTL 1.2 nie potrzebujesz standardtaglib. Więcej szczegółów znajdziesz na stronie z informacjami o tagu.

BalusC,

Answer 6

4

Bardzo podoba mi się strona wiki JSTL, którą stworzyłeś. Jednakże, ponieważ to pytanie jest najpopularniejszym hitem od Google w odniesieniu do konkretnego komunikatu o błędzie, pozwalam sobie na jego edycję i zauważam, że identyfikator URI „non-jsp” pochodzi z JSTL 1.0.

kdgregory

Answer 7

2

@kdgregory: Dziękuję :)

BalusC

Answer 8

1

jeśli używasz Gradle, dodaj tę zależność:compile('javax.servlet:jstl:1.2')

benscabbia

Answer 9

@BalusC ma całkowitą rację, ale jeśli nadal napotykasz ten wyjątek, oznacza to, że zrobiłeś coś źle. Najważniejsze informacje, które znajdziesz, znajdują się na stronie SO JSTL Tag Info .

Zasadniczo jest to podsumowanie tego, co musisz zrobić, aby poradzić sobie z tym wyjątkiem.

Sprawdź wersję serwletu w web.xml: <web-app version="2.5">
Sprawdź, czy wersja JSTL jest obsługiwana dla tej wersji serwletu: Servlet w wersji 2.5 używa JSTL 1.2 lub Servlet w wersji 2.4 używa JSTL 1.1
Twój kontener serwletów musi mieć odpowiednią bibliotekę lub musisz dołączyć go ręcznie do aplikacji. Na przykład: JSTL 1.2 wymaga jstl-1.2.jar

Co zrobić z Tomcat 5 lub 6:

Musisz dołączyć odpowiednie pliki jar do katalogu WEB-INF / lib (będzie działać tylko dla twojej aplikacji) lub do tomcat / lib (będzie działać globalnie dla wszystkich aplikacji).

Ostatnią rzeczą jest taglib w twoich plikach jsp. Dla JSTL 1.2 poprawne jest to:

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

Answer 10

3

Zauważyłem, że to pytanie jest dość popularne (wielu widzów). Dlatego zdecydowałem się napisać krótki poradnik, jak sobie z tym poradzić

lukastymo

Answer 11

17

Znalazłem inny powód tego typu błędu: w moim przypadku ktoś ustawił właściwość conf/catalina.propertiesustawienia, aby uniknąć komunikatów ostrzegawczych dziennika, pomijając w ten sposób niezbędne skanowanie przez Tomcat. Zmiana tego z powrotem na domyślne Tomcat i dodanie odpowiedniej listy plików JAR do pominięcia (bez jstl-1.2 lub spring-webmvc) rozwiązało problem.tomcat.util.scan.StandardJarScanFilter.jarsToSkip*

resnbl
źródło

Tak!. Ja też. Ktoś (= ja) w pewnym momencie został umieszczony tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* w catalina.propertiespliku w (niezrozumianej?) Próbie przyspieszenia uruchamiania Tomcata. Arghh!

peterh

Używam następującego skryptu, aby utworzyć listę jarsToSkip, która unika TLD i słoików z fragmentami sieci: pastebin.com/3Bfm1u6K

Moreaki

1

Jeśli nie chcesz zmieniać swojego jarsToSkipustawienia, poniżej znajduje się jarsToScanustawienie, które zastępuje wszystko w jarsToSkip. Skończyło się na dodaniu taglibs*.jardo naszych, jarsToScantak jak były nasze taglibs taglibs-standard-impl-1.2.5.jari taglibs-standard-spec-1.2.5.jar.

jabe

1

To odpowiedź, która mi pomogła. W conf/catalina.propertieszmieniłem tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*.jarna tomcat.util.scan.StandardJarScanFilter.jarsToScan=jstl*.jari to naprawiło.

Gary S.

Answer 12

Tak!. Ja też. Ktoś (= ja) w pewnym momencie został umieszczony tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* w catalina.propertiespliku w (niezrozumianej?) Próbie przyspieszenia uruchamiania Tomcata. Arghh!

peterh

Answer 13

Używam następującego skryptu, aby utworzyć listę jarsToSkip, która unika TLD i słoików z fragmentami sieci: pastebin.com/3Bfm1u6K

Moreaki

Answer 14

1

Jeśli nie chcesz zmieniać swojego jarsToSkipustawienia, poniżej znajduje się jarsToScanustawienie, które zastępuje wszystko w jarsToSkip. Skończyło się na dodaniu taglibs*.jardo naszych, jarsToScantak jak były nasze taglibs taglibs-standard-impl-1.2.5.jari taglibs-standard-spec-1.2.5.jar.

jabe

Answer 15

1

To odpowiedź, która mi pomogła. W conf/catalina.propertieszmieniłem tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*.jarna tomcat.util.scan.StandardJarScanFilter.jarsToScan=jstl*.jari to naprawiło.

Gary S.

Answer 16

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

sprawdź także pliki jarów zależności, które dodałeś javax.servlet.jari javax.servlet.jsp.jstl-1.2.1.jarczy nie znajdują się w folderze WEB-INF / lib. W moim przypadku ta dwójka rozwiązała problem.

Answer 17

czy możesz

rzucić

Answer 18

Pobierz plik jstl-1.2.jar
Dodaj tę dyrektywę do swojej strony: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
Wklej plik JAR do folderu WEB-INF / lib. To powinno działać. (U mnie to zadziałało.)

Answer 19

10

Dodaj jstl-1.2.jardo tomcat/libfolderu.

Dzięki temu Twój błąd zależności zostanie ponownie naprawiony.

Hadi Rasouli
źródło

Answer 20

3

Wspomniałem, że zależność Mavena w pom.xml jest nieprawidłowa. Powinno być

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

LoBo
źródło

Ciekawe, kiedy szukam jstl w maven, znajduję się w: mvnrepository.com/artifact/javax.servlet.jsp.jstl/jstl/1.2 Jak znalazłeś tę zależność?

Koray Tugay

Answer 21

Ciekawe, kiedy szukam jstl w maven, znajduję się w: mvnrepository.com/artifact/javax.servlet.jsp.jstl/jstl/1.2 Jak znalazłeś tę zależność?

Koray Tugay

Answer 22

Chciałem tylko dodać poprawkę, którą znalazłem dla tego problemu. Nie wiem, dlaczego to zadziałało. Miałem poprawną wersję jstl (1.2), a także poprawną wersję 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>

Miałem też poprawny adres na mojej stronie, jak sugerowano w tym wątku, czyli

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

Rozwiązaniem tego problemu było usunięcie tagu scope z mojego pliku xml w pom dla mojej zależności od jstl 1.2. Ponownie nie jestem pewien, dlaczego to naprawiło, ale na wypadek, gdyby ktoś robił wiosnę z samouczkiem JPA i Hibernacją na temat liczby mnogiej i ma konfigurację pom w ten sposób, spróbuj usunąć tag zakresu i sprawdź, czy to naprawi. Tak jak powiedziałem, to zadziałało dla mnie.

Answer 23

Całkowicie wyłączyłem narzędzia MAVEN i Spring. Musiałem dodać następujące słoiki, aby moje środowisko działało poprawnie.

spring-aop-4.0.3.RELEASE.jar
spring-beans-4.0.3.RELEASE.jar (trudno znaleźć tę poprawkę, inne org.springframework <3.versions> po prostu nie działały.
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
wiosna-webmvc-4.0.3.RELEASE.jar
jstl-1.2.jar

Najgorsze było jstl-api-1.2.jari javax-servlet.jsp.jst-api-1.2.1.jar. Po prostu nie działały.

jstl-1.2.jar działało dobrze.

Answer 24

1

+1 Po tym, jak przez wiele godzin uderzałem głową w ścianę, używanie jstl-1.2zamiast jstl-1.2.1zadziałało również dla mnie i nie mam pojęcia dlaczego.

avojak

Answer 25

1

Jeśli używasz butów Spring, rozważ usunięcie server.tomcat.additional-tld-skip-patterns=*.jarz, Application.propertiesjeśli takie istnieją

Askar
źródło

Answer 26

Wszystkie odpowiedzi na to pytanie pomogły mi, ale pomyślałem, że dodam dodatkowe informacje dla potomności.

Okazało się, że miałem testową zależność od gwt-test-utilsktórej przyniosłem gwt-devpaczkę. Niestety gwt-devzawiera pełną kopię Jetty, JSP, JSTL itp., Która wyprzedziła odpowiednie pakiety w ścieżce klas. Więc mimo że miałem odpowiednie zależności od JSTL 1.2, załadowałbym wewnętrzną wersję 1.0 do gwt-dev. Narzekać.

Rozwiązaniem dla mnie było nie uruchamianie z zakresem testowym, więc nie odbieram gwt-test-utilspakietu w czasie wykonywania. Usunięcie gwt-devpakietu ze ścieżki klas w inny sposób również rozwiązałoby problem.

Answer 27

Właśnie miałem podobny problem w Eclipse naprawiony z:

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

coś go wcześniej wyrzuciło, kiedy edytowałem plik pom.xml

Miałem wszystkie potrzebne pliki jar, taglib uri i web.xml były w porządku

Answer 28

Odpowiedź na rok 2020

Pytanie jest nadal bardzo popularne, ale wszystkie odpowiedzi są poważnie nieaktualne. Wszystkie komponenty Java EE zostały podzielone na różne projekty Dżakarty i nie inaczej jest z JSTL. Oto poprawne zależności Mavena na dzień dzisiejszy:

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

Tak, wersje i groupIds nie są zgodne, ale jest to dziwactwo obecnego stanu projektu .

Answer 29

tak, ale to nie rozwiązuje mojego problemu, ale zamknij, z tomcat10 potrzebujesz dwóch bibliotek * taglibs-standard-impl-1.2.5-migrated-0.0.1.jar * taglibs-standard-spec-1.2.5-migrated- 0.0.1.jar tę bibliotekę można pobrać z tomcat10 przykładowe aplikacje internetowe również nie skanuj taglibs-standard *, ponieważ znajdują się tam pliki tld, można to wyłączyć w context.xml w aplikacji internetowej META-CONF lib

Jasonw

Answer 30

-1

To zadziałało dla mnie

    <groupId>jstl</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>

Ajay Kumar Sinha
źródło

Answer 31

Miałem ten sam problem, używam eclipse, na wypadek, gdyby inni napotkali ten sam problem:
W eclipse kliknij dwukrotnie serwer tomcat,
zatrzymaj serwer,
odznacz opcję „moduły serwera bez publikacji”
uruchom serwer.

Answer 32

-2

Rozwiązano podobny problem w IBM RAD 7.5, wybierając:

Właściwości projektów
Aspekty projektu
Pole wyboru JSTL

do. hantzis
źródło

Jak zainstalować JSTL? Nie można rozpoznać bezwzględnego adresu URL: http://java.sun.com/jstl/core

Odpowiedzi:

Zobacz też:

Odpowiedź na rok 2020