In IntelliJ, is it possible to configure the embedded jetty server used by GWT with a custom jetty-web.xml? I would like to configure my web application to read some init-parameters from jetty-web.xml instead specifying the same web.xml in the web application. We use this approach to remove server context specific configuration in web.xml, however on development machine we still need to set these settings manually in web.xml, it would be nice to reproduce the same behaviour on development machines too.
I have tried placing a jetty-web.xml in WEB-INF directory, however each time the application is launched from IntelliJ the following exception is thrown:
java.lang.ClassNotFoundException: org.eclipse.jetty.webapp.WebAppContext
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:352)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:337)
at org.mortbay.util.Loader.loadClass(Loader.java:91)
at org.mortbay.xml.XmlConfiguration.nodeClass(XmlConfiguration.java:216)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:179)
at org.mortbay.jetty.webapp.JettyWebXmlConfiguration.configureWebApp(JettyWebXmlConfiguration.java:109)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:468)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.handler.RequestLogHandler.doStart(RequestLogHandler.java:115)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:672)
at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:509)
at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1093)
at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:836)
at com.google.gwt.dev.DevMode.main(DevMode.java:311)
Any thoughts?
You're using an old(er) version of GWT, which embeds an old version of Jetty (namely Jetty 6.1.11, see https://stackoverflow.com/a/17592318/116472) whose package name is org.mortbay.jetty, not org.eclipse.jetty.
GWT 2.6 updated to Jetty 8, but that "feature" was lost (there are some classloader issues).
In any case, jetty-web.xml never was officially supported by GWT, so I'd recommend not using it (particularly now that it breaks in GWT 2.6). If you need more than just running your web app, then use an external server and launch DevMode in -noserver mode: http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#How_do_I_use_my_own_server_in_development_mode_instead_of_GWT%27s
Related
I've a strange problem. I created the plain vanilla Greetings example with the webAppCreator of gwt. That means I created a project called Test and after that I did not modify it in any way. Then I created a war file with "ant war" and deployed this on my local tomcat 7. The server starts fine and the Grettings page is loaded properly. But, when clicking on the Send button I get the following error:
There a no error messages in the tomcat logs. However in the development mode the stuff works fine. I'm using gwt 2.5. Any idea what could cause this problem?
Edit: Maybee this gives some further insights:
I found a stack trace:
java.lang.UnsupportedClassVersionError: com/server/GreetingServiceImpl : Unsupported major.minor version 51.0 (unable to load class com.server.GreetingServiceImpl)
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2908)
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
java.lang.Thread.run(Thread.java:680)
But what does it mean?
Okay, I found the problem.
The error UnsupportedClassVersionError means that I tried to run a compiled java file with an older runtime, i.e. I compiled the servlets with java 7 and tried to run them with java 6.
I repaired this by setting the correct JAVA_HOME path to my .bash_profiles file like this
export JAVA_HOME=/path/to/java_7/Home
That was it, now everything runs fine. Thanks for reading anyway.
This question already has answers here:
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config
(2 answers)
Closed 7 years ago.
when I'm running my appication everything is ok to moment when I press the button and I'm redirecting to another xhtml page. Then eclipse console until I stop server display:
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/ChatAzure] threw exception [javax/servlet/jsp/jstl/core/Config] with root cause
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config
at com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:345)
at com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:154)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
I use:
eclipse, jsf2-1-7, jstl-1.2.jar, Tomcat v0.7.
I don't know what's wrong, I need help.
The mentioned class is part of JSTL. This is normally already provided by a full fledged Java EE container, but not in Tomcat as being a barebones JSP/Servlet container. You'd need to supply JSTL yourself along with the web application. It has ultimately to be placed in the webapp's runtime classpath.
You correctly mentioned jstl-1.2.jar (I assume that it's exactly the one as you could find in our JSTL wiki page), but this problem indicates that it has apparently not been placed at the right place. You need to place it in /WEB-INF/lib folder of the web project. This folder is covered by webapp's default runtime classpath. Nothing more needs to be done. If you have ever fiddled in the project's Build Path properties in an attempt to solve it, you should undo all those attempts.
Unrelated to the concrete problem: why are you still using legacy JSP? It has been deprecated and succeeded by Facelets (XHTML) since JSF 2.0. Make sure that you're reading up to date JSF 2.x resources and not JSF 1.x ones while learning JSF.
i always get the following error when trying to start Tomcat in eclipse (or also from the terminal with this specific war file)the build using ant is successful of course:
08.08.2011 08:21:02 org.apache.catalina.core.StandardContext loadOnStartup
SCHWERWIEGEND: Servlet threw load() exception
java.lang.ClassNotFoundException: dea.alo.aloWeb.spring.StxxDelegatingRequestProcessor
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1678)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1523)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.oroad.stxx.plugin.StxxPlugin.initRequestProcessorClass(StxxPlugin.java:153)
at com.oroad.stxx.plugin.StxxPlugin.init(StxxPlugin.java:102)
at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:1158)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:473)
at javax.servlet.GenericServlet.init(GenericServlet.java:160)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1216)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1135)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1031)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4957)
at org.apache.catalina.core.StandardContext$3.call(StandardContext.java:5284)
at org.apache.catalina.core.StandardContext$3.call(StandardContext.java:5279)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
It runs perfectly on a pc using linux and eclipse galileo, but not on my mac using eclipse indigo. the libraries are all in place..does anyone have an idea what the problem might be?
Looks like I syncyronisation problem I often have.
Refresh the Workspace
Project Build (most time not needed) - But make sure that there are no build errors
Then run the two tasks from the Servers/(tomcat) Context menu
Clean...
Clean Tomcat Working Directory
If this all does not help, then Remove the application from the Server, clean the Server and Deploy the application again to the server.
The class StxxDelegatingRequestProcessor is missing in your classpath -> "ClassNotFoundException: dea.alo.aloWeb.spring.StxxDelegatingRequestProcessor"
I think you copied the struts conf from a site but not the class :)
I have a problem running my gwt2.4rc1 application in a tomcat. The problem occurs when I try to make a requestfactory call. Then I get the exception at the bottom.
When I run GWT in development mode everything works fine. The gwt-dev. jar is in the lib folder of my webapp. I am using maven for dependency management. Could there be a problem with my configuration? I already had the error with gwt2.4 beta. If there are any other information required to solve this problem I am glad to provide them.
Regards,
Arne
SEVERE: Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: Unexpected checked exception
at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:216)
at com.google.web.bindery.requestfactory.server.ServiceLayerCache.getOrCache(ServiceLayerCache.java:242)
at com.google.web.bindery.requestfactory.server.ServiceLayerCache.resolveRequestFactory(ServiceLayerCache.java:198)
at com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:201)
at com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:125)
at com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:133)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:261)
at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:175)
at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:62)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)
at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:162)
at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:242)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:203)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:558)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:242)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:259)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:281)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.lang.NoClassDefFoundError: com/google/gwt/dev/util/StringKey
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2804)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1144)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1639)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1517)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.validateProxy(RequestFactoryInterfaceValidator.java:1594)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.validateEntityProxy(RequestFactoryInterfaceValidator.java:828)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.maybeCheckProxyType(RequestFactoryInterfaceValidator.java:1540)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.getDomainType(RequestFactoryInterfaceValidator.java:1374)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.createDomainMethod(RequestFactoryInterfaceValidator.java:1192)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.checkClientMethodInDomain(RequestFactoryInterfaceValidator.java:1079)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.validateRequestContext(RequestFactoryInterfaceValidator.java:909)
at com.google.web.bindery.requestfactory.server.RequestFactoryInterfaceValidator.validateRequestFactory(RequestFactoryInterfaceValidator.java:964)
at com.google.web.bindery.requestfactory.server.ResolverServiceLayer.resolveRequestFactory(ResolverServiceLayer.java:187)
at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveRequestFactory(ServiceLayerDecorator.java:172)
at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveRequestFactory(ServiceLayerDecorator.java:172)
at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveRequestFactory(ServiceLayerDecorator.java:172)
at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.resolveRequestFactory(ServiceLayerDecorator.java:172)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.google.web.bindery.requestfactory.server.ServiceLayerCache.getOrCache(ServiceLayerCache.java:233)
... 32 more
Caused by: java.lang.ClassNotFoundException: com.google.gwt.dev.util.StringKey
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1672)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1517)
... 57 more
There's a fix for this on its way over from RC to trunk. In the mean time, remove gwt-servlet from your dependencies and use requestfactory-servlet.jar instead.
I've always understood gwt-dev.jar to be the compiler and other development tools. If you believe that, there should be no dependency on it from your own code, and there is no reason for it to be in the WEB-INF/lib folder of your war file.
I see from this question that at least one other contributer to SO feels the same way, but the belief doesn't appear to be universal.
I'll update this answer if I can find anything one way or the other in the GWT docs.
Update:
The closest thing I could find was Organize Projects which shows gwt-dev as a referenced library not present in WEB-INF/lib. I can't find anything official that says either that you can or can't deploy it to your web server. In an old book GWT In Action (Hanson, 2007), page 551 says
You should never deploy the gwt-user.jar and gwt-dev.jar files to your server,
because they will interfere with your server; these JAR files contain their own
Tomcat server code, which is used when you're testing in hosted mode.
This is clearly out of date, since hosted mode isn't called that anymore and uses an embedded Jetty server rather than Tomcat, but that's the basis for my belief.
Ok I made it working :)
I used the gwt version compiled from here:
http://code.google.com/p/google-web-toolkit/source/browse/#svn%2Freleases%2F2.4
I did put gwt-servlet.jar and requestfactory-servlet.jar as dependencies in my project. The problem in the other thread occured because I used my own group-id for the compiled jars, so these were not used by gin and the gwt-maven-plugin. No everything works fine :)
Thanks for the help though!!
i am building a GWT project, with GWT-2.0.3 and eclipse plugin.
well, first i tried, JSTL1.2 and servlet 2.5,
i do add 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">
in 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 the core 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 deploy the project to Tomcat 6, it works fine. i search on the web, and i find a article, "JSP Expression Language in GWT’s embedded Jetty", so i tried jstl-1.1 and servlet2.4, but i still get that exception.
i find the GWT's jetty server version should be 6.1, but i am not sure about it, if that is true, it should support EE5, so any one has integrated GWT and JSTL? please help! thanks.
I'd recommend just switching to an external Java server (like Tomcat, which you seem to have installed and which works with your configuration) - much less problems, easier than trying to work with the crippled Jetty that comes with GWT.
The instructions can be found in the docs. If you stick with GWT's Jetty, you will only run into more issues in the future.
Update, see comment by Pascal Thivent below:
#Pascal: sorry for that, I didn't mean to just say "Switch to external server, no talking", it's just that I've seen a lot of people on SO and on GWT's Google Group that have problems configuring Jetty that comes with GWT - in some cases it's because the configuration is somewhat different than standard, because the GWT team included an older/modified (I can't get any solid info on this) version of Jetty, for example see this post and comments there, some quotes:
NOTE: I believe the version of jetty
shipped with GWT is below 6.1.12 and
therefore you must leave off the first
parameter in the example docs as it
was added in jetty 6.1.12rc3. See the
note at the top of the Jetty documents
page.
Supposedly Jetty supports the servlet
2.5 specification and resource injection via the web.xml entry or
#resource annotation. However, I have
yet to figure out if this is supported
by the Jetty version shipped with GWT.
If anyone has figured out whether or
not this works and if so how it is
done please let me know.
Other problems occur when someone wants to use EJB.
All that (maybe in a more condensed/cryptic way) is written in GWT's documentation - for which I provided a link above to the exact paragraph addressing this issue.
Hopefully, that cleared up some things - switching to an external server just seems like the easiest, simplest and best solution - no "special GWT" configuration, meaning you can use the same configuration/server that you'll be using in production, no need to migrate your configuration to, for example, Tomcat, no unexpected bugs after migration, etc.
I stumbled on this while I was looking for fix JSTL for my app engine project. I found the answer on "Will It Play" page by google. Apparently you have to add
<%#page isElIgnored="false" %>
to your JSP pages to enable EL parsing.
I get this error too.
I've found I can fix it by moving the GWT SDK to the bottom of the classpath in the Eclipse Java Build Path -> Order and Export dialog.
However, that breaks 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 that by moving the GWT library back up the classpath, which makes it appear like you can either have JSTL or GWT Serialization working in Jetty, but not both.
(GWT 2.1, JSTL1.2 and servlet 2.5.)
java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;
The webapp's runtime classpath is likely cluttered with a different version of EL JAR file (either an older version or the one of a different appserver) which lacks the in the exception mentioned method. I suspect the /WEB-INF/lib. Get rid of it, it's normally already supplied by the appserver in question, you don't need to include it in your webapp. This applies on all appserver libraries like servlet-api.jar and consorts by the way. You should never copy it into the webapp's /WEB-INF/lib. That's asking for portability trouble.