Bug 901173 (JBEWS-96)
| Summary: | Tomcat6 and tomcat7 installs the EL API package to alternatives using the same name "el_api" | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Web Server 2 | Reporter: | David Knox <dknox> |
| Component: | tomcat6, tomcat7 | Assignee: | Coty Sutherland <csutherl> |
| Status: | CLOSED EOL | QA Contact: | Pavel Slavicek <pslavice> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 2.0.0 | CC: | jclere, jdoyle, lfuka, pcheung, pslavice, rsvoboda |
| Target Milestone: | ER03 | ||
| Target Release: | TBD EWS | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://jira.jboss.org/jira/browse/JBEWS-96 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Previously in JBoss Enterprise Web Server, during the RPM installation for tomcat6 and tomcat7, alternatives are configured for <classname>el_api</classname>. Both versions of tomcat use the same name (<literal>el_api)</literal>), due to which the tomcat version installed later overwrites the version installed first. Additionally, both builds use the alternatives <literal>el_api</literal> and <literal>el_api_1_0</literal> instead of the correct version (tomcat6 uses version 2.1 while tomcat7 uses 2.1).
This issue is fixed in JBoss Enterprise Web Server 2.1.
|
Story Points: | --- |
| Clone Of: | Environment: |
RHEL RPM
|
|
| Last Closed: | 2019-06-13 09:17:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
David Knox
2012-11-06 17:24:04 UTC
Assigning to David for fixing in the next release. David, are the rpms going to be renamed? They are currently tomcat7-el-1.0-api and tomcat6-el-1.0-api. If so, please make sure the proper virtual provides and obsoletes are put in so that they can be installed and or upgraded properly. Thanks! Docs QE Status: Removed: NEW the problem is not that tomcat6 and tomcat7 install el_api under the same name. That's what alternatives takes care of: [root@localhost ep-6-rhel-5]# alternatives --config el_api There are 2 programs which provide 'el_api'. Selection Command ----------------------------------------------- *+ 1 /usr/share/java/tomcat6-el-2.1-api.jar 2 /usr/share/java/tomcat7-el-2.2-api.jar The problem was the version of el-api was hard coded and wrong. So both would be installed using the same jar. As shown above this is fixed. Additionlly, there are alternatives installed as el_2_1_api an el_2_2_api to maintain backward compatibility. The el-api, servlet-api, and jsp-api in tomcat libdir (/usr/share/java/tomcatX) were symlinks to relative jars in _javadir (/usr/share/java). This broke the java security manager because it has difficulty following symlinks. To fix that, the *-api jars were copied into libdir from _javadir. In the process of fixing this bz, the tomcat libdir has become the library of record. The symlinks in _javadir point to the tomcat libdir. We need a pm-ack. updated the doc. Please test it VERIFIED on tomcat6-6.0.41-4_patch_02.ep6.el5 tomcat6-6.0.41-3_patch_02.ep6.el6 tomcat6-6.0.41-4_patch_02.ep6.el7 tomcat7-7.0.54-6_patch_02.ep6.el5 tomcat7-7.0.54-6_patch_02.ep6.el6 tomcat7-7.0.54-4_patch_02.ep6.el7 Changed Doc Type to Bug Fix. Updated the Doc Text. Previous Doc text: the problem is not that tomcat6 and tomcat7 install el_api under the same name: [root@localhost]# alternatives --config el_api There are 2 programs which provide 'el_api'. Selection Command ------------------------------------------- *+ 1 /usr/share/java/tomcat6-el-2.1-api.jar 2 /usr/share/java/tomcat7-el-2.2-api.jar The problem was the version of el_api was hard coded and wrong. So both would be installed using the same target jar. The alternatives output shows el_api installed correctly. The el_api alternatives are also installed as el_2_1_api an el_2_2_api to maintain backward compatibility. Related to this, having the *-api symlinks in tomcat libdir broke the java security manager which has problems following symlinks. To fix that, the *-api jars had to be redundantly copied into libdir from _javadir. In the process of fixing this issue, the tomcat libdir has become the point of record. The symlinks in _javadir point to targets in the tomcat libdir, including symlinks for maven tomcat components. New Doc Text: During the RPM installation for tomcat6 and tomcat7, alternatives are configured for <classname>el_api</classname>. Both versions of tomcat use the same name (<literal>el_api)</literal>), due to which the tomcat version installed later overwrites the version installed first. Additionally, both builds use the alternatives <literal>el_api</literal> and <literal>el_api_1_0</literal> instead of the correct version (tomcat6 uses version 2.1 while tomcat7 uses 2.1). This issue is fixed in JBoss Enterprise Web Server 2.1.0. |