Thank you Mark. I mainly wanted to have answers for when I will be invariably questioned about it. :-). I knew about the naming, but understand that these aren't recompiled for each release, so modifying the version wouldn't work. (file/properties)
Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Wednesday, September 28, 2022 1:57 PM > To: users@tomcat.apache.org > Subject: Re: OT: Question about TomcatX.exe files > > On 28/09/2022 18:36, jonmcalexan...@wellsfargo.com.INVALID wrote: > > Ok, this is a silly off-topic question, but is there an underlying reason > > that > the wrapper exe files for Windows Tomcat do not reflect the same file > version as the implementation version found in the manifest of the > bootstrap.jar? That version info matching the release version of the Tomcat > release? I understand if these wrappers aren't recompiled each release, but > if they are, why not make the versions reflect the Tomcat release? > > > > This seems to throw a loop at 3rd party software discovery tools such as > BigFix, ServiceNow, etc., as well as normalizations performed by vendors like > Flexera. > > Those files are renamed Procrun files from Commons Daemon. > > The filesare never compiled as part of a Tomcat release (we use the binaries > from Commons Daemon) but they can be renamed to anything you want but > note the next point. > > The file name reflects the default service name so you don't have to specify > the service name every time you call the executables. > > The default service name is TomcatX where X is the major version. This > allows the service name to stay the same across minor and point release > upgrades. Renaming the service every time you upgrade is likely to cause > other issues - e.g. for software monitoring the service. > > Other naming schemes are possible. The current scheme seems to provide a > reasonable solution for the majority of users. That said, if the community > disagrees, it can always be changed. > > Mark > > > > > > Just curious. > > > > Thank you for your time. > > > > Dream * Excel * Explore * Inspire > > Jon McAlexander > > Senior Infrastructure Engineer > > Asst. Vice President > > He/His > > > > Middleware Product Engineering > > Enterprise CIO | EAS | Middleware | Infrastructure Solutions > > > > 8080 Cobblestone Rd | Urbandale, IA 50322 > > MAC: F4469-010 > > Tel 515-988-2508 | Cell 515-988-2508 > > > > > jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com> > > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you > for your cooperation. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
