[ https://issues.apache.org/jira/browse/ARIES-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208310#comment-17208310 ]
Domagoj Cosic commented on ARIES-1998: -------------------------------------- The commit is as expected, with reasonable addition of try/catch - though I cannot think of a race condition at once, I can imagine there could be some. > IllegalStateException on service unregistration in > ProviderBundleTrackerCustomizer.removedBundle > ------------------------------------------------------------------------------------------------ > > Key: ARIES-1998 > URL: https://issues.apache.org/jira/browse/ARIES-1998 > Project: Aries > Issue Type: Bug > Components: SPI Fly > Affects Versions: spifly-1.3.0 > Reporter: Domagoj Cosic > Assignee: Raymond Augé > Priority: Major > Fix For: spifly-1.3.1 > > > {{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}}. -- This message was sent by Atlassian Jira (v8.3.4#803005)