tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject Re: WAR Files
Date Mon, 24 Jan 2000 04:08:33 GMT

i'd like to see the implementation to support both internal expansion
(as it defaults today) and running from a war. the code to support
this shouldn't be that intrusive if coupled with some other refactoring
initiatives ... imho.

hope this helps,

- james

Jason Hunter wrote:

> > 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
> not.
> > > 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?
> -jh-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message