Hmm generally I like having build-in proxy with GWT, as I usually use a proxy anyways at work just to mimic the production behavior (load balancers serving static GWT app files and proxy certain requests to servlet container). However I think there should be more options to be more configurable. Looking at our setup I would instantly ask for cookie rewriting (multiple ProxyPassReverseCookieDomain, ProxyPassReverseCookiePath), proxy rewrites per URL (we have multiple *.war deployed thus different contextPaths but all are accessed from the GWT app) and finally the ability to add custom headers (mostly caching, but x-forwarded-for / x-real-ip should also be there). Well and as configure options add up, a way to switch between different configurations might be handy, e.g. -configFile parameter.
Also GWT-RPC and GWT public resources should work as lot of people depend on it. I actually did a contribution to provide gwt.codeserver.host but it was abandoned in favor of writing GWT-RPC policy files to the -launcherDir on each compile. That way if -launcherDir points to an exploded war a local Jetty will just have them or you need to build the war and redeploy to a remote server (or maybe use some network share). See https://gwt-review.googlesource.com/#/c/9504/ for some discussion. Next there are people embedding the module.nocache.js file directly into their host page (like me ;-) basically our host page is a servlet) and that should work also during development. -- J. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8abc55a7-a6eb-4a55-b484-e69480aa7738%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
