[ 
https://issues.apache.org/jira/browse/FELIX-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

J.W. Janssen reopened FELIX-3334:
---------------------------------


I'm reopening this issue after giving my earlier fix yet another thought. From 
field tests it appears that other NPEs can occur even with my earlier fix.

Why not let the BackingStoreManager#getStore() throw an BackingStoreException 
if there is no backing store service tracker available?

While it would mean a (internal) API-change, all usages of the #getStore() 
method would only yield an exception if used after the bundle has being 
stopped. We could try to cover all usages of #getStore() with a null-check as 
well, but would make the code (IMO) more complicated than necessary?!

I've investigated the impact of this change, and found that all places where 
#getStore() is called already handle or throw a BackingStoreException, making 
it a trivial change.
                
> PreferencesManager can throw NPE after being stopped.
> -----------------------------------------------------
>
>                 Key: FELIX-3334
>                 URL: https://issues.apache.org/jira/browse/FELIX-3334
>             Project: Felix
>          Issue Type: Bug
>          Components: Preferences Service
>    Affects Versions: prefs-1.0.4
>            Reporter: J.W. Janssen
>            Assignee: Carsten Ziegeler
>              Labels: patch
>             Fix For: prefs-1.0.6
>
>         Attachments: felix-prefs-3334-2.patch, quickfix-new.patch
>
>
> PreferencesManager#bundleChanged tries to intercept bundles that are 
> uninstalled. However, if the PreferencesManager itself is stopped, it does 
> not unregister itself as bundle listener, causing possible NPEs when other 
> bundles depending on the preferences service are stopped later on, for 
> example during a shutdown.
> I've got a patch available, will attach it to this issue to be applied.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to