2010-03-28 10 views
7

He estado luchando con Jetty 7 y su soporte para JSP y JSTL.Jetty 7 distribución Hightide, soporte JSP y JSTL

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

Las porciones JSP anteriores funcionan como se esperaba. JSTL, sin embargo, no. Las campañas y las variables de resultados son atributos de solicitud establecidos por un servlet.

que obtienen los siguientes errores:

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; 
  • no me la agrupación de los archivos jar en mi archivo .war desplegado a embarcadero.
  • La versión de amarre que estoy usando es: amarre-hightide-7.0.1.v20091125

La ruta de clases:

/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 

Cualquier ayuda sería muy apreciada.

Gracias de antemano,

Lior.

Respuesta

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

Esta excepción básicamente significa que el método mencionado no se puede encontrar en la ruta de clase en tiempo de ejecución, mientras que estaba disponible en la ruta de clase tiempo de compilación de cualquiera de la clase o una de sus dependencias.

Este method se presenta en JSP 2.1 que se combina con Servlet 2.5. Como se supone que Jetty 7 es compatible con Servlet 2.5 y, por lo tanto, no es el sospechoso aquí, la única causa puede ser que el web.xml se declare como Servlet 2.4 o inferior en lugar de Servlet 2.5. Por lo tanto, para solucionar este problema en particular, debe declarar su web.xml como al menos Servlet 2.5. La etiqueta <web-app> debería tener este aspecto:

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

Si eso no resuelve el problema, entonces la otra causa es que el /WEB-INF/lib o peor aún la /JRE/lib o /JRE/lib/ext está lleno de bibliotecas de servidor de aplicaciones específicas que contienen un servlet mayores Versión API P.ej. servlet-api.jar de Tomcat o j2ee.jar o javaee.jar de Glassfish, etcétera. Necesitará limpiar esas carpetas de classpath de cualquier biblioteca que no pertenezca allí, porque tienen precedencia en la carga de clases y anularán las propias bibliotecas del servidor de aplicaciones. Las bibliotecas específicas de Appserver pertenecen al servidor de aplicaciones en cuestión, no a la aplicación web o JRE.


Dicho esto, y aparte del problema real, el @page atributos language="java" contentType="text/html; charset=utf-8" son todos superfluo. El language ya está predeterminado en Java y el contentType ya está predeterminado en text/html y el charset ya estará configurado en UTF-8 si establece pageEncoding="UTF-8".Así que la siguiente ya es suficiente:

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

Mi web.xml ya usa la versión 2.5 como se muestra arriba. No vayas. –

+0

Actualicé mi respuesta para incluir otra posible causa. – BalusC

+0

Modifiqué mi directiva <% @ page para que coincida con sus sugerencias. Gracias. Todavía luchando con el problema principal aunque. –

7

con embarcadero 8, la situación es un poco diferente, en caso de que esto ayude a.

Para JSTL 1.2, en lugar de esperar, el taglib tiene que ser:

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

con JSTL 1.2 a partir de (mavenishly):

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

realmente no puedo explicar por qué la URL carece ' jsp ', pero funciona de esta manera.

4

tsk ... No tengo el privilegio de comentar. Estoy usando Jetty 7.1.6 y la respuesta proporcionada por bmargulies funciona.

Básicamente, el cambio de URI de

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

a

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

hace taglibs para trabajar en el embarcadero 7.

-Nishant

+0

Gracias, dando una oportunidad. –

4

La razón por la http://java.sun.com/jsp/jstl/core no funciona es porque el código en el analizador Jasper Jsp utilizado por Jetty (org.apache .jasper.glassfish: jar: 2.2.2.xxx) asume que ese uri es un systemuri (ver TldScanner.java) y no pondrá taglibs con este uri en su caché de ubicación tablib. No sé por qué esta suposición está en el código, pero lo es. Parece ser un error para mí.

+0

Gracias por la explicación (consiguió JSTL trabajando ahora gracias a la discusión anterior). Estoy usando Embedded Jetty, y para JSP utilizo esta coordenada de Maven: org.glassfish.web: jsp-impl: 2.2.1. Intentaré usar otra implementación de JSP. ¡Buen descubrimiento (detectando el problema en TldScanner)! – Daniel

1

Thx para la punta Steve! El error parece estar ahí, aquí hay una solución para ejecutar en la inicialización de Jetty. Me hizo el truco.

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); 
+0

¿Es esto realmente un error? – Cemo

+0

Parece que es un error. Cambiar a jasper 6.0.37 ayuda con ese problema. Excluya el módulo "todo * .excluir: 'org.apache.jasper.glassfish'" (sintaxis gradle) y agregue "compilar 'org.apache.tomcat: jasper: 6.0.37'". – Stas

Cuestiones relacionadas