On 14/05/2013 20:55, Christopher Schultz wrote: > On 5/13/13 3:35 AM, Mark Thomas wrote:
>> I've updated the proposal to cover these. > > Cool. Having all the rules in one place will be tremendously helpful to > users. Even if they disagree with the rules, they will at least be > predictable without having to read the code. Indeed. > IIRC, it used to be that Tomcat would unconditionally expand the WAR > file "for performance reasons". Are those performance reasons no longer > considered warranted, or has "expandWars" been added so that deployers > who don't want anything written to the disk can have their way? unpackWARs has been present for as long as I can remember. Certainly from Tomcat 4 onwards the intention was that a web app could be a WAR, a directory or served from anywhere such as a database. > I'm wondering if a somewhat reasonable change might be to deploy the > "true" webapp into the work/ directory to resolve these conflicts. So, > for instance, deploying a WAR file would result in the expansion of the > WAR file into the work/ directory instead of into webapps/, while > deployment of a DIR would copy to work/ and serve from there. That way, > you don't have to worry about potentially killing a DIR when a WAR needs > to be deployed. I think that just changes the problem because a user could copy an app directory and app.war into webapps. > Of course, that could cause (further?) confusion between the behavior of > WAR, DIR, and work-DIR for users trying to track-down some obscure > change they (think they) made and why they can't get it to show up in > their webapp. Indeed. We see this when the various anti-resource locking options are used. I think keeping the process as simple as possible is the way forward, both for user understanding and simplicity of code. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
