Mark, On 5/13/13 3:35 AM, Mark Thomas wrote: > On 08/05/2013 15:18, Christopher Schultz wrote: > >> Perhaps I should clarify my question with an example: what happens >> when a WAR file is found and a DIR also exists with the same >> context name, but expandWars is false? Does the directory get >> updated with the contents of the WAR file, or does the WAR's >> descriptor control the deployment (subject to all the other >> behavior covered by your table(s)) and then (potentially old) >> content is served from the pre-existing DIR? > > Ah. One of the edge cases that makes this rather more complex than it > first appears. > > There are a couple of ways to get Tomcat into this state. They ways I > can think of are: > a) deploy the WAR then copy the DIR > b) deploy the DIR, stop Tomcat, copy the WAR, start Tomcat > > There may be others. > > Note for case b) if Tomcat is running, the DIR will be removed. > > In both cases what should happen is that the content is served from > the WAR and the DIR is ignored. The question is what happens when the > WAR is removed? Is the DIR removed as well? Alternatively, should the > DIR be removed as soon as it is detected? > > I'm leaning towards the DIR just being ignored but a warning logged. > That would mean: > - Content is served from the WAR > - The DIR remains but is unused > - A warning will be logged when the DIR is first detected > - If the WAR is removed, the DIR will be deployed > > There are similar questions about what happens if you have XML + > WAR(external) + DIR (expanded) and you add a WAR to the appBase? > Again, I'm leaning towards ignoring it apart from a warning when it is > first detected. > > 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. 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? 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. 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. -chris
signature.asc
Description: OpenPGP digital signature
