[ https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148387#comment-13148387 ]
Rob Walker commented on FELIX-3160: ----------------------------------- Struggling to recreate in a simplified form. I don't think it's as simple as just the uninstall inside the handler for the framework STARTED event. I think it has something related to package admin - looking at the exception trace again, the log message I have after the uninstall has already been output. The Null pointer exception looks to happen asynchronously soon after: === 11-11-11 10:35:39 DEBUG - Removing transient bundle: com.ascert.transient.vt.lib.lib_4047819872618789.jar [36] 11-11-11 10:35:39 DEBUG - Framework error, bundle: com.ascert.transient.vt.lib.lib_4047819872618789.jar [36] java.lang.NullPointerException at org.apache.felix.framework.BundleRevisionImpl.close(BundleRevisionImpl.java:642) at org.apache.felix.framework.BundleImpl.closeRevisions(BundleImpl.java:154) at org.apache.felix.framework.BundleImpl.closeAndDelete(BundleImpl.java:138) at org.apache.felix.framework.Felix$RefreshHelper.refreshOrRemove(Felix.java:4640) at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3952) at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:172) at java.lang.Thread.run(Thread.java:662) === My cut down example still has the same package refresh code in, but as yet isn't tripping the issue. Will continue trying to recreate > 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