aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Domagoj Cosic (Jira)" <j...@apache.org>
Subject [jira] [Updated] (ARIES-1998) IllegalStateException on service unregistration in ProviderBundleTrackerCustomizer.removedBundle
Date Wed, 19 Aug 2020 19:53:00 GMT

     [ 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)

Mime
View raw message