With the exception of engine.js in DWR 2.0, all the script files that DWR produces are static. They can be safely extracted, combined, compressed and cached.
With DWR 1.0 this was a manual process. DWR 3.0 will handle compression and caching automatically.
If you are using DWR 2.0 in a bandwidth sensitive environment, you might benefit from using a static version of engine.js
DWR version 1.x did not support Reverse Ajax, so engine.js was static by default. DWR 3.0 will automatically fetch the dynamic data, so engine.js can be static once more. Previews of release are available either from the DWR download pages at java.net or from CVS.
If you are using 2.0, there are 2 routes you can take to caching engine.js. One if you need Reverse Ajax, and one if you don't.
It's also worth checking out JAWR which includes DWR integration. JAWR is a packaging and compressing library for serving JavaScript and CSS.
The following steps will break ScriptSessions and Reverse Ajax, but are a simple way to cache engine.js.
http://localhost:8080/[YOUR-WEB-APP]/dwr/engine.js. This should be saved into your web directory.The procedure here is slightly more involved. You need to split engine.js into 2 pieces, one small dynamic, the other larger, static.
The engine.js in dwr.jar should now look something like this:
dwr.engine._origScriptSessionId = "${scriptSessionId}";
dwr.engine._sessionCookieName = "${sessionCookieName}";
dwr.engine._allowGetForSafariButMakeForgeryEasier = "${allowGetForSafariButMakeForgeryEasier}";
dwr.engine._scriptTagProtection = "${scriptTagProtection}";
dwr.engine._defaultPath = "${defaultPath}";
dwr.engine._pollWithXhr = "${pollWithXhr}";
The rest of engine.js can then be combined with other scripts, and compressed, as for the non reverse-ajax version.
This is much harder than we would like it to be. During the development of version 2.0 we realized that the correct solution was trickier than we had time for during the 2.0 time-frame. So we chose a solution that would work without breaking changes across versions 1, 2 and 3, but that still allowed advanced users to customize their 2.0 builds.