Updated WAR design for GWT 1.6

[BobV]

Scott, Miguel, Kelly, and I sat down today to try to resolve some of
the problems with the existing "WAR" deployment design. Here is our
strawman proposal for how it should work in the future (we can go into
more detail on the rationale). Note that legacy mode would be
supported for 1.6 to maintain backwards compatibility.

Either:
1a) A new tag in GWT modules to specify a subdir in the output folder
to deploy into, something like: <deploy-path value="/shortName" />
- This specifies a subdirectory inside your WAR directory that GWT
should output public files (and compiled files) into. For backwards
compatibility, the default value if this tag isn't specified will be
the fully-qualified module name.
- Our project creator could emit a either a module short name, or a
constant name (such as "gwt" or "compiled").
- A user could also specify "/" to dump the output directly into the
top level of the WAR directory.
- <deploy-path> tags are inherited and last-one wins.

or:
1b) A new attribute "deploy-path" on the <module> tag.
- As above, except that the value is not inherited.

2) GWTShell (or another entry point) requires you to specify the
modules you care about on the command line. This is critical because
during hosted mode development, we need to create a map of deploy-path
-> module name. It also breaks potential circular dependencies
between static html files and public resources. It also gives an easy
answer to "What does Compile/Browse do?" in hosted mode.

3) The GWT module <servlet> tag is deprecated; it only works in legacy
mode and is ignored (or generates a warning) in WAR mode. Instead,
you should configure servlets in your web.xml.

--
Bob Vawter
Google Web Toolkit Team

[Scott Blum]

Hearing no objections, we implemented this. :)

[Miguel Méndez]

Can we get a patch?

--
Miguel

[John Tamplin]

On Thu, Oct 30, 2008 at 9:38 AM, Miguel Méndez <mme...@google.com> wrote:

Can we get a patch?

svn sw http://google-web-toolkit.googlecode.com/svn/releases/1.6

--
John A. Tamplin
Software Engineer (GWT), Google

[Scott Blum]

Yeah, sorry.. we checked it into the 1.6 branch.

On Thu, Oct 30, 2008 at 9:38 AM, Miguel Méndez <mme...@google.com> wrote:

[Ray Cromwell]

On Wed, Oct 29, 2008 at 8:00 AM, BobV <bo...@google.com> wrote:

> 3) The GWT module <servlet> tag is deprecated; it only works in legacy
> mode and is ignored (or generates a warning) in WAR mode. Instead,
> you should configure servlets in your web.xml.

Does WAR mode offer the same inheritance benefits? What I mean is
this: Today, I provide a servlet that accompanies the
Chronoscope.gwt.xml module. Chronoscope itself has no entry point, it
is a module made to be inherited. Any GWT module that inherits
Chronoscope would get servlet config inherited with no need to
configure anything. "It just works" And with the gwt-maven plugin I
use, the <servlet> module descriptors are merged into any web.xml on
behalf of the user, again, hassle-free module inheritance.

With a pure module like Chronoscope, which has no entry points, but
does have servlets, I'm unsure if it even needs a web.xml. If I
provided one, and another project inherits from Chronoscope, and has
its own web.xml as well, how do the two web.xml instances interact?
Does the entry point module's web.xml win? This then seems to require
that the developer scan the jars of every module he inherits looking
for servlets so that he can add them to his web.xml

I don't know what the solution is, but I kinda liked the <servlet>
module tag and it's ability to be picked up by inheritors.

-Ray

[Scott Blum]

Ray, it's a great point you raise.  And it's possible my wanting to deprecate it is in some way related to not wanting to solve the problem of merging into a user's existing web.xml.  For parity between hosted and web mode, I feel like if we continue to support servlets, the compiler needs to hand this (as well as hosted mode).

There is a possible security motivation, however, for not doing this.  I think it's slightly better if a developer explicitly includes your servlet in their web.xml.  Otherwise, just by inheriting your module (and future tools might make it very easy to download/install/inherit someone's module off the web) they are, perhaps without realizing it, setting themselves up to run your code on their production servers.  Not only that, but as a servlet, their code can be controlled directly from the web.  I'm imagining someone slipping in a <servlet path="/__hax__" class="im.in.ur.datacenter.pwning.ur.Server" />.

[Bruce Johnson]

perhaps the solution to the security concern is just to somehow be
more clear what your actual endpoints are as a function of the modules
you've inherited. maybe some sort of click-through acknowledgment? the
compiler could even dump out the list when you compile.

[Rajeev Dayal]

Hey all,

Sorry to derail from the security question that is being debated, but I wanted to mention some of my observations as I've been playing around with the DynaTable2 sample.

If the "-out" directory is unspecified, the application fails to launch. I think this is probably because it is looking in the same directory as the ".project" file, which does not contain a "WEB-INF" directory. We can probably rectify this by choosing a better default if "-out" is unspecified, such as "war".

Along the same train of thought, if the directory specified by "-out" does not exist, then the application will fail to launch. We could probably add a simple sanity check for this.

Finally, I noticed that the DynaTable2 Eclipse project has the war/WEB-INF/classes directory as its output directory. If you are manipulating this directory from the command line, and you blow away the classes directory, you have force a rebuild in Eclipse in order to populate this necessary directory before launching the application. I guess it is just a bit odd to me that the "-out" directory, which was previously only used for output, now is considered to be an "input" directory as well.

Rajeev