You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Marko Herchet (JIRA)" <ji...@apache.org> on 2017/11/02 08:37:00 UTC
[jira] [Updated] (FELIX-5739) Strange behaviour with
Lazy-ActivationPolicy and autostart
[ https://issues.apache.org/jira/browse/FELIX-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marko Herchet updated FELIX-5739:
---------------------------------
Description:
Iam using felix.scr with Equinox (e4 application)
Scenario:
Bundle A has Bundle-ActivationPolicy: lazy
Bundle A has startLevel=4
Bundle A provides Service S1 via ComponentDefinition
Bundle B listens for REGISTER-Event of S1 and retrieves it via BundleContext.getService(serviceEvent.getServiceReference())
When Bundle A has autostart = false everything behaves as expected:
* Equinox-ModuleContainer increases actual level to 4
* Equinox-ModuleContainer starts lazyOnly-Bundles with StartLevel 4
* Bundle A BundleState changes to STARTING
* felix.scr reacts to BundleEvent for STARTING of Bundle A, and parses the ComponentDefinitions
* felix.scr registers a ServiceFactory for S1
* Bundle B reacts to ServiceEvent for REGISTER of S1 and calls BundleContext.getService(serviceEvent.getServiceReference())
* The ServiceFactory for S1 loads Class of S1
* The responsible Equinox-BundleClassLoader starts Bundle A
* Activator#start of Bundle A is called
* Instance of S1 is created
* S1.activate() is called
When Bundle A has autostart = false something (in my opinion) weird happens:
* Equinox-ModuleContainer increases actual level to 4
* Equinox-ModuleContainer starts lazyOnly-Bundles with StartLevel 4
* Bundle A BundleState changes to STARTING
* felix.scr reacts to BundleEvent for STARTING of Bundle A, and parses the ComponentDefinitions
* felix.scr registers a ServiceFactory for S1
* Bundle B reacts to ServiceEvent for REGISTER of S1 and calls BundleContext.getService(serviceEvent.getServiceReference())
* The ServiceFactory for S1 loads Class of S1
* The responsible Equinox-BundleClassLoader (!) DOESNT start Bundle A
* Instance of S1 is created
* S1.activate() is called
* Equinox-ModuleContainer starts autostartedOnly-Bundles with StartLevel 4 (module#start returns fast for Modules that are not autostarted)
* Activator#start of Bundle A is called
* Bundle A BundleState changes to ACTIVE
In this case we have a Lazy-BundleA and its services #activate-Method is called before its Activator#start... should this even be possible?
I'm not sure why one would even use LazyActivationPolicy in combination with autostart but I'm pretty sure it didnt behave this way before we updated to eclipse-oxygen and felix.scr
was:
Iam using felix.scr with Equinox (e4 application)
Scenario:
Bundle A has Bundle-ActivationPolicy: lazy
Bundle A has startLevel=4
Bundle A provides Service S1 via ComponentDefinition
Bundle B listens for REGISTER-Event of S1 and retrieves it via BundleContext.getService(serviceEvent.getServiceReference())
When Bundle A has autostart = false everything behaves as expected:
* Equinox-ModuleContainer increases actual level to 4
* Equinox-ModuleContainer starts lazyOnly-Bundles with StartLevel 4
* Bundle A BundleState changes to STARTING
* felix.scr reacts to BundleEvent for STARTING of Bundle A, and parses the ComponentDefinitions
* felix.scr registers a ServiceFactory for S1
* Bundle B reacts to ServiceEvent for REGISTER of S1 and calls BundleContext.getService(serviceEvent.getServiceReference())
* The ServiceFactory for S1 loads Class of S1
* The responsible Equinox-BundleClassLoader starts Bundle A
* Activator#start of Bundle A is called
* Instance of S1 is created
* S1.activate() is called
When Bundle A has autostart = false something (in my opinion) weird happens:
* Equinox-ModuleContainer increases actual level to 4
* Equinox-ModuleContainer starts lazyOnly-Bundles with StartLevel 4
* Bundle A BundleState changes to STARTING
* felix.scr reacts to BundleEvent for STARTING of Bundle A, and parses the ComponentDefinitions
* felix.scr registers a ServiceFactory for S1
* Bundle B reacts to ServiceEvent for REGISTER of S1 and calls BundleContext.getService(serviceEvent.getServiceReference())
* The ServiceFactory for S1 loads Class of S1
* The responsible Equinox-BundleClassLoader DOESNT start Bundle A
* Instance of S1 is created
* S1.activate() is called
* Equinox-ModuleContainer starts autostartedOnly-Bundles with StartLevel 4 (module#start returns fast for Modules that are not autostarted)
* Activator#start of Bundle A is called
* Bundle A BundleState changes to ACTIVE
In this case we have a Lazy-BundleA and its services #activate-Method is called before its Activator#start... should this even be possible?
I'm not sure why one would even use LazyActivationPolicy in combination with autostart but I'm pretty sure it didnt behave this way before we updated to eclipse-oxygen and felix.scr
> Strange behaviour with Lazy-ActivationPolicy and autostart
> ----------------------------------------------------------
>
> Key: FELIX-5739
> URL: https://issues.apache.org/jira/browse/FELIX-5739
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.0.10
> Environment: felix.scr 2.0.10
> eclipse 4.7.0
> equinox
> windows
> Reporter: Marko Herchet
> Priority: Minor
>
> Iam using felix.scr with Equinox (e4 application)
> Scenario:
> Bundle A has Bundle-ActivationPolicy: lazy
> Bundle A has startLevel=4
> Bundle A provides Service S1 via ComponentDefinition
> Bundle B listens for REGISTER-Event of S1 and retrieves it via BundleContext.getService(serviceEvent.getServiceReference())
> When Bundle A has autostart = false everything behaves as expected:
> * Equinox-ModuleContainer increases actual level to 4
> * Equinox-ModuleContainer starts lazyOnly-Bundles with StartLevel 4
> * Bundle A BundleState changes to STARTING
> * felix.scr reacts to BundleEvent for STARTING of Bundle A, and parses the ComponentDefinitions
> * felix.scr registers a ServiceFactory for S1
> * Bundle B reacts to ServiceEvent for REGISTER of S1 and calls BundleContext.getService(serviceEvent.getServiceReference())
> * The ServiceFactory for S1 loads Class of S1
> * The responsible Equinox-BundleClassLoader starts Bundle A
> * Activator#start of Bundle A is called
> * Instance of S1 is created
> * S1.activate() is called
> When Bundle A has autostart = false something (in my opinion) weird happens:
> * Equinox-ModuleContainer increases actual level to 4
> * Equinox-ModuleContainer starts lazyOnly-Bundles with StartLevel 4
> * Bundle A BundleState changes to STARTING
> * felix.scr reacts to BundleEvent for STARTING of Bundle A, and parses the ComponentDefinitions
> * felix.scr registers a ServiceFactory for S1
> * Bundle B reacts to ServiceEvent for REGISTER of S1 and calls BundleContext.getService(serviceEvent.getServiceReference())
> * The ServiceFactory for S1 loads Class of S1
> * The responsible Equinox-BundleClassLoader (!) DOESNT start Bundle A
> * Instance of S1 is created
> * S1.activate() is called
> * Equinox-ModuleContainer starts autostartedOnly-Bundles with StartLevel 4 (module#start returns fast for Modules that are not autostarted)
> * Activator#start of Bundle A is called
> * Bundle A BundleState changes to ACTIVE
> In this case we have a Lazy-BundleA and its services #activate-Method is called before its Activator#start... should this even be possible?
> I'm not sure why one would even use LazyActivationPolicy in combination with autostart but I'm pretty sure it didnt behave this way before we updated to eclipse-oxygen and felix.scr
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)