felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Walker (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
Date Mon, 17 Oct 2011 08:52:11 GMT

    [ 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

        

Mime
View raw message