Hide Forgot
+++ This bug was initially created as a clone of Bug #679574 +++ Velocity has a dependency on jakarta-commons-collections and jakarta-commons-lang. Bug #658926 added the dependency on jakarta-commons-lang but the same patch removed jakarta-commons-collections as an explicitly enabled jar in the web instance class loader because jakarata-commons-collections was being loaded by tomcat6 via the container class loader, it was felt this was redundant. The tomcat6 version of jakarta-commons-collections worked fine on Fedora because it was a current version. But on RHEL 6 the version of jakarta-commons-collections loaded by the container class loader is an older version (from tomcat5?). Velocity is loaded by the web app instance, the system version of jakarta-commons-collections should be available to the same class loader and not depend on the container class loader. The fix is add back the symlink to jakarta-commons-collections to the web app library directory. However, as per bug #665388 it's not sufficient to set up links to jakarta-commons-collections because the jar names have been renamed in F14 and above. Therefore the link creation logic in pkicreate needs to follow the model for other jakarata-commmons-* jars. --- Additional comment from jdennis on 2011-02-22 16:46:05 EST --- Created attachment 480262 [details] setup links to {jakarta,apache}-commons-collection.jar
Created attachment 480305 [details] setup links to {jakarta,apache}-commons-collection.jar Reference: Bugzilla Bug #679574
IPA_v2_RHEL_6_1_ERRATA_BRANCH: # cd pki # svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^? M base/setup/pkicreate # svn commit base/setup/pkicreate Sending base/setup/pkicreate Transmitting file data . Committed revision 1864. Resolves #679580 - Velocity fails to load all dependent classes
Is this sufficient to verify this issue? # yum deplist velocity Loaded plugins: product-id, subscription-manager Updating Red Hat repositories. Finding dependencies: package: velocity.noarch 1.4-10.7.el6 dependency: werken-xpath provider: werken-xpath.noarch 0.9.4-4.beta.12.6.el6 dependency: oro provider: jakarta-oro.x86_64 2.0.8-6.6.el6 dependency: log4j >= 1.1 provider: log4j.x86_64 1.2.14-6.4.el6 dependency: apache-tomcat-apis provider: apache-tomcat-apis.noarch 0.1-1.el6 dependency: jdom >= 1.0-1 provider: jdom.noarch 1.1.1-1.el6 dependency: avalon-logkit provider: avalon-logkit.noarch 1.2-8.2.el6 dependency: bcel provider: bcel.x86_64 5.2-7.2.el6 dependency: jakarta-commons-collections provider: jakarta-commons-collections.noarch 3.2.1-3.4.el6 # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 Beta (Santiago)
To verify: remove the link to {apache,jakarta}-commons-collections.jar and/or {apache,jakarta}-commons-lang.jar from /var/lib/pki-ca/webapps/ca/WEBINF/lib That should trigger a failure.
I think these were things that were tripping us up in getting a successful install/config of dogtag with IPA. As an alternative method for verification at a high level, if you can confirm that IPA/dogtag setup has occurred and that you can get certs issued etc.. that would even suffice IMHO.
Using: ipa-server-2.0.0-23.el6.x86_64 Can install with CS successfully. We have ipa server install test suite running with various options that use CS, and they pass. We also have ipa-getcert test suite which runs tests for various options for ipa-getcert request, and these pass too. Setting status to Verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0627.html