[ https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128277#comment-13128277 ]
Richard S. Hall commented on FELIX-3160: ---------------------------------------- I created a bundle like this: public class Activator implements BundleActivator { public void start(final BundleContext bc) { bc.addFrameworkListener(new FrameworkListener() { public void frameworkEvent(FrameworkEvent event) { if (event.getType() == FrameworkEvent.STARTED) { for (Bundle b : bc.getBundles()) { if ((b.getBundleId() != 0) && (b != bc.getBundle()) && !b.getSymbolicName().startsWith("org.apache.felix.gogo")) { try { b.uninstall(); } catch (Exception ex) { System.out.println("+++ Uninstall error: " + ex); } } } } } }); } public void stop(BundleContext bc) { } } This was working for me, it was correctly deleting any non-shell bundles on framework restart. Perhaps there is something else I need to do to recreate. Perhaps you could see if my code above gives you an error too. Thanks. > 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