[
https://issues.apache.org/jira/browse/ARIES-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domagoj Cosic updated ARIES-1998:
---------------------------------
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}}.
was:
{{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.STARTED}} 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}}.
> 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
> Priority: Major
>
> {{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)
