Come installare JSTL? L'uri assoluto: http://java.sun.com/jstl/core non può essere risolto

135

Non so cosa ho fatto in modo errato, ma non posso includere JSTL. Ho jstl-1.2.jar, ma purtroppo ottengo un'eccezione:

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)

Io ho:

  • 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>
jsp  servlets  jstl 
— lukastymo
fonte
4
Ho dovuto aggiungere anche la dipendenza da taglibs accanto al jstl e ho appena funzionato.
— Christian Vielma,

Risposte:

193

org.apache.jasper.JasperException: l'uri assoluto: http://java.sun.com/jstl/core non può essere risolto in web.xml o nei file jar distribuiti con questa applicazione

Quell'URI è per JSTL 1.0, ma in realtà stai utilizzando JSTL 1.2 che utilizza URI con un /jsppercorso aggiuntivo (perché JSTL, che ha inventato le espressioni EL, era dalla versione 1.1 integrata come parte di JSP per condividere / riutilizzare la logica EL in anche JSP semplice).

Quindi, correggi l'URI taglib di conseguenza in base alla documentazione JSTL :

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

Inoltre, è necessario assicurarsi assolutamente di non aggiungere più file JAR JSTL con versioni diverse nel percorso di classe di runtime. Questo è un errore abbastanza comune tra gli utenti Tomcat. Il problema con Tomcat è che non offre JSTL pronto all'uso e quindi è necessario installarlo manualmente. Ciò non è necessario nei normali server Java EE. Vedi anche Cos'è esattamente Java EE?

Nel tuo caso specifico, il tuo pom.xml ti dice sostanzialmente che hai jstl-1.2.jar e standard-1.1.2.jar insieme. Questo è sbagliato. Fondamentalmente stai mescolando JSTL 1.2 API + impl di Oracle con JSTL 1.1 impl di Apache. Devi rimuovere qualsiasi standard-xxx.jar. È sufficiente solo il jstl-1.2.jar.

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

Gli utenti non Maven possono ottenere lo stesso rilasciando il file jstl-1.2.jar fisico nella /WEB-INF/libcartella del progetto di applicazione web ( non rilasciare assolutamente file standard.jar o file .tld lì dentro!). Rimuovili se necessario.

Nel caso in cui si stia effettivamente utilizzando un normale server Java EE come WildFly, Payara, ecc. Anziché un servletcontainer barebone come Tomcat, Jetty, ecc., Non è necessario installare esplicitamente JSTL. I normali server Java EE forniscono già JSTL pronto all'uso. In altre parole, non è necessario aggiungere JSTL pom.xmlné eliminare alcun file JAR / TLD in webapp. Solo la providedcoordinata Java EE con ambito è sufficiente:

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

Inoltre, dovresti anche assicurarti che il tuo web.xmlsia dichiarato conforme almeno Servlet 2.4 e quindi non come Servlet 2.3 o precedente. Altrimenti le espressioni EL all'interno dei tag JSTL a loro volta non funzionerebbero. Scegli la versione più alta corrispondente al tuo contenitore di destinazione e assicurati di non averne uno <!DOCTYPE>nel tuo web.xml. Ecco un esempio compatibile con Servlet 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>

Guarda anche:

— BalusC
fonte
Ho cambiato in / jsp e: org.apache.jasper.JasperException: l'uri assoluto: java.sun.com/jsp/jstl/core non può essere risolto in né web.xml ....
— lukastymo
4
Quindi il tuo percorso di classe è un casino. Puliscilo. Non so che cosa stia facendo Maven e se sia intelligente, ma per JSTL 1.2 non hai bisogno di standardtaglib. Leggi la pagina delle informazioni sui tag per maggiori dettagli.
— BalusC
4
Mi piace molto la pagina wiki JSTL che hai messo insieme. Tuttavia, poiché questa domanda è il massimo riscontro da parte di Google per il particolare messaggio di errore, mi prendo la libertà di modificarlo e noto che l'URI "non jsp" proviene da JSTL 1.0.
— kdgregory
2
@kdgregory: Grazie :)
— BalusC
1
se stai usando Gradle, aggiungi questa dipendenza:compile('javax.servlet:jstl:1.2')
— benscabbia,
36

@BalusC ha perfettamente ragione, ma se riscontri ancora questa eccezione, significa che hai fatto qualcosa di sbagliato. Le informazioni più importanti che troverai sono nella pagina Informazioni tag SO JSTL .

