Jetty 7 distribuzione hightide, supporto JSP e JSTL

Ho sofferto con Jetty 7 e il suo supporto per JSP e JSTL.Jetty 7 distribuzione hightide, supporto JSP e JSTL

file di mio JSP:

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8" %> 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 
<html> 
<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> 

<head> 
    <title>blah</title> 
</head> 
<body> 
    <table id="data"> 
    <tr class="columns"> 
     <td>Hour</td> 
     <c:forEach var="campaign" items="${campaigns}"> 
     <td>${campaign}</td>    
     </c:forEach> 
    </tr> 

    <c:forEach var="hour" items="${results}"> 
     <tr> 
     <td class="hour">${hour.key}</td> 
     <c:forEach var="campaign" items="${campaigns}"> 
      <td>${hour[campaign]}</td> 
     </c:forEach>    
     </tr>  
    </c:forEach> 
    </table> 
</body> 
</html>

Le porzioni JSP di cui sopra funzionano come previsto. JSTL, tuttavia, non lo fa. Le campagne e le variabili dei risultati sono attributi della richiesta impostati da un servlet.

ottengo i seguenti errori:

WARN: ... compiler.TagLibraryInfoImpl: Unknown element (deferred-value) in attribute 
WARN: ... compiler.TagLibraryInfoImpl: Unknown element (deferred-value) in attribute 
WARN: ... compiler.TagLibraryInfoImpl: Unknown element (deferred-value) in attribute 
ERROR: ... javax.servlet.ServletException: java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;

non sto bundling alcun file jar nel mio file .war schierato al pontile.
La versione del pontile che sto utilizzando è: molo-HighTide-7.0.1.v20091125

Il percorso di classe:

/usr/local/jetty/lib/jetty-xml-7.0.1.v20091125.jar:/usr/local/jetty/lib/servlet-api-2.5.jar:/usr/local/jetty/lib/jetty-http-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-continuation-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-server-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-security-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-servlet-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-webapp-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-deploy-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-servlets-7.0.1.v20091125.jar:/usr/local/jetty/lib/jsp/ant-1.6.5.jar:/usr/local/jetty/lib/jsp/core-3.1.1.jar:/usr/local/jetty/lib/jsp/jetty-jsp-2.1-7.0.1.v20091125.jar:/usr/local/jetty/lib/jsp/jsp-2.1-glassfish-9.1.1.B60.25.p2.jar:/usr/local/jetty/lib/jsp/jsp-api-2.1-glassfish-9.1.1.B60.25.p2.jar:/usr/local/jetty/resources:/usr/local/jetty/lib/jetty-util-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-io-7.0.1.v20091125.jar

Qualsiasi aiuto sarebbe molto apprezzato.

Grazie in anticipo,

Lior.

fonte

2010-03-28 Lior Cohen

java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;

Questa eccezione sostanzialmente significa che il metodo citato non può essere trovato nel classpath runtime, mentre era disponibile nel percorso classe compiletime di una classe o una delle sue dipendenze.

Questo method è stato introdotto in JSP 2.1 che va di pari passo con Servlet 2.5. Poiché Jetty 7 supporterà Servlet 2.5 e quindi non è il sospetto qui, l'unica causa può essere che lo web.xml è dichiarato come Servlet 2.4 o inferiore invece di Servlet 2.5. Quindi, per risolvere questo particolare problema, devi dichiarare il tuo web.xml come minimo Servlet 2.5. Il tag <web-app> dovrebbe essere simile a questo:

<web-app 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns="http://java.sun.com/xml/ns/javaee" 
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    id="YourWebAppID" 
    version="2.5">

Se questo non risolve il problema, poi l'altra causa è che il /WEB-INF/lib o peggio ancora la /JRE/lib o /JRE/lib/ext è ingombra di librerie specifiche appserver contenenti un servlet vecchio Versione API. Per esempio. servlet-api.jar da Tomcat o j2ee.jar o javaee.jar da Glassfish, eccetera. Avrai bisogno di ripulire quelle cartelle del classpath da qualsiasi libreria che non vi appartiene, perché ottengono la precedenza nel caricamento delle classi e sovrascriveranno le librerie di appserver. Le librerie specifiche di Appserver appartengono al server delle applicazioni in questione, non alla webapp o JRE.

Detto e, a parte il problema reale, il @page attributi language="java" contentType="text/html; charset=utf-8" sono tutti superflui. Il valore language è già impostato su Java e lo contentType è già impostato su text/html e charset è già impostato su UTF-8 se si imposta pageEncoding="UTF-8".Così il seguente è già sufficiente:

<%@page pageEncoding="UTF-8" %>

fonte

2010-03-28 23:26:20 BalusC

My web.xml utilizza già la versione 2.5 come mostrato sopra. Non andare. –

Ho aggiornato la mia risposta per includere un'altra possibile causa. – BalusC

Ho modificato la direttiva <% @ page in modo che corrisponda ai vostri suggerimenti. Grazie. Ancora alle prese con il problema principale. –

con pontile 8, la situazione è un po 'diversa, nel caso in cui questo aiuta nessuno.

Per JSTL 1.2, piuttosto sorprendentemente, il taglib deve essere:

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

con JSTL 1.2 da (mavenishly):

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

non posso davvero spiegare perché l'URL manca ' jsp ', ma funziona in questo modo.

fonte

2010-07-02 14:59:17 bmargulies

tsk ... Non ho il privilegio di commentare. Sto usando Jetty 7.1.6 e risposta fornita da bmargulies opere.

Fondamentalmente, cambiando URI

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

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

rende taglibs lavorare Molo 7.

-Nishant

fonte

2010-12-21 09:19:15 Nishant

Grazie, provando. –

Il motivo http://java.sun.com/jsp/jstl/core non funziona è perché il codice nel parser Jasper Jsp utilizzato da Jetty (org.apache .jasper.glassfish: jar: 2.2.2.xxx) presume che quel uri sia un systemuri (vedi TldScanner.java) e non inserirà alcun tagli con questo uri nella sua cache di posizione del tablib. Non so perché questa ipotesi è nel codice, ma lo è. Sembra essere un bug per me.

fonte

2012-01-18 16:05:57 Steve

Grazie per la spiegazione (ha funzionato JSTL ora grazie alla discussione sopra). Sto usando Jetty incorporato e per JSP uso questa coordinata Maven: org.glassfish.web: jsp-impl: 2.2.1. Proverò a usare un'altra implementazione JSP. Buona ricerca (individuazione del problema in TldScanner)! – Daniel

Thx per la punta Steve! Il bug sembra ancora lì, ecco una soluzione alternativa per l'inizializzazione del Jetty. Ha fatto il trucco per me.

import org.apache.jasper.runtime.TldScanner; 
import java.util.Set; 

Field field = TldScanner.class.getDeclaredField("systemUris"); 
field.setAccessible(true); 
((Set<?>)field.get(null)).clear(); 
field.setAccessible(false);

fonte

2012-08-07 05:53:12 Toilal

È davvero un bug? – Cemo

Sembra che sia un bug. Passare a jasper 6.0.37 aiuta a risolvere questo problema. Escludere il modulo "all * .exclude:" org.apache.jasper.glassfish "" (sintassi gradle) e aggiungere "compile" org.apache.tomcat: jasper: 6.0.37 '". – Stas

Jetty 7 distribuzione hightide, supporto JSP e JSTL

risposta

Problemi correlati