[ https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128727#comment-13128727 ]
Rob Walker edited comment on FELIX-3160 at 10/17/11 8:51 AM: ------------------------------------------------------------- Now that would be quite funny ... but I have an odd sense of humour ;) There are 2 aspects I wonder if could be different in our setup. * Our sweeper bundle runs at a start level of 2. The bundles being uninstalled have a start level of 1, but, they used START_TRANSIENT in the previous framework start. On the restart, they never get beyond a start state of INSTALLED due do the transient start option. * The original JAR from which these bundles were started was a temporary file and will not be accessible on restarted (it's been deleted). The cached JAR and settings are of course still present. I don't recall any OSGi rule that says the original location/file that a bundle was installed from has to always be available, but maybe I forgot this? - Rob was (Author: walkerr): Now that would be quite funny ... but I have an odd sense of humour ;) There are 2 aspects I wonder if could be different in our setup. * Our sweeper bundle runs at a start level of 2. The bundles being uninstalled have a start level of 1, but, they used START_TRANSIENT in the previous framework start. On the restart, they never get beyond a start level of INSTALLED due do the transient start option. * The original JAR from which these bundles were started was a temporary file and will not be accessible on restarted (it's been deleted). The cached JAR and settings are of course still present. I don't recall any OSGi rule that says the original location/file that a bundle was installed from has to always be available, but maybe I forgot this? - Rob > NPE in BundleRevisionImpl.close() when uninstalling a bundle > ------------------------------------------------------------ > > Key: FELIX-3160 > URL: https://issues.apache.org/jira/browse/FELIX-3160 > Project: Felix > Issue Type: Bug > Components: Framework > Affects Versions: framework-4.0.0 > Reporter: Rob Walker > Assignee: Rob Walker > Priority: Minor > Fix For: framework-4.2.0 > > > There seems to be a case where m_content can be null when uninstalling a > bundle, causing the following code to throw an NPE: > synchronized void close() > { > try > { > resolve(null); > } > catch (Exception ex) > { > ((BundleImpl) m_bundle).getFramework().getLogger().log( > Logger.LOG_ERROR, "Error releasing revision: " + > ex.getMessage(), ex); > } > > m_content.close(); > I've added a simple check for null around the close in my version to avoid > the exception, which I'll check in. > I'm not sure of the scenarios where this can legally be null at this point, > and whether there's some nastier underlying circumstance that needs > investigating. We see it under the following circumstances: > * we register a listener that looks for framework STARTED > * when triggered, this iterates all bundles and performs an uninstall on ones > which we determine are zombies leftover from a previous run > Aside from the fact we're calling uninstall from inside an event handling > method, there doesn't anything else unusual about this code. -- 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