> Le 25 juin 2015 à 21:45, Pascal Abaziou <pascal.abaz...@gmail.com> a écrit : > > >> Le 25 juin 2015 à 10:40, André Warnier <a...@ice-sa.com >> <mailto:a...@ice-sa.com>> a écrit : >> >> Pascal Abaziou wrote: >> >>>> Le 25 juin 2015 à 00:23, Mark Eggers <its_toas...@yahoo.com.INVALID >>>> <mailto: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. >> >> You should also decide if you call them redhat or redhead... Their logo >> quite clearly has a white head and a red hat. >> >> Maybe in defense of the sysadmins, despite what I said earlier, and to show >> the other side of the coin : it is inherently sweet for a sysadmin who has >> to manage a non-trivial number of Linux systems, with a non-trivial number >> of software packages installed on each, to be able to rely on a simple >> single command to update a software package from a repository, and have a >> supposedly "stable and secure and compatible-with-everything-else" version >> installed as a result. And, to be able to blame someone else if it is not >> so. That's why people pay for redhat Enterprise support after all. >> >> This is a perpetual and unresolved debate on this list, because of course >> the point of view of developers is different from the point of view of >> sysadmins. >> But they each need one another, so the debate generally remains polite... >> >> ------------- >> >> Maybe still an addendum on a specific point above, as an illustration : you >> mention that you requested a Tomcat 8. That implies Java 7 minimum. Which >> maybe then conflicts with other Java-based packages on the same system, >> which may not have (yet) a Java 7 compatible/tested version in the redhat >> respository for that same redhat Linux release. >> Things can quickly get out of hand there, from an overburdened sysadmin's >> point of view. >> >> A number of our corporate customers have the following policy : >> - either their IT dept. provides a system with redhat/Suse/whatever >> Enterprise Linux and all the packages that we request, in the version that >> corresponds to the package repository of ditto Enterprise version. In that >> case, they do the maintenance and support of the system. >> - or we install some version of a package which is not from their official >> repository. They do not forbid this, but in that case they wash their hands >> off the system, and it becomes *our* burden to maintain and support it (for >> everything). >> >> It is a bit frustrating as an external software vendor, but from my own >> part-time sysadmin's point of view, I would tend to say "fair enough". >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> <mailto:users-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: users-h...@tomcat.apache.org >> <mailto:users-h...@tomcat.apache.org> > Thanks, > > I understand the policy of sysadmin (and more of some in our team as we have > other topics — without bugs but features like selling— not related to tomcat > to solve and I am more for the admin position on the subject), but in this > case, it’s about 2 bugs. We found a workaround for the other. For this one, > if it hase impacts on the dev it will be more tricky to deal with. > > oh and for redhat (and not redhead), it’s my e-mail client that did automatic > « correction » : I revert one but didn’t see the last one.
Oh and we do use Java 8 (and we really use Java 8 features) : a very good help to implements the features we were asked to deliver. Regards, Pascal
