tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Hunter <>
Subject Re: WAR Files
Date Wed, 19 Jan 2000 00:00:24 GMT
> Yes, I agree the user shouldn't edit any config file or shouldn't
> unjar any file.
> ( and it's very simple to do that - using a deploy program )

I think "cp" is a file deploy program.  :-)  Copy one file to the
standard location, and things just work.  Slick!

> Expanding the war at startup is a good solution ( which should work
> with the current tomcat ).

Right, and no one but us server implementors need to know that
internally we expand it.  Think of the expansion like an on-disk cache. 

> What I don't like is the  code that tries to deal with serving out of
> unexpanded war files, and all classloader tricks ( loading a jar file
> from a jar for libs, special cases in mappings, etc).

I agree that's a pain.  Cool, but not mandatory.

> We still have most of the code in, if someone wants to fix
> it, but I would be very happy if we could just remove it -
> we have more important things to fix.

James Todd will know best on whether we should leave that code in or

> > I liked your idea of a "webapps" directory where (by default) all direct
> > subdirs were automatically treated as individual web apps.  We could do
> > the same with WAR files.  A webapps/foo.war would default manage the
> > /foo context.  No configuration would be required, unless you wanted
> > something custom.
> > What's the status of that effort, by the way?
> After we burn M1 we can start doing changes again, and since
> nobody said -1, probably the change will be done very soon.

Great!  The way I see it is that server_root/webapps is the directory
base for web apps that are to be auto-detected.  .../webapps/foo would
contain the "/foo" web app.  .../webapps/bar.war would contain the
"/bar" web app.  In case of collision with webapps/bap and
webapps/bap.war, the directory wins (cuz it's an arbitrary choice and
reading from a dir is easier because it avoids the WAR expansion).  

The server will read the contents of webapps at startup but not
afterward.  There will be no way to assign a "/multi/level" context
prefix except by editing server.xml.  

The auto-detected contexts should have default values for
defaultSessionTimeOut, isWorkDirPersistent, etc that match those
currently used for the default context.  If the user wants to override
these values, an entry can be made to server.xml.

Sound like the right approach to everyone?  Does this match what you had
in mind, Costin?


View raw message