> Le 25 juin 2015 à 10:40, André Warnier <a...@ice-sa.com> a écrit : > > Pascal Abaziou wrote: > >>> 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. > > 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.
