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
For additional commands, e-mail: users-h...@tomcat.apache.org
