Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Message-ID: <15716509.1162796857549.JavaMail.jira@brutus>
Date: Sun, 5 Nov 2006 23:07:37 -0800 (PST)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: felix-dev@incubator.apache.org
Subject: [jira] Updated: (FELIX-169) Shutdown of Felix through
 Felix.shutdown() does not call custom activator stop methods
In-Reply-To: <4703322.1162479616499.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/FELIX-169?page=all ]

Felix Meschberger updated FELIX-169:
------------------------------------

    Attachment: FELIX-169_2.diff

Proposed patch with following additions:
  * Felix.shutdown() method split into public Felix.shutdown() (checks status, calls Felix.shutdownInternal(), exits VM if not embedded) and private Felix.shutdownInternal() doing the rest of the work of the former Felix.shutdown() method.
  * SystemBundle.stop() method split into SystemBundle.stop() (just calls Felix.shutdown() in a separate thread if the framework is running) and SystemBundle.shutdown() (actually stops the SystemBundle)

The reasoning for these new methods is as follows:
   (1) Felix.shutdown() and SystemBundle.stop() should behave the same for a running framework: The framework should be shut down - albeit Felix.shutdown() works synchronously and SystemBundle.stop() must work asynchronously (according to the spec).
   (2) Calling Felix.shutdown() or SystemBundle.stop() (e.g. through context.getBundle(0).stop()) while the framework is shutting down should have no effect.
   (3) After taking the startlevel to zero, the SystemBundle must be regularly stopped, which primarily means stopping any BundleActivators started.

With the former combined SystemBundle.stop() method, issue (2) could not be solved, as either the BundleActivators were never stopped (as no shutdown thread was started) or calling SystemBundle.stop() while the framework was being stopped would result in the BundleActivators being stopped to early.

I split the Felix.shutdown() method just for source code complexity reasons: The framework shutdown should complete - with or without exception - and the the VM should be stopped no matter what if the framework is not embedded. Therefore, shutdown processing should be encapsulated by a try-catch statement.

> Shutdown of Felix through Felix.shutdown() does not call custom activator stop methods
> --------------------------------------------------------------------------------------
>
>                 Key: FELIX-169
>                 URL: http://issues.apache.org/jira/browse/FELIX-169
>             Project: Felix
>          Issue Type: Bug
>            Reporter: Felix Meschberger
>         Attachments: FELIX-169.diff, FELIX-169_2.diff
>
>
> When starting Felix through Felix.start() a list of BundleActivator objects may be handed in. Additionally, the SystemBundle adds some more BundleActivators (e.g. the URLHandlersActivator. When stopping Felix through the SystemBundle.stop() method, a separate thread is started, which calls the Felix.shutdown() method, which ultimately calls back into the SystemBundle.stop() method, which now - amongst other things - calls the BundleActivator.stop() method of the additional BundleActivators.
> If shutting Felix down through Felix.shutdown() directly, a separate thread is not started, and hence the BundleActivator.stop() methods are not called.
> I assume, the test for the m_shutdownThread field in the SystemBundle.stop method is superfluous as this field is only set then Felix is stopped through the system bundle.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira