has anyone an idea, how to run my app in DevMode with a working WebsocketConnection?
First I thought the missing jetty jars (websocket, continuation, http, io, server and util) were the reason for errors, because when i compiled the app and put it on an external jetty, there was no problem with WebsocketConnection.
So i searched for them and added them to my project.
But now everytime i start it in DevMode i get an exceptionlike this:
[WARN] /testchat/WebSocketChatServlet
java.lang.NullPointerException
at org.eclipse.jetty.websocket.WebSocketFactory.upgrade(WebSocketFactory.java:197)
at org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket(WebSocketFactory.java:304)
at org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
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)
[ERROR] 500 - GET /testchat/WebSocketChatServlet (127.0.0.1) 3129 bytes
The Jetty team is only too happy to help Google port GWT to jetty-7. We have actually contacted them several times about it over the space of a couple of years, including sending along code, however we've never had a response from them. So Google, if you're listening, we're here to help :)
Jan
DevMode's embedded server is Jetty 6, which doesn't support WebSockets. Google tried to upgrade it to Jetty 7 a couple years ago, but there were issues with classloaders that they couldn't work out.
The only way to use WebSockets is to use an external server (or, if you can solve the classloading issues, write your own ServletContainerLauncher) and run DevMode in -noserver mode.
See Using my own server in development mode instead of GWT's built-in Jetty instance
Related
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
I have a Rest Web service deployed on Glassfish 3.1.2. I sporadically get a particular exception on it.
[#|2012-12-20T10:48:33.796+0530|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=28;_ThreadName=Thread-2;|StandardWrapperValve[Jersey REST Service]: PWC1406: Servlet.service() for servlet Jersey REST Service threw exception
org.codehaus.jackson.map.JsonMappingException: WEB9031: WebappClassLoader unable to load resource [java.util.TimeZone], because it has not yet been started, or was already stopped (through reference chain: spreadsheet.Exceldatalist["globalContext"]->spreadsheet.GlobalContext["dateOfCreation"])
at org.codehaus.jackson.map.JsonMappingException.wrapWithPath(JsonMappingException.java:218)
at org.codehaus.jackson.map.JsonMappingException.wrapWithPath(JsonMappingException.java:183)
at org.codehaus.jackson.map.ser.std.SerializerBase.wrapAndThrow(SerializerBase.java:140)
at org.codehaus.jackson.map.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:158)
at org.codehaus.jackson.map.ser.BeanSerializer.serialize(BeanSerializer.java:112)
at org.codehaus.jackson.map.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:446)
at org.codehaus.jackson.map.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:150)
at org.codehaus.jackson.map.ser.BeanSerializer.serialize(BeanSerializer.java:112)
at org.codehaus.jackson.map.ser.StdSerializerProvider._serializeValue(StdSerializerProvider.java:610)
at org.codehaus.jackson.map.ser.StdSerializerProvider.serializeValue(StdSerializerProvider.java:256)
at org.codehaus.jackson.map.ObjectMapper.writeValue(ObjectMapper.java:1604)
at org.codehaus.jackson.jaxrs.JacksonJsonProvider.writeTo(JacksonJsonProvider.java:558)
at com.sun.jersey.json.impl.provider.entity.JacksonProviderProxy.writeTo(JacksonProviderProxy.java:160)
at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1437)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:708)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [java.util.TimeZone], because it has not yet been started, or was already stopped
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1401)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getDeclaredMethods(Class.java:1791)
at org.codehaus.jackson.map.introspect.AnnotatedClass._addMemberMethods(AnnotatedClass.java:620)
at org.codehaus.jackson.map.introspect.AnnotatedClass.resolveMemberMethods(AnnotatedClass.java:408)
at org.codehaus.jackson.map.introspect.BasicClassIntrospector.classWithCreators(BasicClassIntrospector.java:185)
at org.codehaus.jackson.map.introspect.BasicClassIntrospector.collectProperties(BasicClassIntrospector.java:157)
at org.codehaus.jackson.map.introspect.BasicClassIntrospector.forSerialization(BasicClassIntrospector.java:96)
at org.codehaus.jackson.map.introspect.BasicClassIntrospector.forSerialization(BasicClassIntrospector.java:16)
at org.codehaus.jackson.map.SerializationConfig.introspect(SerializationConfig.java:974)
at org.codehaus.jackson.map.ser.BeanSerializerFactory.createSerializer(BeanSerializerFactory.java:251)
at org.codehaus.jackson.map.ser.StdSerializerProvider._createUntypedSerializer(StdSerializerProvider.java:782)
at org.codehaus.jackson.map.ser.StdSerializerProvider._createAndCacheUntypedSerializer(StdSerializerProvider.java:735)
at org.codehaus.jackson.map.ser.StdSerializerProvider.findValueSerializer(StdSerializerProvider.java:344)
at org.codehaus.jackson.map.ser.impl.PropertySerializerMap.findAndAddSerializer(PropertySerializerMap.java:39)
at org.codehaus.jackson.map.ser.BeanPropertyWriter._findAndAddDynamic(BeanPropertyWriter.java:463)
at org.codehaus.jackson.map.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:441)
at org.codehaus.jackson.map.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:150)
My Web service marshals an xml on the server after processing. The xml contains a time set in a tag
GregorianCalendar gc = (GregorianCalendar) GregorianCalendar
.getInstance();
globalContextObj.setDateOfCreation(DatatypeFactory.newInstance()
.newXMLGregorianCalendar(gc));
The jaxb xml object is private member var of the class, changing the access modifier from static to none is not affecting the exception. I read about the WEB9031 exception that it is caused by the classloader not being able to load the TimeZone class library. Glassfish documentation suggests that while deploying we must mention the common libraries in the console. But I have no common libraries. I think that the java.util.timezone class mentioned in the exception is getting unloaded or something like that.
If anyone has any idea to resolve this please let me know!!
According to Oracle the cause and solution of WEB9031 is:
Cause:
This problem usually indicates that the classloader of a web application was cached, and an attempt is being made to have it load resources even though the web application with which the classloader used to be associated has already been undeployed
Solution:
Make sure that the classloader associated with your web application is not cached and used beyond the lifetime of your web application
Since your problem appears sporadic, it sounds like it could be a caching issue. Personally though, I think it should be unnecessary to ask a Glassfish user to place a standard Java class (java.util.TimeZone) on Glassfish's classpath when Glassfish itself is a server for Java applications! Suggestions to mention the class containing java.util.TimeZone when starting the domain from the console might only work because it'll add the library back to the classpath.
Try stopping and starting the domain again to refresh the cache.
I'm facing the a similar problem and restarting the domain doesn't seem to be working for me. I just thought I'd suggest it to you since it doesn't sound like you tried that.
Do the following steps.
Undeploy all the applications deploy in the glassfish server.
Stop the glassfish server.
Clear the glassfish cache.(Clear the following folders contents)
$GLASSFISH_HOME/glassfish/domains/domain1/generated/*
$GLASSFISH_HOME/glassfish/domains/domain1/osgi-cache/*
$GLASSFISH_HOME/glassfish/domains/domain1/applications/*
Now restart the glassfish server.
I'm working on a GWT project in eclipse that makes calls to Apache Hive from the webpage. The architecture is something like this.
In the GWT project. the use puts a hive query on the webpage. The webpage sends this query to the server class using GWT RPC. The server makes a call to another java class in another eclipse project. This project has the hive jdbc driver, which calls hive that is running on a VM (CDH3).
I wrote a unit test that calls the GWT server class and sends a Hive query and it executes fine, but when I run he project and try to send the query from the webpage. It throws a runtime error. It seems to have some conflict with the slf4j classes included in the second eclipse project that has the Hive JDBC driver. I am guessing, there is some conflict between GWT server classes that are called at runtime and the slf4j classes included in the other project. By the way, the second project is included in the build path of the first one, but not the other way.
Here's the error:
[WARN] Exception while dispatching incoming RPC call
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract java.lang.String com.unitest.client.GreetingService.greetServer(java.lang.String) throws java.lang.IllegalArgumentException' threw an unexpected exception: java.lang.NoClassDefFoundError: Could not initialize class org.apache.thrift.transport.TSocket
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:385)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:588)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
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.content(HttpConnection.java:843)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
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)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.thrift.transport.TSocket
at org.apache.hadoop.hive.jdbc.HiveConnection.<init>(HiveConnection.java:92)
at org.apache.hadoop.hive.jdbc.HiveDriver.connect(HiveDriver.java:104)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
Your server-side dependencies have to live within the WEB-INF/lib of the GWT project (just like any other WAR).
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.