> Le 25 juin 2015 à 00:23, Mark Eggers <its_toas...@yahoo.com.INVALID> a écrit : > > -----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/
Thanks for your answers. I’ll go in this direction. We already noticed another issue between the 2 versions and so I known the current position of the sysadmin. I’ll try to argue with your infos and good advices. At the beginning of the project, we asked for a tomcat 8. But we’re beginning to have linux/redhat, and are building the « norms » to deploy on this system. So the sysadmin are not very easy to go apart of versions delivered and supported by redhead. /regards. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
