https://issues.apache.org/bugzilla/show_bug.cgi?id=51294
--- Comment #21 from Mark Thomas <ma...@apache.org> --- (In reply to comment #19) If the requirement is to just copy the WAR, deploy it as ROOT and retain version information in the file name you can name the file ROOT##version-information-here.war The version marker after the ## is used in parallel deployment but it can still be used even if you have a single version deployed and specifying it in that case has no negative consequences. > Why not just make the whole process straight forward? I'd love to but you aren't the only user of Tomcat. What might seem simple to you may be the exact opposite of what another user wants. > What are all of these features not uniform and straight forward? I do think there are issues with clarity and consistency with automatic deployment. This stems from a lack of definition of how automatic deployment is meant to behave (particularly around the many edge cases) and also from the changes over time that have tried to address the issues for one group of users that have usually created problems for another. > I don't think the problem is external vs internal unpacking. Then you haven't fully understood the problem. There are additional edge cases created by supported unpacking of external WARs that need to be thought through. > What would be super straight forward and simple is. Copy the war file up to > a folder (maybe webapps, any folder, etc), and deploy a config file (like a > context file) that can map the war file to a URL including ROOT path, > specify if a war file should be unpacked or not, redeploy, etc. Breaking the linkage from XML / WAR / DIR name to context path creates multiple problems for automatic deployment around name clashes that would require far more complexity to solve. I don't see any implementation along those lines ever being accepted. > It just so straight forward it makes me want to cry that TC right now is so > confusing with all of these terrible options we have. If you make the > process straight forward the code will clean itself up because it's simple. I agree a simple process will result in simple code but what you are proposing is not simple. > I think TC has so many options for deployment that are worthless it made the > code complex. Again, you are not the only user of Tomcat. There are other users that do find the features useful and they presented a strong enough case to the community to convince the committers that the feature would be of useful. > It's just you took away one of the useful features for bad reasons. I removed an undocumented feature you had been relying on because of the complications is caused for automatic deployment. You might not like that decision but the tone of your comment is not likely to help your case. I'd like to remind folks reading this that this is open source with an open development process. If you want to see this enhancement request implemented, constructive contributions are far more likely to achieve the results you desire. A discussion [1] is already underway on the dev list about proposed changes [2] to automatic deployment covering: - creating a clear definition of the expected behaviour of automatic deployment - ensuring that the behaviour of automatic deployment is logical and consistent - implementing this enhancement request If you want to move this enhancement request forward, constructive contributions to that thread and constructive criticisms of the proposed new behavior are the way to do it. [1] http://tomcat.markmail.org/thread/zmcxxfqbb3p4qft5 [2] http://people.apache.org/~markt/dev/auto-deployment-proposed.txt -- 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
