Workaround: Workaround Exists Workaround Description: Use update-alternatives to install the desired version of EL API. examples: update-alternatives --install /usr/share/java/el-api-2_1.jar el_api_2_1 /usr/share/tomcat6-el-1.0-api-6.0.35.jar update-alternatives --install /usr/share/java/el-api-2_2.jar el_api_2_2 /usr/share/tomcat7-el-1.0-api-7.0.30.jar project_key: JBEWS When the RPMs for tomcat6 and tomcat7 are installed, alternatives is configured for el_api. Both tomcat6 and tomcat7 use the same name "el_api" which allows for one to override the first. A user of EL API vis a vi alternatives may be unaware which version is configured for use. Both builds use the names el_api and el_api_1_0 for alternatives. The name should include the correct EL version spec. Tomcat6 uses elspec 2.1 while tomcat7 uses 2.2. Instead the alternatives name should reflect which elspec is used; e.g., el_api_2_1 and el_api_2_2.
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.