Community
Participate
Working Groups
Created attachment 189945 [details] PAR to reproduce the problem The attached PAR contains a simple WAB with an invalid web.xml. The WAB fails to start, but the synthetic context bundle remains in ACTIVE state and the PAR ends up in STARTING state. The PAR should really end up in RESOLVED state as should the synthetic context bundle. (Alternatively, the PAR should fail to deploy since it won't start and should end up not installed at all. I can't remember off hand what the correct behaviour is.)
The problem reproduces at HEAD. The following method in AbstractInstallArtifact is involved: public void signalSuccessfulCompletion() { try { asyncStartSucceeded(); AbstractInstallArtifact.signalSuccessfulCompletion(this.signal); } catch (DeploymentException de) { signalFailure(de); } } signalFailure is driven and this is sufficient to set the WAB into RESOLVED state, but not to set the PAR state to RESOLVED.
Fixed in kernel commit 75a5fc2fea791a5060bc54876b19e3e53a9525ef Because the web application start is asynchronous to the bundle install artifact start, the deployment is not failed. However the bug was that the PAR was not reacting appropriately to the web application bundle stopping. The atomic lifecycle listener was correctly feeding "stop" to the PAR install artifact, but there was a bug in the abstract install artifact implementation of stop which was ignoring the stop because the PAR is in STARTING state. The diff of the fix shows how clear a bug this was: public void stop() throws DeploymentException { // Only stop if ACTIVE or STARTING. if (getState().equals(State.ACTIVE) || getState().equals(State.STARTING)) { - if (this.getState().equals(State.ACTIVE)) { // stop the artifact - } }
