litesoft
@ HEAD
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
<!DOCTYPE html>
<html><head><title>Community Edition and Debugging & "war" pollution & Versioned Static w/ DevMode.</title></head>
<body>
<center>
<h1>Community Edition and Debugging & "war" pollution &<br> Versioned Static w/ DevMode.</h1>
</center>
<p>
When you run: <b>com.google.gwt.dev.DevMode</b>
<p>
You have to tell it the "path" to the "gwt.xml" "module" file. This file's location is the "module directory".
<p>
DevMode assumes that your supporting resources are either already in the "war" directory, or are in the "public" directory (in the "module directory").
<p>
When DevMode executes it drops the GWT generated files into the appropriate war sub-dir, and then copies everything in the "public" directory into the war directory.
<p>
As you can imagine, between the GWT generated files, and the files copied from the "public" directories (especially if you are using supporting code/libraries with their own "public" directories - like my almost <b>1400</b> files), GWT makes quite a mess of the war directory.
<p>
Managing the separation of the GWT DevMode "droppings" and the files that HAVE to be there (and in source control) e.g. "WEB_INF/web.xml" would be quite a problem (especially from source control perspective).
<p>
If we could limit the GWT DevMode "droppings" to just the GWT generated files, and we could serve all the other resources (the ones from the "public" directories) directly from the source controlled resource dirs, then we would gain two advantages:
<p>
<ol>
<li>The war directory is now polluted "only" with the GWT generated sub-dirs (which can be source controlled Ignored)</li>
<li>Changes to the other resources can be seen in real-time (without the need for GWT to recopy them - i.e. restarting)</li>
</ol>
<p>
To accomplish this we need to do three things:
<p>
<ol>
<li>Move all the resources in the "public" directories to directories that GWT does not process by default - e.g. "warResources" </li>
<li>Tell the "VersionedStaticContentFilter" that it should look in these new directories for requested resources</li>
<li>Put the LocationAnchor.jar into the "WEB-INF/lib" directory under your war directory **</li>
</ol>
<p>
To tell the "VersionedStaticContentFilter" that it should look in additional directories, they must be specified in a System.Property (paths are relative to the war directory), like:
<p>
<ul>-DDevMode=../warResources|../../GWTshared/warResources
</ul>
<p>
The above indicates that if a requested resource is not found in the war directory, look in the "local" warResource directory, and if still not found, then look in a "peer" project called "GWTshared" in its warResources directory.
<p>
<p>
** - The LocationAnchor.jar allows the "VersionedStaticContentFilter" to locate the war directory at runtime. The code for this is:
<ul>
<pre>
package org.litesoft.locationanchor;
@SuppressWarnings({"UnusedDeclaration"})
public class LocationAnchor
{
public String toString()
{
return getClass().getProtectionDomain().getCodeSource().getLocation().toString();
}
}
</pre>
</ul>
and the code that uses it in VersionedStaticContentFilter is:
<ul>
<pre>
private String getLocationAnchor() // e.g.: file:/C:/zDev/litesoft/GWT_Sandbox/UIdesign/war/WEB-INF/lib/LocationAnchor.jar
{
try
{
Class<?> zClass = getClass().getClassLoader().loadClass( "org.litesoft.locationanchor.LocationAnchor" );
return zClass.newInstance().toString();
}
catch ( Exception e )
{
e.printStackTrace();
return null;
}
}
</pre>
</ul>
from the above you can see that it is relatively easy to extract the war directory, as it is the path up to (excluding) the "/WEB-INF/" sub-string.
</body>
</html>
|
Diff
GeorgeS
View complete history
Commits RSS feed for