Hash: SHA256


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

> 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.


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.

- -chris
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to