Bug 1139745 - After undeployment of a deployment unit which was previously deployed via REST API, status of the deployment unit remains DEPLOYED instead of NONEXISTENT
Summary: After undeployment of a deployment unit which was previously deployed via RES...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ER3
: 6.2.0
Assignee: Shelly McGowan
QA Contact: Ivo Bek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-09 14:33 UTC by Ivo Bek
Modified: 2020-03-27 19:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:38:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ivo Bek 2014-09-09 14:33:04 UTC
Description of problem:

After undeployment of a deployment unit which was previously deployed via REST API, status of the deployment unit remains DEPLOYED instead of NONEXISTENT.

The problem exists only if a deployment unit is deployed via REST API. Otherwise, I get correctly NONEXISTENT status for the undeployed deployment unit.

Server log says: "Deployment unit org.jboss:remote-file-deployment:1.0-SNAPSHOT [strategy=SINGLETON] removed successfully" and it disappears from the deployment view in Business Central, thus undeployment works fine, just the status is incorrect then.

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


How reproducible:


Steps to Reproduce:
1. Deploy any deployment unit via REST API
2. Get deployment unit via REST to see the status - DEPLOYED
3. Undeploy the deployment unit via Business Central or REST API
4. Get deployment unit via REST to see the status - DEPLOYED (should be NONEXISTENT!)

Actual results:


Expected results:


Additional info:

Comment 1 Marco Rietveld 2014-09-10 11:05:54 UTC
Hi Ivo, 

Just to be sure, could you verify that the deployment unit keeps the status "DEPLOYED" indefinitely? (longer than.. 10 seconds?) You've probably already checked this, but I just want to make sure that that's not the case. 

Also, the status may end up changing to "UNDEPLOYED" instead of "NONEXISTENT" -- I'll check the code to see what the exact logic is.

Comment 2 Ivo Bek 2014-09-10 14:22:37 UTC
Hi Marco,

I tried it more times before but to be sure I checked it again on your request. After a long time 16:13:38,178 - 14:24:38,766 the state remains the same, DEPLOYED.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><deployment-unit><groupId>org.jboss</groupId><artifactId>remote-file-deployment</artifactId><version>1.0-SNAPSHOT</version><strategy>SINGLETON</strategy><status>DEPLOYED</status></deployment-unit>

UNDEPLOYED would be fine as well because it would mean that the deployment unit was available some time ago and now it is not. NONEXISTENT on the other hand can mean that the deployment unit has never existed but I do not know how you want it to be.

Comment 3 Marco Rietveld 2014-11-28 13:27:28 UTC
Ivo, 

I've just tried this with the 6.1.0.CR2 build and I haven't been able to reproduce this exception. 

Could you retry it on the next build?

Comment 4 Ivo Bek 2015-01-02 10:59:24 UTC
Verification failed in BPMS 6.1.0.ER3

Marco, below are updated steps to reproduce the problem because it works fine when I use REST API only, however in combination with Business Central, the status remains DEPLOYED though we undeployed the deployment unit via Business Central.

1. Deploy any deployment unit via REST API
2. Get deployment unit via REST to see the status - DEPLOYED
3. Undeploy the deployment unit via Business Central (via REST API, the status is correctly changed to UNDEPLOYED, that's why it is important to undeploy the deployment unit in Business Central)
4. Get deployment unit via REST to see the status - DEPLOYED (should be UNDEPLOYED)

Comment 5 Ivo Bek 2015-12-07 13:28:43 UTC
Verified in BPM Suite 6.2.0.CR2

currently, the request returns UNDEPLOYED status of the deployment unit


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