Bug 752761

Summary: Deleting an EAR/WAR fails with UnsupportedOperationException
Product: [Other] RHQ Project Reporter: Robert Buck <rbuck>
Component: PluginsAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED NOTABUG QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.0.0CC: ccrouch, dsteigne, hrupp, jshaughn, rbuck, rsoares
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 672240 Environment:
Last Closed: 2014-09-11 17:38:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 752918, 752919, 752920, 752921, 752925, 752926, 752928, 752929, 753761, 672240    
Bug Blocks: 745494, 749804    
Attachments:
Description Flags
Image showing result none

Description Robert Buck 2011-11-10 11:34:56 UTC 
+++ This bug was initially created as a clone of Bug #672240 +++

Description of problem:

After performing a farmed deployment I tried to delete the WAR via RHQ using Content...Deployed...Delete and I get errors, "UnsupportedOperationException: Cannot remove the package backing an EAR/WAR resource."

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

JON 3.0 Beta1

How reproducible:

Every time.

Steps to Reproduce:

1. Deploy helloworld.war as farmed (probably happens else where too)
2. Delete helloworld.war resource via RHQ.
  
Actual results:

java.lang.UnsupportedOperationException: Cannot remove the package backing an EAR/WAR resource.
	at org.rhq.plugins.jbossas5.StandaloneManagedDeploymentComponent.removePackages(StandaloneManagedDeploymentComponent.java:210)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:552)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Comment 1 Robert Buck 2011-11-10 11:35:33 UTC 
Created attachment 532786 [details]
Image showing result
Comment 2 Ian Springer 2011-11-15 21:04:25 UTC 
The WAR or EAR package associated with a WAR or EAR Resource is considered that Resource's "backing package". A Resource's backing package cannot be deleted, as this would make the Resource defunct since its underlying WAR or EAR would no longer exist.

So this is the expected behavior and it has been this way since JON 2.0. I admit it is confusing. Perhaps we should not list the backing package on the Content>Deployed subtab, or list if but disable the delete action for it. The content subsystem is full of such non-intuitive things, but I don't think it's a priority right now to address them.