[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125986#comment-13125986
]
Rob Walker commented on FELIX-3160:
-----------------------------------
Certainly always happened our side.
Here's the code in our activator:
public void start(BundleContext context)
throws
Exception
{
this.context = context;
...
// Only run sweeper once fully started
this.context.addFrameworkListener(new FrameworkListener()
{
public void frameworkEvent(FrameworkEvent evt)
{
if (evt.getType() ==
FrameworkEvent.STARTED)
{
runSweeper();
}
else if (evt.getType() ==
FrameworkEvent.ERROR)
{
diag.debug("Framework error,
bundle: " + evt.getBundle(), evt.getThrowable());
}
}
});
}
We added the diag.debug when we started getting framework errors - that's what
nailed the source of the NPE
The runSweeper method is very simple. This is a framework restart - so we are
warm starting using previously cached and started bundles. The sweeper looks
for our transient bundles and cleans them out. They used START_TRANSIENT in the
last run of the framework, this time around they only reach an INSTALLED state
on startup.
protected void runSweeper()
{
// TODO Auto-generated method stub
for (Bundle bundle : this.context.getBundles())
{
try
{
if
(bundle.getSymbolicName().startsWith(VtLibrary.TRANSIENT_PREFIX) &&
bundle.getState() == Bundle.INSTALLED)
{
diag.debug("Removing transient bundle: " +
bundle.toString());
bundle.uninstall();
}
}
catch (BundleException be)
{
app.error("Watchdog: sweeper error removing transient bundle: "
+ bundle.getSymbolicName());
}
}
}
Not really sure what the trigger for m_content being null at uninstall time -
whether it's to do with the uninstall() being called from inside the event
handle, or whether some facet of the framework restart has left m_content null.
> 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
