Bug 752761 - Deleting an EAR/WAR fails with UnsupportedOperationException
Deleting an EAR/WAR fails with UnsupportedOperationException
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
All All
unspecified Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On: 752918 752919 752920 752921 752925 752926 752928 752929 753761 672240
Blocks: jon30-sprint8 749804
  Show dependency treegraph
Reported: 2011-11-10 06:34 EST by Robert Buck
Modified: 2014-09-11 13:38 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 672240
Last Closed: 2014-09-11 13:38:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Robert Buck 2011-11-10 06:34:56 EST
+++ 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 06:35:33 EST
Created attachment 532786 [details]
Image showing result
Comment 2 Ian Springer 2011-11-15 16:04:25 EST
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.