-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/24/2015 2:40 PM, André Warnier wrote: > Pascal Abaziou wrote: >> Hello, >> >> I’m searching for the version that fixes a bug I’ve on a tomcat >> 6.0.24 (on redhat). As I do not reproduce it on my windows >> workstation with tomcat 6.0.44, I need elements to argue to >> upgrade to the sys admin. >> >> So the bug : with a REST resource service implemented with >> Jersey, if there’s no method corresponding to a URI (under the >> hierarchy that Jersey should handle), Jersey raises a 404 >> NOT_FOUND error. >> >> In 6.0.24, tomcat raises a 500 internal error. In 6.0.44, tomcat >> propagates the 404 not found error. >> >> As the sysadmin want to stay on version delivered by redhead, I >> need elements to motivate an update. >> >> I’ve read the tomcat 6 changelog, but did not find when this was >> fixed. >> > > You know, I don't want to discourage you, but.. > > Assuming even that this was a bug that was fixed on its own, and > not some side-effect of some other change.. > > As you know, Tomcat is an open-source and free software, developed > and supported by volunteers, who apart from their Tomcat > involvement, all have a paying job which they do on the side.. > This user's list is the same. > > Tomcat 6.0.24 is at least 5 years old. The current Tomcat version > is 8.0.23. Between these two, there are 5 years and probably close > to 100 versions. Some of these versions correct real bugs or > security issues which could leave any lower version vulnerable to > hacking. > > The Tomcat developers, having a limited amount of time to dedicate > to it, rather understandably prefer to spend this time working on > and supporting the latest version, rather than very old ones. > > All of this to say that unless there is a very strong incentive for > someone to go and dig through the documentation and the code, your > chances of getting real help on this apparently minor and > peripheral issue, affecting an old version of Tomcat but not more > recent ones, are really slim. > > If your sysadmin does not understand the benefits of upgrading to > a more recent version, rather than this very old one, then the > problem is with him, not with you and not with the Tomcat > developers. Maybe you should just take the change logs, starting > with 6.0.44 and working back to 6.0.24, append them to one another, > and send this to him as a token of what he is missing in terms of > bug corrections and security fixes, by /not/ upgrading. And if he > still does not understand the issue, or cannot give you a better > reason to want to stay with 6.0.24, send the list to his boss.
There's another issue when comparing vendor-packaged versus Apache-distributed Tomcat versions. Vendors often backport various fixes from later Apache-distributed versions to vendor-packaged versions. For example, you may see the following in RedHat (I'm running Fedora 22 or CentOS 6) distributions: CentOS 6 Name : tomcat6 Arch : x86_64 Version : 6.0.24 Release : 83.el6_6 Size : 92 k Repo : updates First of all, you have to select Tomcat 6 as opposed to Tomcat on CentOS 6.6. I understand that the Tomcat 7 version is only available in the EPEL repository. Here's the information for tomcat.noarch from the EPEL repository. Name : tomcat Arch : noarch Version : 7.0.33 Release : 4.el6 Size : 86 k Repo : epel The key thing to look at in both of these listings is the Release tag. RedHat (and I suppose other vendors) release updates to their packages that include backports for certain issues. In general, RedHat addresses security issues, but avoids backporting API changes between releases of their Linux platform. It is very difficult to compare RedHat's version of 6.0.24 or 7.0.33 with the Apache release. You would have to compare both sets of change logs to find out how RedHat's release compared to Apache's release. Then, since it doesn't appear that this particular problem was uniquely identified in the Apache Tomcat changelogs, you would have to determine what change (and when) fixed the issue. Finally, you would then have to lobby RedHat to include the appropriate change into their repackaging of Tomcat. Lots of work . . . This is one of the reasons why most people on the list advocate using Apache-distributed packages. In the end, it's easier for everyone (mailing list members, Apache Tomcat users, and system administrators). As André pointed out above, this is a system administrator issue, not a Tomcat issue. If there are policies in place that preclude third party packaged applications running in production, then there are also corporate policy issues. In short, there are few reasons to stay with a vendor-distributed packaging of Tomcat, and quite a few good reasons to move to the Apache-distributed packages. . . . happily running Apache-distributed packages everywhere /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJViy3MAAoJEEFGbsYNeTwtaFsIAJ14fuK3xUnnXyCCkP3dqiwD 57TiC7vODbpp1P5g0yhWsHF6UDCykdjMcZQkez7J0Z4ioyns1xEmro9YAzi6KkKn F4kqf3cGdtNen1J7Afg5tPAUFhcu2qG77DJmX4AOS56ILPUSPOFkFc8986ioSyrM s5C2DTrqTsuL/2sRUn2nUs4KDl0eh0ZaB4Zn8m4pKsZ4zJEn+zYTkLwPoDpyg7ET ZpK+AoAEhSUM3l8fLMkOfMca3n6gt45zjDhkGAsIymChPugxpIQNMMXupA2ECkCj 6ae+dakafZMhj78taeJipTe4FTdAIEG1km4qOgz0o07bWp4RcvXbc7dssYcgOV8= =OS4B -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
