-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 8/9/19 09:46, Mark Thomas wrote: >> Mark, >> >> On 8/8/19 08:19, ma...@apache.org wrote: >>> This is an automated email from the ASF dual-hosted git >>> repository. >> >>> markt pushed a commit to branch master in repository >>> https://gitbox.apache.org/repos/asf/tomcat.git >> >>> commit 7ac5fc8a59c10e7de1ee6d4b85c1ee797942a1e7 Author: Mark >>> Thomas <ma...@apache.org> AuthorDate: Thu Aug 8 13:17:29 2019 >>> +0100 >> >>> Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63285 >> >>> Align the behaviour of service.bat with the Windows installer >>> and rename the executables on installation (and restore on >>> removal). >> >> If I understand this patch, I might need to veto it for Tomcat >> 9. Changing for TC 10 will be okay. >> >> Re-naming the Tomcat .exe files on Windows will be a very >> surprising change for a point-release. Every installation I've >> ever worked on has multiple services running off the same Tomcat >> installation. If any of them is upgraded without adding the >> "--no-rename" option to an invocation of the service.bat script, >> all automation will begin to fail. > > As soon as a new service is installed, yes. > >> That includes services which *are not* reconfigured because the >> TomcatX.exe file will be renamed and still referenced in various >> service definitions. > > Yes. > > This is one of those cases where something is going to be broken > whatever we do. Happy to discuss options to try and minimise how > much gets broken. Help me understand how "no change" is broken. Who is adversely affected by not making any changes? > How about this as a modified approach: > > - Keep renaming back to Tomcat9[w].exe on remove. That won't > impact existing service.bat users but will help users that install > via the installer (e.g. they'll be able to change the service > name). Aha. I'm sure that has something to do with the answer to "who is broken" question. > - Change the option to --rename and only rename on install when > explicitly requested. Current service.bat users would be > unaffected and installer users would need to use this option if > they used service.bat to uninstall and reinstall the service (e.g. > to rename it) I think I like the --no-rename -> --rename option is the best because it makes the smallest change. Only currently-affected users will need to modify their behavior, instead of most users having to modify their behavior. > That should fix the reported issue while removing the impact on > the existing service.bat users. > > Thoughts? > > Mark > > > P.S. I know the 9.0.x and 8.5.x tags are overdue but I'd rather > wait a few more days to make sure we are happy with this change > before tagging and committing us to an approach. +1 I wouldn't want to put out a release where the rules are different from every other release if we are going to change --no-rename -> - --rename. In case it's not clear, I'm fully in favor of changing --no-rename -> - --rename instead of the current patch. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1Ns4MACgkQHPApP6U8 pFj6NA//ZkKtLWvNF3sByWLijbdtQlw8fTScLgWfrN2WmcJc5Y3gO+xfi89mfaPc 5We7o7F0pNmyYAF1ndyk4myKXju7tg6RPYEnfEm2sOv1UajOD7PIeFKC5WCnp4hn A6npiA4uXzDeEm8hTbdV9e1bIvZnx2xtivzD1tYvJpuctvjmb7ktK+hGw0SVNWxI zXept1kg4O8zHOp6XvGkcV7kCLitW9v0TeOwJmuIYUpjBB2J+wSnRNQZyZliUd+6 vQhrvGFzptcLE7j6ek24yKCRkCNXnBipoFnNT5GMBmjerd9w3QHvcrGefU4L1Zqk DgY1lDYaCBaAaBnPFMXPobmLhT/PbI6wVdl6s6b2sBk+fj9FZIS0bgVrb6hlBEVS GfBZPITR/HG+Bz1s4gLndNqbOZ1z/c7NpTM7smpcEnlaWSnjxQE/V90Kc4Y0cTXp +CudLWhxrqXFOEXuvngFCi1gXsvSbDqjMckcvgKfW764L1vOyNrWP4pgd/xSUJaq 0cq4q/Xw8Dhl3yBDxkG0ZLrvT9lNh9S4XKUW0WqXRSbiMmofAhSJS7bjEWnRS1sy nmxdG62EZyYaGs/8VUWz3eceUU3DqOgCtxO5nnfKC8h42bpSKJboQ1FvOO4dd5uV bkoQJrIkGopOzyGzxq5xHBVkJCxT9r/1+CRX0hJ31FNI6lJA1Bk= =02Pa -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
