Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <19150824.1190877470608.JavaMail.jira@brutus>
Date: Thu, 27 Sep 2007 00:17:50 -0700 (PDT)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Updated: (FELIX-381) Started bundles may change state to
 RESOLVED
In-Reply-To: <31930767.1190877350569.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FELIX-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated FELIX-381:
------------------------------------

    Attachment: FELIX-381.patch

Addition to moduleResolved method in the Felix class to ignore the event if the owning bundle is not in the INSTALLED state.

> Started bundles may change state to RESOLVED
> --------------------------------------------
>
>                 Key: FELIX-381
>                 URL: https://issues.apache.org/jira/browse/FELIX-381
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 1.0.0
>            Reporter: Felix Meschberger
>         Attachments: FELIX-381.patch
>
>
> In certain situations a bundle, which has already been started gets its state changed back to RESOLVED.
> Consider the following situation: A thread T1 is starting a Bundle A while another thread T2 is starting a Bundle B depending on Bundle A. T2 resolves Bundle B and as T1 has not done it yet assumes to have to resolve Bundle A. Before T2 can resolve Bundle A, T1 resolves Bundle A itself and actually starts Bundle A at the end setting the state to ACTIVE. Then T2 finishes resolving and calls the ResolveListener to inform that Bundle A has been resolved, which causes the state of Bundle A to be set to RESOLVED.
> The consequence is that Bundle A has been started  - BundleActivator called, STARTED event fired - and then its state is just set to RESOLVED and a RESOLVED event is fired. This is incorrect as (1) Bundle A has already started and before entering the RESOLVED state (again) it would have to be stopped and (2) getting A back into resolved state would cause STOPPING and STOPPED events to be fired and not a RESOLVED event.
> The fix would probably be to ignore the moduleResolved event for bundles, which are not in the INSTALLED state.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.