Hi Thomas, Hi all, I've recently studied and "hacked" the code server and I have grown an opinion about this, let me share some thoughts.
I do prefer too that Jetty get stripped off from GWT, I find generically the same issue of Luis and Bendg; it is true there are many ways to work around these issues, but it can get very annoying in the end. In my studies I have "hacked" the code server, and I've noted that the codeserver's com.google.gwt.dev.codeserver.WebServer is the class responsible of depending on Jetty. It basically creates an anonymous Servlet and start it with an embedded Jetty, but it is all merged on a single class with many responsibilities and it is very hard to reuse. Well, the good news is that even if Jetty has very bad records of backward compatibility, the servlet standard has a very good one, and I think that if we split the CodeServer's Servlet from the Embedded Jetty Server implementation, anyone can get happy. This is not an hypothesis, I've actually made it working: I have created a pure servlet, extracted from WebServer, that provides the code server functionality. I've been able to run this servlet on the Jetty version that I prefer (Jetty 9.2.11.v20150529), and moreover, I've used a single embedded Jetty server, written by myself that run both the GWT application and the Code Server's servlet. This CodeServer don't runs on port 9876, it runs instead on sub-path /dev-mode, same port. With this configuration, I've achieved another goal (well, actually it was my primary one): I've been able to use the SSO linker with SuperDevMode (with limitations, I need to open manually the url http://localhost:*8888*/ *dev-mode* /recompile/my_module?_callback=__gwt_sdm_globals.callbacks.c1444718136184 <http://localhost:8888/dev-mode/recompile/my_module?_callback=__gwt_sdm_globals.callbacks.c1444718136184> to trigger recompilation, and the SuperDevMode compiled Javascript is included with a script tag like <script src=" dev-mode/my_module/wunit_logic.nocache.js <http://localhost:8082/dev-mode/wunit_logic/wunit_logic.nocache.js>"></script> - anyway this can be improved and automated easily). Another relevant consideration is that with these configuration, I've been able to develop and debug (server side for the moment) GWT *without the Eclipse Plugin*: I think next generation of GWT should follow such approach, that it is inspired on what the Wicket framework provides: if you try to create a Wicket archetype (use this command: mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.0.0 -DgroupId=org.example.jetty.embedded.wicket.check -DartifactId=check-wicket-embedded-jetty -DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false), you'll see that it creates an embedded Jetty server in test sources, and it can be started in Eclipse as any regular Java application. If GWT would follow the same approach, it could create an embedded jetty server that also starts a CodeServer Servlet, or maybe a Servlet Filter that intercepts Javascript requests for GWT's *.nocache.js files and recompiles them on the fly. I don't have "clean" code to share, but if there is interest I can share these modified classes or describe the modification I've ade (note though I'm not using this code in production, I've just hacked it while studying the feasibility of some other PoC using SSO linker). If I reach some more concrete results, I'll show them to the GWTcon in Florence next 11 november, where I hope to meet and discuss about these topics with a wide community. Hope this is interesting, have a nice day, Cristiano -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