Fondamentalmente questo è un riepilogo di ciò che è necessario fare per gestire questa eccezione.

  1. Controlla la versione servlet in web.xml: <web-app version="2.5">

  2. Controllare se la versione JSTL è supportata per questa versione servlet: la versione servlet 2.5 utilizza JSTL 1.2 o la versione servlet 2.4 utilizza JSTL 1.1

  3. Il contenitore del servlet deve disporre della libreria appropriata oppure è necessario includerlo manualmente nell'applicazione. Ad esempio: JSTL 1.2 richiede jstl-1.2.jar

Cosa fare con Tomcat 5 o 6:

È necessario includere i jar appropriati nella directory WEB-INF / lib (funzionerà solo per l'applicazione) o nel tomcat / lib (funzionerà a livello globale per tutte le applicazioni).

L'ultima cosa è un taglib nei tuoi file jsp. Per JSTL 1.2 uno corretto è questo:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
— lukastymo
fonte
3
Ho notato che questa domanda è piuttosto popolare (molti spettatori). Quindi è per questo che ho deciso di scrivere un breve tutorial su come affrontare questo problema
— lukastymo,
17

Ho trovato un altro motivo per questo tipo di errore: nel mio caso, qualcuno ha impostato la proprietà conf/catalina.propertiessetting per evitare i messaggi di avviso del registro, saltando così la scansione necessaria da Tomcat. La modifica del valore predefinito di Tomcat e l'aggiunta di un elenco appropriato di vasetti da saltare (escluso jstl-1.2 o spring-webmvc) hanno risolto il problema.tomcat.util.scan.StandardJarScanFilter.jarsToSkip*

— resnbl
fonte
Sì!. Anch'io. Qualcuno (= me stesso) a un certo punto messo tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* in catalina.propertiesarchivio in un (incompreso?) Tentativo di accelerare il tempo di avvio di Tomcat. Arghh!
— Pietro,
Uso il seguente script per creare un elenco di vasetti ToSkip che evita TLD e vasetti di frammenti web: pastebin.com/3Bfm1u6K
— Moreaki,
1
Se non si desidera modificare l' jarsToSkipimpostazione, al di sotto di essa è presente jarsToScanun'impostazione che sovrascrive qualsiasi elemento jarsToSkip. Abbiamo finito per aggiungere taglibs*.jaral nostro jarsToScancome erano i nostri taglibs taglibs-standard-impl-1.2.5.jare taglibs-standard-spec-1.2.5.jar.
— jabe
1
Questa è la risposta che ha funzionato per me. Nel conf/catalina.properties, ho cambiato tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*.jarper tomcat.util.scan.StandardJarScanFilter.jarsToScan=jstl*.jare che riparato.
— Gary S.
15 
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" %>

anche fare riferimento ai vasetti di dipendenza che sono stati aggiunti javax.servlet.jare javax.servlet.jsp.jstl-1.2.1.jaro no nel vostro WEB-INF / lib cartella. Nel mio caso questi due hanno risolto il problema.

— Il falco della strada
fonte
ti invitiamo a dare un'occhiata alla domanda qui [ stackoverflow.com/questions/44039706/...
— Kasun Siyambalapitiya
10

Aggiungi il jstl-1.2.jarnella tomcat/libcartella.

In questo modo, l'errore di dipendenza verrà nuovamente corretto.

— Hadi Rasouli
fonte
10
  1. Scarica jstl-1.2.jar

  2. Aggiungi questa direttiva alla tua pagina: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

  3. Incolla il file JAR nella cartella WEB-INF / lib. Questo dovrebbe funzionare. (Ha funzionato per me.)

— Prashant Ghimire
fonte
3

Volevo solo aggiungere la correzione che ho trovato per questo problema. Non sono sicuro del motivo per cui ha funzionato. Ho avuto la versione corretta di jstl (1.2) e anche la versione corretta di 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>

Ho anche avuto l'indirizzo corretto nella mia pagina come suggerito in questo thread, che è 

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

Ciò che ha risolto questo problema per me è stata la rimozione del tag scope dal mio file XML nel pom per la mia dipendenza jstl 1.2. Ancora una volta non sono sicuro del motivo per cui è stato risolto, ma nel caso in cui qualcuno stia facendo la primavera con il tutorial di JPA e Hibernate su Pluralsight e abbia il suo pom setup in questo modo, prova a rimuovere il tag scope e vedi se lo risolve. Come ho detto, ha funzionato per me.

— gnattyp
fonte
2

Avevo disattivato completamente gli strumenti MAVEN e Spring. E ho dovuto aggiungere i seguenti jar per far funzionare bene il mio ambiente.

  • primavera-AOP-4.0.3.RELEASE.jar
  • spring-beans-4.0.3.RELEASE.jar (difficile trovare questa correzione, altri org.springframework <3.versioni> non hanno funzionato.
  • primavera-context-4.0.3.RELEASE.jar
  • spring-core-4.0.3.RELEASE.jar
  • primavera-espressione 4.0.3.RELEASE.jar
  • primavera-web-4.0.3.RELEASE.jar
  • primavera-webmvc-4.0.3.RELEASE.jar
  • JSTL-1.2.jar

Il peggio di tutto è stato jstl-api-1.2.jare javax-servlet.jsp.jst-api-1.2.1.jar. Semplicemente non hanno funzionato.

jstl-1.2.jar ha funzionato bene.

— Siddharth
fonte
1
+1 Dopo aver sbattuto la testa contro il muro per ore, usando jstl-1.2invece di jstl-1.2.1lavorare anche per me, e non ho idea del perché.
— avojak
1

Se usi Spring boot, considera di rimuoverlo server.tomcat.additional-tld-skip-patterns=*.jarda Application.propertieseventuali

— Askar
fonte
0

Tutte le risposte a questa domanda mi hanno aiutato, ma ho pensato di aggiungere alcune informazioni aggiuntive per i posteri.

Si è scoperto che avevo una dipendenza di prova da gwt-test-utilscui ho portato il gwt-devpacchetto. Purtroppo gwt-devcontiene una copia completa di Jetty, JSP, JSTL, ecc. Che era in anticipo rispetto ai pacchetti appropriati sul percorso di classe. Quindi, anche se avessi dipendenze adeguate da JSTL 1.2, avrebbe caricato la versione 1.0 interna gwt-dev. Brontolare.

La soluzione per me era non funzionare con l'ambito del test, quindi non ritirare il gwt-test-utilspacchetto in fase di esecuzione. La rimozione del gwt-devpacchetto dal percorso di classe in qualche altro modo avrebbe anche risolto il problema.

— Grigio
fonte
0

Ho appena avuto un problema simile in Eclipse risolto con:

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

qualcosa l'ha buttato fuori prima, mentre stavo modificando il mio pom.xml

Avevo bisogno di tutti i file jar, taglib uri e web.xml erano ok

— w3Charlie
fonte
0

Una risposta per l'anno 2020

La domanda è ancora molto popolare, ma tutte le risposte sono gravemente obsolete. Tutti i componenti Java EE sono stati suddivisi in vari progetti di Jakarta e JSTL non è diverso. Quindi, ecco le dipendenze Maven corrette ad oggi:

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

Sì, le versioni e gli ID gruppo non corrispondono, ma è una stranezza dello stato corrente del progetto .

— JohnEye
fonte
sì, ma questo non risolve il mio problema ma vicino, con tomcat10, hai bisogno di due librerie * taglibs-standard-impl-1.2.5-migrated-0.0.1.jar * taglibs-standard-spec-1.2.5-migrated- 0.0.1.jar questa libreria può essere recuperata dalle webapps di esempio tomcat10, inoltre non esegue la scansione di taglibs-standard * poiché i file tld sono presenti, questo può essere disabilitato in context.xml nella webapp META-CONF lib
— Jasonw
-1

Questo ha funzionato per me 

    <groupId>jstl</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
— Ajay Kumar Sinha
fonte
-1

Ho avuto lo stesso problema, sto usando eclipse, nel caso in cui altri riscontrino lo stesso problema:
in eclipse fai doppio clic sul server tomcat,
ferma il server
deselezionando i "moduli server senza pubblicare"
avvia il server.

inserisci qui la descrizione dell'immagine

— JavaSheriff
fonte
-2

Risolto problema simile in IBM RAD 7.5 selezionando:

  1. Proprietà dei progetti
  2. Sfaccettature del progetto
  3. Casella di controllo JSTL
— c. hantzis
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.