Bug 752761 - Deleting an EAR/WAR fails with UnsupportedOperationException
Summary: Deleting an EAR/WAR fails with UnsupportedOperationException
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: 3.0.0
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On: 752918 752919 752920 752921 752925 752926 752928 752929 753761 672240
Blocks: jon30-sprint8 749804
TreeView+ depends on / blocked
 
Reported: 2011-11-10 11:34 UTC by Robert Buck
Modified: 2014-09-11 17:38 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 672240
Environment:
Last Closed: 2014-09-11 17:38:52 UTC
Embargoed:


Attachments (Terms of Use)
Image showing result (246.89 KB, image/png)
2011-11-10 11:35 UTC, Robert Buck
no flags Details

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.


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