Как использовать JSTL в проекте GWT?

Question

Я строю проект GWT, с GWT-2.0.3 и плагином Eclipse. хорошо, сначала я попробовал, JSTL1.2 и сервлет 2.5,

• я добавляю jstl-1.2.jar к войне /WEB-INF/lib

• в web.xml я использую:

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

• на странице JSP я использую:

  <%@ 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>
      ...
  

Если я удаляю тег foreach, он работает нормально. но если я использую основные теги, я получаю следующее исключение:

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

Если я разверну проект в Tomcat 6, он будет работать нормально. Я ищу в Интернете и нахожу статью "Язык выражений JSP во встроенной в GWT Jetty", поэтому я попробовал jstl-1.1 и servlet2.4, но все равно получаю это исключение.
я считаю, что версия сервера Jetty GWT должна быть 6.1, но я не уверен в этом, если это правда, он должен поддерживать EE5, поэтому кто-нибудь интегрировал GWT и JSTL? пожалуйста помоги! Благодарю.

Answer 1

Я наткнулся на это, пока искал исправление JSTL для своего проекта движка приложений. Я нашел ответ на странице "Будет ли это играть" от Google. Видимо, вы должны добавить

<%@page isElIgnored="false" %>

на ваши страницы JSP, чтобы включить анализ EL.

Answer 2

Я бы порекомендовал просто переключиться на внешний Java-сервер (например, Tomcat, который, кажется, вы установили и который работает с вашей конфигурацией) - гораздо меньше проблем, проще, чем пытаться работать с поврежденной Jetty, которая поставляется с GWT.

Инструкции можно найти в документации. Если вы будете придерживаться GWT Jetty, в будущем у вас будут только другие проблемы.

---

Обновление, см. Комментарий Паскаля Thivent ниже:

@Pascal: извините за это, я не хотел просто сказать "Переключиться на внешний сервер, не разговаривать", просто я видел много людей на SO и в GWT в Google Group, у которых есть проблемы с настройкой Jetty, который приходит с GWT - в некоторых случаях это потому, что конфигурация несколько отличается от стандартной, потому что команда GWT включила более старую / измененную (я не могу получить точную информацию об этом) версию Jetty, например, см. этот пост и комментарии там, некоторые цитаты:

ПРИМЕЧАНИЕ: я считаю, что версия пристани, поставляемая с GWT, ниже 6.1.12, и поэтому вы должны пропустить первый параметр в примерах документации, как он был добавлен в пристани 6.1.12rc3. См. Примечание в верхней части страницы документов Jetty.

---

Предположительно, Jetty поддерживает спецификацию сервлета 2.5 и внедрение ресурсов через запись web.xml или аннотацию @resource. Однако мне еще предстоит выяснить, поддерживается ли это версией Jetty, поставляемой с GWT. Если кто-нибудь выяснил, работает ли это или нет, и если да, то как это сделать, пожалуйста, дайте мне знать.

Другие проблемы возникают, когда кто-то хочет использовать EJB.

Все это (может быть, более сжатым / загадочным образом) написано в документации GWT - для чего я предоставил ссылку выше на точный параграф, посвященный этой проблеме.
Надеемся, что это прояснило некоторые вещи - переход на внешний сервер кажется самым простым, простым и лучшим решением - нет "специальной конфигурации GWT", а это означает, что вы можете использовать ту же конфигурацию / сервер, который вы будете использовать в работе, нет необходимо перенести вашу конфигурацию, например, в Tomcat, без неожиданных ошибок после миграции и т. д.

Answer 3

Я тоже получаю эту ошибку.

Я обнаружил, что могу это исправить, переместив GWT SDK в конец пути к классам в диалоговом окне Eclipse Java Build Path -> Order and Export.

Однако это нарушает сериализацию GWT с этим сообщением:

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)

Вы можете исправить это, переместив библиотеку GWT обратно по пути к классам, что заставляет ее выглядеть так, как будто вы можете использовать сериализацию JSTL или GWT в Jetty, но не то и другое одновременно.

(GWT 2.1, JSTL1.2 и сервлет 2.5.)

Answer 4

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

Путь к классу времени выполнения веб-приложения, вероятно, загроможден другой версией файла EL JAR (либо более старой версии, либо версии другого сервера приложений), в которой отсутствует упомянутый метод исключения. Я подозреваю /WEB-INF/lib, Избавьтесь от него, обычно он уже предоставляется соответствующим сервером приложений, вам не нужно включать его в ваше веб-приложение. Это относится ко всем библиотекам приложений, таких как servlet-api.jar а супруги кстати. Вы никогда не должны копировать его в веб-приложение /WEB-INF/lib, Это требует проблем с переносимостью.