Current DevMode -superDevMode issues for our setup

73 views
Skip to first unread message

Jens

unread,
Oct 1, 2014, 6:26:42 AM10/1/14
to google-web-tool...@googlegroups.com
Hi,

I just tried latest trunk (without Daniels upcoming automatic recompile on page reload patch) and the following describes our current setup and the issues we have with DevMode -superDevMode.


TL;DR:
- public resources are not copied to war output directory. Only app.nocache.js will be generated. We need public resources.
- the generated app.nocache.js of DevMode -superDevMode does not set all binding properties so SDM fails because more than 1 permutation has been detected. In our case GWT "locale" and one of our properties is not defined with a default value.


We use GWTs "public" folder feature quite a bit and rely on the fact that DevMode copies the content of all public folders to the war output directory as soon as DevMode has started (without ever accessing the app through the browser).

With current state of DevMode -superDevMode it seems like that only an app.nocache.js file will be copied to the war output directory and no other public resources at all. That won't work for us because in our public folders we have an index.tpl file that will be used by a servlet to generate the GWT host page. There are also other files in our public folders that should be deployed on server like icon fonts and other stuff that is not managed by GWT ClientBundle resources.

I also noticed that the CodeServer now provides some public resources but it seems like it only provides files but not directories, for example public/robots.txt has been copied but public/fonts/* is missing. Not sure if that is intended behavior, maybe there is a bug in the resource copying code.

Now if I workaround the above issue by copying our public resources manually to the war output directory we still can't launch our app because the Recompiler (automatically started by the generated app.nocache.js file) detects multiple permutations and thus fails. The reason is that the generated app.nocache.js only defines the user.agent property and nothing more. Are we now required to change GWT module xml files to set default property values? 

So for us the only way to use SDM without issues is to not use DevMode -superDevMode and do it the ordinary "compile once, then deploy, then use bookmarklets" way.


-- J.






Jens

unread,
Oct 1, 2014, 7:53:57 AM10/1/14
to google-web-tool...@googlegroups.com
Now I have applied Daniels patch to always recompile on reload. The situation is now:

- Resources from public folders are still missing so I need to copy them manually
- the generated app.nocache.js file of DevMode -superDevMode correctly sets all permutation properties so the first compile works now
- recompiles on page reload work well

The only other thing I noticed is that the RemoteServiceServlet always uses localhost to fetch GWT-RPC policy files. However we sometimes need to access our app via IP (e.g. access local dev environment from IE browser in a VM). If we do so, the code server must also run on that IP because the new app.nocache.js file constructs the recompile URL based on the current hostname of Window.Location. However that means we must override RemoteServiceServlet.getCodeServerPolicyUrl(). While doing so I noticed that the variable RemoteServiceServlet.codeServerPort is private. I think we should make it protected or add a protected getter to access it so it can be used in RemoteServiceServlet.getCodeServerPolicyUrl().

Alternatively we could introduce gwt.codeserver.ip system property instead and fallback to localhost if it is not specified.


So I would propose the following changes:

- Make sure ALL public resources (files + directories) are copied to war output directory once DevMode -superDevMode has been started
- instead of hard coding localhost in RemoteServiceServlet.getCodeServerPolicyUrl() we should introduce gwt.codeserver.ip system property and fallback to localhost if it is not specified. Alternatively make codeServerPort accessible in sub classes of RemoteServiceServlet. However I would prefer a new system property because thats what I would have implemented anyway if I would need to override the method.


-- J.
Reply all
Reply to author
Forward
0 new messages