Bug 788773 - JBoss AS5 Plugin - SHA256 For Deployments Not Used Correctly
JBoss AS5 Plugin - SHA256 For Deployments Not Used Correctly
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
4.3
Unspecified Unspecified
high Severity high (vote)
: ---
: JON 3.0.1
Assigned To: Stefan Negrea
Mike Foley
:
Depends On: 767393
Blocks: 788629 790146
  Show dependency treegraph
 
Reported: 2012-02-08 18:57 EST by Stefan Negrea
Modified: 2013-09-03 11:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 767393
: 790146 (view as bug list)
Environment:
Last Closed: 2013-09-03 11:17:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
verification image (134.72 KB, image/png)
2012-02-13 13:30 EST, Mike Foley
no flags Details
verification text from CLI (1.79 KB, text/plain)
2012-02-13 13:30 EST, Mike Foley
no flags Details

  None (edit)
Description Stefan Negrea 2012-02-08 18:57:39 EST
+++ This bug was initially created as a clone of Bug #767393 +++

Description of problem:
For the JBoss AS5 plugin, the SHA256 is not returned correctly by the plugin
during discovery. Also, the SHA256 is not saved properly if the deployment does
not have a manifest file.

How reproducible:
Every time.

Steps to Reproduce:
1. Inventory an AS5 (EAP5) server.
2. Prepare a sample war file without a manifest file and folder.
2. Update an existing exploded webapp through the CLI using the sample war.
3. Browse and view the content of the manifest file for the deployed app (look
into the server deployment folder).
4. Wait for the discovery process to take place and notice that the SHA256 is
not returned correctly to the server.

Actual results:
There is no manifest file. The SHA256 returned to the server is null.

Expected results:
The manifest file is present and the RHQ-Sha256 attribute is present in the
main section. The SHA256 returned to the server is the one computed during
deployment.

Additional info:
There are several problems with saving the manifest file as well in the
discovery process. This plugin should behave like the corrected and enhanced
Tomcat plugin.

--- Additional comment from mfoley@redhat.com on 2012-01-23 15:25:34 EST ---

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.

--- Additional comment from mfoley@redhat.com on 2012-01-23 15:30:43 EST ---

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.

--- Additional comment from snegrea@redhat.com on 2012-02-08 18:55:48 EST ---

Some negative test cases:

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.
Comment 2 Simeon Pinder 2012-02-10 17:44:49 EST
Moving to ON_QA as new RC 4 available to test in:
https://brewweb.devel.redhat.com//buildinfo?buildID=198384
Comment 3 Mike Foley 2012-02-13 13:29:51 EST
uploading image and text to document the verification described
Comment 4 Mike Foley 2012-02-13 13:30:26 EST
Created attachment 561626 [details]
verification image
Comment 5 Mike Foley 2012-02-13 13:30:57 EST
Created attachment 561627 [details]
verification text from CLI
Comment 6 Mike Foley 2012-02-13 13:32:56 EST
performed additional negative and edge cases as described.
Comment 7 Heiko W. Rupp 2013-09-03 11:17:44 EDT
Bulk closing of old issues in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.