Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338417

Summary: PAR containing a WAB which fails to start ends up partially started
Product: [RT] Virgo Reporter: Glyn Normington <glyn.normington>
Component: runtimeAssignee: Glyn Normington <glyn.normington>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: alex.blewitt
Version: 3.0.0.M01   
Target Milestone: 3.0.0.M05   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
PAR to reproduce the problem none

Description Glyn Normington CLA 2011-02-28 09:44:24 EST
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.)
Comment 1 Glyn Normington CLA 2011-05-16 08:00:18 EDT
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.
Comment 2 Glyn Normington CLA 2011-05-18 08:16:34 EDT
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
-             }
        }