Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
spifly-1.3.0
-
None
Description
ProviderBundleTrackerCustomizer.addingBundle method registers one or serveral ProviderServiceFactory services and stores the service registrations in a List within the tracked object. This list is used in order to unregister the services in removedBundle. However this logic is flawed when taking into account the modifiedBundle method. Its implementation is either unnecessary or over-simplified, pick one. Say, addingBundle is called with Bundle.STARTING event. It creates the array, the tracker will store it as the returned value. Next, modifiedBundle will be called with Bundle.ACTIVE event. It unregisters everything by calling removedBundle, leaving the array with "spent" service registrations. Then addingBundle re-registers the ProviderServiceFactory services, creating a new array which is eventually thrown away by modifiedBundle. When finally removedBundle is called again (e.g. on shutdown), it only has a "broken" service registration array on its disposal. The real one was thrown away.
Two ways to solve the issue:
- Make modifiedBundle implementation empty. There is no rationale for it. All the information processed comes from the manifest and it will not change between the bundle states.
- If you still find a rationale for implementing modifiedBundle: Move the addingBundle code into a private method, adding the service registration list as an additional parameter. Call it with a new list from public addingBundle method and with the stored list form the modifiedBundle method. Clear the list after unregistering services in removedBundle.
Attachments
Issue Links
- is duplicated by
-
ARIES-2006 java.lang.IllegalStateException: The service has been unregistered
- Resolved
-
ARIES-1924 Provider bundle service url tracking with bundle wiring instead of custom urls
- Resolved