Description of problem: The Tomcat plugin does not compute the SHA for exploded deployments. How reproducible: Every time. Steps to Reproduce: 1. Inventory a Tomcat 6 Server 2. Deploy a new WAR for an existing application (make sure it gets exploded) 3. Check the manifest for the exploded war for the RHQ SHA attribute. Actual results: The SHA attribute is not present. Expected results: The SHA attribute is in the file. Additional info: This functionality is not implemented for the Tomcat 6 plugin. The JBoss AS 4 and 5 plugins will also need to be code inspected.
Verification steps for QE Setup: 1) RHQ server started, RHQ agent running, CLI connected to RHQ server 2) Inventoried Tomcat Server, JBoss AS4 or JBoss EAP5.1 3) Need the ID of a content backed resource, eg. an application resource. The ID can be retrieved from the UI http://localhost:7080/coregui/#Resource/14932, the last portion of the url is the ID of the resource. 4) A sample war application to be deployed to the application server 5) A folder to backup applications from the server Stimulate: 1) Navigate in the UI to the selected application resource, content tab, history subtab. 2) From the CLI run the following commands: 3) applicationResource = ProxyFactory.getResource(14932) 4) applicationResource.retrieveBackingContent("/resources/backup/original.war") 5) applicationResource.updateBackingContent("/resources/new/newcontent.war", "1.2") 6) applicationResource.retrieveBackingContent("/resources/backup/updated.war") 7) Navigate in the UI to the resource that was just updated to the Content tab Verification steps: 1) Verify that after Step 1, the Full Package Audit Trail table, version column has either a normal number (eg. 1.2.3) or sha256. The version field should not be empty. 2) Verify that the archive retrieved in Step 3 is the exact archive that was deployed on the server before running the test 3) Verify that after Step 4 the new application has been actually deployed on the application server. Check the file system where the application server deploys content. 4) Verify that after Step 4 the new application has RHQ-Sha256 attribute in the manifest. 5) Verify that after Step 5 the archive downloaded is the application deployed in Step 4 6) Verify the content tab, history subtab has the following: a) Full Package Audit Trail table has the correct package information marked as Discovered, including correct version. b) Completed Requests table has information regarding the request submitted from the CLI, including submitted version.
2nd verification step for QE UI Test (applicable to BZ 761593, 767247, 767393, 769986) Setup: 1) RHQ server started, RHQ agent running 2) Inventoried Tomcat Server, JBoss AS4 or JBoss EAP5.1 3) A sample war application to be deployed to the application server Stimulate: 1) Navigate in the UI to the selected application resource, content tab, history subtab. 2) Navigate to the New subtab. 3) Upload a new war package for the resource. Follow the guided UI but do change the version field to something unique. 4) Navigate in the UI to the resource that was just updated to the Content tab Verification steps: 1) Verify that after Step 1, the Full Package Audit Trail table, version column has either a normal number (eg. 1.2.3) or sha256. The version field should not be empty. 2) Verify after Step 4 the new application has been actually deployed on the application server. Check the file system where the application server deploys content. 3) Verify after Step 4 the new application has RHQ-Sha256 attribute in the manifest. 4) Verify after Step 4 the content tab, history subtab has the following: a) Full Package Audit Trail table has the correct package information marked as Discovered, including correct version. b) Completed Requests table has information regarding the request submitted from the CLI, including submitted version.
adding NeedsTestCase ... there may be opportunities to automate either the CLI or the UI tests ... or failing that ... add this in TCMS
*** Bug 602475 has been marked as a duplicate of this bug. ***
Some negative test cases for the first test case posted in comment 1 : 1) Step 4, point to an existing file 2) Step 5, point to a non-existing file 3) Step 6, retrieve content twice in two separate files and then compare the results 4) Step 5, repeat the step with a different version. Observe in the UI that that version is from the last call and two entries in the deployment log.
master branch commits: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=9149b3a7b20af133724d7f0a2dda4f09f54105ae http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=810fa9312582fa68526aaffab74eabca35ffa7c7 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=53268f7ce298e11e1a5fa079ff3c25b051d75746 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=f185673bc3ec2c9739912b62e2700814d73494aa http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=b960588d8d6f13d9fcfe2c5c48c1252adad8819a http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=3bbfcdabea8dad6533e1249f21424cb0d05a2a8e http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=398c5e22e76aab0f16b4abfac37513f5abc5d372 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=b6fb8cd62aac2c10a727208c2cea08352f8a89d1 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=9c318d42bbc4f80305afb1fa0e351b38bdbd80ba http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=b4761de3c02ae31c891e783d656ccb1be4bb7b41
Not verifiable in RC3. wait for RC4, or a build from jenkins 3.01 branch
movina back to ON_QA, I've actually verified this on JON 3.0.1 not master
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.