Re: Next release

On Tuesday, October 20, 2015 at 8:50:39 AM UTC+2, Cristiano wrote:

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

Actually, Goktug (IIRC) once suggested (months ago) such an evolution of SDM, to work as a pure servlet within the webapp.

But now you just brought ECJ/JDT inside your webapp classloader, where it's likely to conflict with any ECJ/JDT version you could be using within your app (see https://github.com/gwtproject/gwt/issues/5289 and https://github.com/gwtproject/gwt/issues/4479 for the reverse: people putting their server-side deps in GWT's classpath and seeing conflicts); and I'm not even talking about possible dependencies of your client libraries, particularly those used in generators or linkers (e.g. Arcbees like to use Velocity for code generation in their generators).

So to work cleanly, SDM would have to be a webapp with its own isolated classloader, rather than a servlet. And we'd have to find a way to pass "arguments" to the webapp (system properties? servlet context init parameters? maybe both?)

Note however that this is apparently not the way j2cl will work (a priori, from what we know), as it'll more likely run as/in a process watching for file changes and continuously re-transpiling changed files, similar to what you'd do with SASS, LESS, CoffeeScript, TypeScript, etc. (some of them can work directly in the browser too); and possibly would just integrate seamlessly with gulp/grunt/etc. to use their own "watch" feature.

--
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+unsubscribe@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.