I\'ve been struggling with Jetty 7 and its support for JSP and JSTL.
My JSP file:
<%@ page language=\"java\" contentType=\"text/html; charset=utf-8\"
java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;
This exception basically means that the mentioned method cannot be found in the runtime classpath, while it was available in the compiletime classpath of either the class or one of its dependencies.
This method is introduced in JSP 2.1 which gets hand in hand with Servlet 2.5. Since Jetty 7 is supposed to support Servlet 2.5 and thus isn't the suspect here, the only cause can be that the web.xml
is declared as Servlet 2.4 or lower instead of Servlet 2.5. So, to fix this particular problem, you need to declare your web.xml
as at least Servlet 2.5. The <web-app>
tag should look like this:
<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">
If that doesn't solve the problem, then the other cause is that the /WEB-INF/lib
or even worse the /JRE/lib
or /JRE/lib/ext
is cluttered with appserver-specific libraries containing an older Servlet API version. E.g. servlet-api.jar
from Tomcat or j2ee.jar
or javaee.jar
from Glassfish, etcetera. You'll need to clean up those classpath folders from any libraries which doesn't belong there, because they get precedence in classloading and will override the appserver's own libraries. Appserver-specific libraries belongs to the appserver in question, not to the webapp or JRE.
That said and apart from the actual problem, the @page
attributes language="java" contentType="text/html; charset=utf-8"
are all superfluous. The language
already defaults to Java and the contentType
already defaults to text/html
and the charset
will already be set to UTF-8
if you set pageEncoding="UTF-8"
. So the following is already sufficient:
<%@page pageEncoding="UTF-8" %>
With Jetty 8, the situation is a bit different, in case this helps anyone.
For JSTL 1.2, rather surprisingly, the taglib has to be:
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
with JSTL 1.2 from (mavenishly):
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
I can't really explain why the URL lacks 'jsp', but it works this way.
tsk... I don;t have privilege to comment. I am using Jetty 7.1.6 and answer provided by bmargulies works.
Basically, changing URI from
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
to
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
makes taglibs to work in Jetty 7.
-Nishant
Thx for the tip Steve! The bug seems still there, here's a workaround to run at Jetty initialisation. It did the trick for 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);
The reason why http://java.sun.com/jsp/jstl/core doesn't work is because the code in the Jasper Jsp parser used by Jetty (org.apache.jasper.glassfish:jar:2.2.2.xxx) assumes that that uri is a systemuri (see TldScanner.java) and it will not put any taglibs with this uri in its tablib location cache. I don't know why this assumption is in the code but it is. Seems to be a bug to me.