https://issues.apache.org/bugzilla/show_bug.cgi?id=57251
--- Comment #11 from Mark Thomas <ma...@apache.org> --- (In reply to Francisco A. Lozano from comment #10) > The deploy/redeploy tooling we have had around since tomcat 6 works that > way, and it's easier to manage just a WAR file in webapps than a WAR file > and a exploded directory. I seem to recall that keeping them in sync was > problematic, as tomcat may be down when the WAR is reinstalled. Yes, that can be a problem. Tomcat doesn't detect that the WAR is newer than the exploded directory. > I think there is value in existing tomcat6/7 behaviour - the "interface" > that users have to deal with is just simpler, and it makes it more difficult > to shoot yourself in the foot without paying performance penalty. Keep in mind you are still paying the performance penalty for at least the first load all your static resources (although they are normally then cached in memory which will help until the cache expires). > In T8, the current options are either large performance penalty paid or > having to deal with a slightly more complex deployment. > > I understand the 'unpackWARS="false" really should mean exactly that' > statement, but existing behaviour in T6/7 is valuable and is relied upon - > so maybe the new 'really don't unpack anything' behaviour could be a > separate feature, but existing one in my opinion should still be available. That would mean adding back in the "unpack the JARs anyway if unpackWARs is false" feature which is do-able but would add complexity to an area where I have been trying to reduce it. Given the use case, I'm wondering if making Tomcat's auto-deployment code smart enough to detect that the WAR has been updated even if Tomcat is not running might be a better solution. Something along the lines of a file in the work directory configured with the same last modified time as the WAR. A simple comparison of the last modified time of the two files tells Tomcat if a redploy is required on start. I did think about caching the JARs in memory (probably only during web application start) but for some applications that could mean significant increases in the memory footprint just to start. I suspect this might cause as many problems as it solves. Overall, I'm leaning towards a position of finding a better solution to the use cases that mean folks opt to run with unpackWARs set to false. I'd be interested in hearing if there are any other use cases. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
