Check whether delete succeeded when undeploying from dropins

[Azquelt]

Issue Overview

If deleting a file from dropins fails, the exception returned does not identify the cause

Expected Behaviour

If deleting a file from dropins fails, the exception returned to the user should say that it couldn't delete the file

Current Behaviour

If deleting a file from dropins fails, the exception returned to the user is
Caused by: org.jboss.arquillian.container.spi.client.container.DeploymentException: Timeout while waiting for "CDIPropertyNameMatchingTest" ApplicationMBean to reach NOT_INSTALLED. Actual state: STARTED.

Steps To Reproduce

1. Run a test which deploys an application to dropins
2. Cause the application file to fail to undeploy (e.g. by file locking on Windows)

Additional Information

We saw this problem when the liberty process had the file locked due to a server bug. Although liberty shouldn't have the application locked, it might make sense to include a wait and retry loop if we can't delete the file.

[codingchili]

@Azquelt I'm having described with file locking on windows. Is there a fix somewhere?

18.0.0.3 (wlp-1.0.22.cl180320180905-2337)

com.package.ArquillizerIT > executionError FAILED
    org.jboss.arquillian.container.spi.client.container.DeploymentException: Error undeploying application da049535-6ed8-416d-bdca-0e96ac66b69c.war org.apache.http.client.ClientProtocolException: Unable to undeploy application d
a049535-6ed8-416d-bdca-0e96ac66b69c.war, server returned response: HTTP/1.1 400 Bad Request

The test archive is deployed in dropins and the archive is locked until websphere is stopped.

I'm not having any issues when adding the same test archive by dropping it manually into dropins. The tests are not executed then, it's only "deployed".

[Azquelt]

Hi @codingchili I'm guessing you're using the remote container (Based on server returned response: HTTP/1.1 400 Bad Request)?

If so could you open a separate issue and also check the messages log of the server for any relevant messages?

The issue I reported here is a result of the managed container not waiting for the server to unlock the file so it could be deleted. If you're using the remote container, then the container makes a call to the remote liberty server which is then responsible for deleting the file. So it could be a problem with the remote container, or a problem with Liberty itself. Raise a new issue and include the messages log from around the time the failure occurred and we can investigate.

[Azquelt]

The managed container issue where the file is not deleted because it is locked should be fixed by #46 but I should also check whether that fixes the exception message that's returned if the deletion still fails.