Bug 679580

Summary: Velocity fails to load all dependent classes
Product: Red Hat Enterprise Linux 6 Reporter: John Dennis <jdennis>
Component: pki-coreAssignee: Matthew Harmsen <mharmsen>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: alee, benl, jgalipea, nsoman, shaines
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-9.0.3-3.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 679574 Environment:
Last Closed: 2011-05-19 13:44:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 679574    
Bug Blocks:    
Attachments:
Description Flags
setup links to {jakarta,apache}-commons-collection.jar mharmsen: review+

Description John Dennis 2011-02-22 22:05:58 UTC
+++ 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

Comment 1 Matthew Harmsen 2011-02-23 00:42:00 UTC
Created attachment 480305 [details]
setup links to {jakarta,apache}-commons-collection.jar

Reference:   Bugzilla Bug #679574

Comment 2 Matthew Harmsen 2011-02-23 00:46:35 UTC
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

Comment 4 Jenny Severance 2011-04-18 18:05:13 UTC
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)

Comment 5 John Dennis 2011-04-18 18:38:53 UTC
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.

Comment 6 Chandrasekar Kannan 2011-04-20 23:34:48 UTC
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.

Comment 7 Namita Soman 2011-04-28 14:50:59 UTC
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.

Comment 8 errata-xmlrpc 2011-05-19 13:44:07 UTC
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