How to use JSTL in a GWT project?

Question

I am creating a GWT project with GWT-2.0.3 and the eclipse plugin. well, at first I tried, JSTL1.2 and servlet 2.5,

• I am adding jstl-1.2.jar to war / WEB-INF / lib

• in web.xml, I use:

  <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="WebApp_ID" version="2.5"> 

• on the jsp page, I use:

   <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%> <c:forEach var="app" items="${requestScope.apps}"> <tr><td width=20%><c:out value="${app.mapping}"></c:out></td> <td width=40%><c:out value="${app.description}"></c:out></td> ... 

If I remove the foreach tag, it works fine. but if I use basic tags, I get the following exception:

 HTTP ERROR: 500 javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext; RequestURI=/system/view/register.html Caused by: java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext; at javax.servlet.jsp.jstl.core.LoopTagSupport.unExposeVariables(LoopTagSupport.java:587) at javax.servlet.jsp.jstl.core.LoopTagSupport.doFinally(LoopTagSupport.java:323) at org.apache.jsp.system.view_jsp._jspx_meth_c_forEach_0(view_jsp.java:267) at org.apache.jsp.system.view_jsp._jspx_meth_a_body_0(view_jsp.java:186) at org.apache.jsp.system.view_jsp._jspService(view_jsp.java:98) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:285) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) at org.app4j.test.DispatchServlet.doGet(DispatchServlet.java:133) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:49) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488) Powered by Jetty:// 

If I build a project on Tomcat 6, it works great. I search on the Internet and I find an article, "JSP Expression Language in GWTs embedded Jetty" , so I tried jstl-1.1 and servlet2.4, but I still get this exception.
I believe that the version of the GWT server for berths should be 6.1, but I'm not sure if it is, it should support EE5, so does anyone have built-in GWT and JSTL? please help! thanks.

Answer 1

I would recommend just switching to an external Java server (for example, Tomcat, which you seem to have installed and which works with your configuration) - there are much fewer problems, easier than trying to work with the damaged Jetty that comes with GWT.

Instructions can be found in the docs . If you stick with GWT Jetty, you will face a lot of problems in the future.

---

Update, see Pascal Thiven's comment below:

@Pascal: sorry for that, I didn’t just want to say “Switch to an external server, don’t talk”, it’s just that I saw a lot of people on SO and on the Google Group GWT who have problems with the Jetty setup that comes with GWT , - in some cases, this is due to the fact that the configuration is somewhat different from the standard, because the GWT team included an older / modified (I can not get any reliable information about this) version of Jetty, for example, see this post and comments there, some quotes:

NOTE. I believe that the version of the berth comes with GWT below 6.1.12 and therefore you should leave the first parameter in the docs example, since it was added to the berth 6.1.12rc3. See note at the top of Jetty docs.

---

Presumably Jetty supports servlet 2.5 and injection of resources by writing to the web.xml or @resource annotation. However, I have but to find out if this is supported by the version of Jetty that comes with GWT. If someone found out this does not work, and if so, how is it done, please let me know.

Other problems arise when someone wants to use EJB.

All of this (possibly in a more concise / cryptic way) is written in the GWT documentation, for which I provided the link above for an exact paragraph addressing this issue.
I hope this clarified some things - switching to an external server just seems to be the simplest, easiest and best solution - there is no special GWT configuration, that is, you can use the same configuration / server that you will use in production, no need to transfer your configuration e.g. in Tomcat, without any unexpected errors after migration, etc.

Answer 2

I came across this while looking for a JSTL fix for my application engine project. I found the answer on the "Will it play" page of Google. Obviously you should add

<%@page isElIgnored="false" %>

to your JSP pages to enable EL parsing.

Answer 3

I am getting this error too.

I found that I can fix this by moving the GWT SDK to the end of the class path in the Eclipse Java Build Path → Order and Export window.

However, this interrupts GWT serialization with this message:

 Mar 3, 2011 3:31:23 PM sun.reflect.NativeMethodAccessorImpl invoke0 WARNING: Exception while dispatching incoming RPC call com.google.gwt.user.client.rpc.SerializationException: java.lang.reflect.InvocationTargetException at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeWithCustomSerializer(ServerSerializationStreamWriter.java:764) at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeImpl(ServerSerializationStreamWriter.java:727) 

You can fix this by moving the GWT library to a backup copy of the class path, which makes it look like you can either use JSTL or GWT Serialization running on Jetty, but not both.

(GWT 2.1, JSTL1.2 and servlet 2.5.)

Answer 4

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

The path to the Webapp runtime classes is probably cluttered with another version of the EL JAR file (either an older version or a different version of the application server) that lacks the excluded method mentioned. I suspect /WEB-INF/lib . Get rid of it, as a rule, already supplied by the specified application server, you do not need to include it in your webapp. This applies to all appserver libraries, for example servlet-api.jar , and to ships. You should never copy it to webapp /WEB-INF/lib . This requires portability problems.