Bug 589231 - when uploading a new package via an EAR or WAR Resource's Content>New subtab, user should not be required to select a repo
when uploading a new package via an EAR or WAR Resource's Content>New subtab,...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Content (Show other bugs)
1.3.1
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Simeon Pinder
Sunil Kondkar
:
Depends On:
Blocks: jon24-content
  Show dependency treegraph
 
Reported: 2010-05-05 11:49 EDT by Ian Springer
Modified: 2013-08-05 20:37 EDT (History)
1 user (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 12:47:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot showing the issue (57.20 KB, image/png)
2010-05-05 12:34 EDT, Ian Springer
no flags Details
Screenshot for the message (118.73 KB, image/png)
2010-05-19 07:53 EDT, Sunil Kondkar
no flags Details

  None (edit)
Description Ian Springer 2010-05-05 11:49:01 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create a WAR Resource (e.g. helloworld.war)
2. Go to the WAR Resource's Content>New subtab.
3. Click the Upload New Package button.
4. Click the Upload File button and upload a new version of the WAR (e.g. helloworld_v2.war)
5. Try to click the Continue button.

Actual results:
You'll get an error that says "A repository deployment option must be specified." (see attached screenshot)

Expected results:
The original WAR package associated with the WAR Resource is not associated with a repo or a content source. I verified this by peeking at the DB using dbvis. So the package for the updated v2 WAR really should not require a repo be specified either.

I propose we add a 4th radio button labeled "None" to the select repository options, and have this radio button selected by default.

We could also potentially not require selecting a repository at all in the case where the Resource is a package-backed Resource such as an EAR or WAR (this would assume that a package-backed Resource would never have other poackages associated with it, besides its backing package).
Comment 1 Ian Springer 2010-05-05 12:34:16 EDT
Created attachment 411669 [details]
screenshot showing the issue
Comment 2 Simeon Pinder 2010-05-17 21:12:08 EDT
Made suggested changes to add None option for repo selection and select by default.

Available in successful master build >= 307, and 

commit hash:
ce0d8ab908a52df1bc7826de06d848c8300a343f
Comment 3 Sunil Kondkar 2010-05-19 07:14:26 EDT
Verified on jon build#154 (Revision: 10620)

Observed that now there is a 'None' option for repository selection and the 'None' option is selected by default.

However, when clicked on 'Continue' button after uploading a .war file and selecting null option, it displays below message on the screen:

Failed to associate package [rhq-postinstaller.war] with repository ID [null]. Cause: java.lang.NumberFormatException:null.


Please find attached the screenshot for more details.
Comment 4 Sunil Kondkar 2010-05-19 07:53:08 EDT
Created attachment 415091 [details]
Screenshot for the message
Comment 5 Simeon Pinder 2010-05-26 05:03:38 EDT
Yep. This was caused by a curious reversion of the applied fix after checkin. I'm calling it a gitastrophy.  I re-applied the fix and the error message from the screenshot should be fixed now in successful build of master >= 355, and 
git hash: bd8ee1ee291e656dfec223110ed51d0cb24d2219.
Comment 6 Sunil Kondkar 2010-05-27 07:35:09 EDT
Verified on Jon build170 (Revision: 10621)

Observed that there is a 'None' option for repository selection and the
'None' option is selected by default. No exception is observed after clicking on 'Continue' button after uploading a .war file. New package is deployed successfully.
Comment 7 Corey Welton 2010-08-12 12:47:25 EDT
Mass-closure of verified bugs against JON.

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