From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Description of problem:
The update from mx4j broke tomcat v4.1.27 as supplied by jpackage,
causing a major outage on a production system.
Even though JPP is an external project to Redhat, the Redhat packages
still need to "play nice", otherwise decisionmakers will lose faith in
up2date on live systems, and we're back to security hole hell.
The fix is to revert back to the JPP provided RPM of mx4j.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Only Red Hat signed packages are supported on RHEL3 systems.
Tomcat (5 only) support will be provided as part of out RHAPS
(Application Server) offering.
Tomcat 4 was in the Beta (unsupported) version of RHAPS. If you think
Tomcat4 should still be supported please tell your representative so
he/she can pass this request to Marketing.
Ask you sales representative about RHAPS.
The problem was not whether something was supported or not, but
whether Redhat were responsible enough during software releases to
ensure their releases "played nice" with others in the marketplace.
If it turns out that automatic updates break production systems, then
we will abandon the use of automatic updates on our systems, and in
turn probably abandon the RHEL distribution for a vendor that takes
software releases more seriously.
If Redhat's approach to this issue is to just refer the customer to
marketing, then we will be considering a competing product in future.
How did it break it exactly? Did the JPackage mx4j get overwritten?
Redhat released mx4j-1.1.1-6, which is technically later than JPP's
most recent release mx4j-1.1.1-5jpp.
The JPP release of tomcat does not detect the jar files from
mx4j-1.1.1-6, which caused it to fail to start on its next invocation
after the update.