Thanks for this detailed explanation Peter. I will change my cleanup to a nonblocking implementation.
regards Marc ___________________________________________ Sparda-Datenverarbeitung eG AD-POR Freiligrathstrasse 32, 90482 Nürnberg Tel.: 0911/5486-722 mailto: [email protected] Sitz der Genossenschaft: Nürnberg Amtsgericht Nürnberg, GnR 271 Vorstand: Ludwig Oberhammer (Vorsitzender), Burkhard Kintscher Aufsichtsratsvorsitzender: Manfred Stevermann Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Von: Peter Kriens <[email protected]> An: OSGi Developer Mail List <[email protected]>, Datum: 01.06.2016 12:37 Betreff: Re: [osgi-dev] Is a Bundle in state STOPPING still accessible? Gesendet von: [email protected] You?re reaching dangerous grounds ? If you use a SynchronousBundleListener then you get the BundleEvent.STOP before the BundleActivator.stop (if any) is called. At that point the BundleContext is still valid and the services are still registered. However, the state of the bundle?s code is now undefined because other extenders could already muck around with it. SynchronousBundleListeners should obviously NOT wait for locks unless you like deadlocks. Any trick to create ordering and holding up this process is generally extremely painful. Use the events asynchronously and only as events, never do real work in even handlers. In general, you want to do any cleanup without collaboration of the target bundle in any way. Kind regards, Peter Kriens On 1 jun. 2016, at 10:09, [email protected] wrote: Hello everyone I need to handle a threading issue in one of my extenders (cleanup on stop). Since I need some locking I would like to ask if a Bundle in STOPPING-state can still be used from other bundles (because I aquire a write-lock during stopping which might have to wait for a read-lock)? In section 4.4.2 of the core-specification I read the following: If this specification uses the term active to describe a state, then this includes the STARTING and STOPPING states. Can I assume this means my bundle is still accessible until the state reaches RESOLVED? Thanks Marc ___________________________________________ Sparda-Datenverarbeitung eG AD-POR Freiligrathstrasse 32, 90482 Nürnberg Tel.: 0911/5486-722 mailto: [email protected] Sitz der Genossenschaft: Nürnberg Amtsgericht Nürnberg, GnR 271 Vorstand: Ludwig Oberhammer (Vorsitzender), Burkhard Kintscher Aufsichtsratsvorsitzender: Manfred Stevermann Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev [Anhang "smime.p7s" gelöscht von Marc Schlegel/sdv] _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
