-
Type: Improvement
-
Status: Resolved
-
Priority: Minor
-
Resolution: Fixed
-
Affects Version/s: 11.2
-
Component/s: Runtime
-
Epic Link:
-
Team:AT
-
Sprint:nxAT 11.1.23, nxAT 11.1.24
-
Story Points:3
The ComponentManager service has 2 listener apis:
- addComponentListener(ComponentListener) for components deployments events
- addListener(ComponentManager.Listener) for runtime lifecycle hooks
The first one is unused right now, and the second one is used:
- by RuntimeMessageHandler, registering itself on the ComponentManager when created explicitly by the framework in it method Component#start
- by components, in method Component#start
The first, unused, listener registration would need to be done very early so that all component events are available to the listener.
This cannot currently be ensured without registering a listener in the code, similarly to RuntimeMessageHandler, as any hook method like Component#activate or Component#start cannot be ensured to be called as "the first ones" when the framework starts.
Goal is to make this pluggable by:
- instantiating components
- activating them in a second step
This would be useful for explorer introspection logics, although registration and resolution of components happens earlier.
When instantiating components, they can add themselves as listeners of the ComponentManager method.
Note the listener addition methods check for duplicates, so it might not be necessary to unregister listeners at hot reload, but might be interesting to plug it on the component stop method, still (as component being hot-reloaded are instantiated again), for consistency.
- is related to
-
NXP-29641 Fix component manager events on pending registrations
- Resolved
-
NXP-28948 Handle components in error in Explorer export
- Resolved
-
NXP-29569 Make explorer registration order meaningful
- Resolved
-
NXP-29573 Better track runtime errors and warnings
- Resolved
- Is referenced in