felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [jira] Closed: (FELIX-2822) [Framework] System bundle module's state not reset when framework restarted leading to NPE
Date Thu, 10 Feb 2011 14:27:50 GMT

On 2/10/11 2:02, Felix Meschberger wrote:
> Hi Richard,
> This confuses me (and maybe I just don't know enough).
> So what you essentially say, is that after Framework.stop(), the system
> bundle is essentially in the RESOLVED state just like after an initial
> Framework.init() call ? Thus a call to init() after stop() processing
> completed has no effect ?
> This seems to be kind contradictory to the Framework.stop()
> documentation, which includes:
>> After being stopped, this Framework may be discarded, initialized or started.

It does not contradict the documentation, consider 4.2.3 which states:

    stop – Move the framework into the RESOLVED state via the STOPPING
    state. This will return a Framework STOPPED event from the
    waitForStop method. The Framework's Bundle Context is no longer
    valid. The framework must be initialized again to get a new, valid
    BundleContext. The stop method can be called on the framework or on
    the system bundle.

So, this is what I am saying. Stopping the framework does NOT move it 
back to the INSTALLED state, it moves it back to the RESOLVED state.

> Here is why I am asking: In Sling we do the following for an initial startup :
>    * Create Framework instance
>    * call Framework.init()
>    * install a bunch of bundles
>    * check whether one of the bundles is a framework extension bundle
>       * if so:
>            - call Framework.stop()
>            - call Framework.init() (once stop completed)

I believe with the currently released framework, this could lead to NPEs 
as described in the issue. Although, if you are not ever seeing them, I 
am not sure why. Also note that you should not need to stop the 
framework unless you are updating a framework extension bundle. 
Installing a framework extension bundle should take effect immediately.

>       * otherwise:
>            - continue with next step
>    * start the framework with Framework.start()
> The idea of calling stop()-init() is to make sure the system bundle can
> have the newly installed system extension fragments attached.
>  From your comment I would assume, this to not be possible and I would
> have to create a new Framework instance for that ? Would not be a big
> deal, but I would need to know ;-)

I'll let Karl comment on the specifics here, since he implemented this 
part. However, system bundle fragments are handled differently than 
normal bundles. When you stop the framework, all bundles should be 
refreshed if needed (i.e., if you updated any). When you restart, all 
bundles are reinstalled including framework extensions, which should be 
available immediately. Still, if you've loaded classes from previously 
attached framework extensions, these classes cannot go away until you 
completely throw away the class loader that loaded the framework, if I 
understand correctly.


In short, though, nothing I've done will prevent you from stopping a 
framework and restarting it...or at least it shouldn't.

-> richard

> Regards
> Felix
> Am Mittwoch, den 09.02.2011, 22:51 +0000 schrieb Richard S. Hall
> (JIRA):
>> [ https://issues.apache.org/jira/browse/FELIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> Richard S. Hall closed FELIX-2822.
>> ----------------------------------
>>      Resolution: Fixed
>> After thinking about it, I realize that the system bundle should be handled differently
than other bundles when the framework is stopped. Normal bundles are unresolved and effectively
discarded. The system bundle was being treated the same way, but this was causing a problem
since the framework instance can be reused.
>> To avoid this situation, since Felix extends BundleImpl, I just overrode BundleImpl.close()
to do nothing. Thus, when the framework stops all bundles except the system bundle are thrown
away. This means that once the framework is started, the system bundle continues to exist
and stays in the RESOLVED state forever, even after the framework stops.
>> This makes sense, because if you reuse the framework instance then the system bundle
doesn't need to be resolved again since it configuration cannot change from one run to the
>>> [Framework] System bundle module's state not reset when framework restarted leading
to NPE
>>> ------------------------------------------------------------------------------------------
>>>                  Key: FELIX-2822
>>>                  URL: https://issues.apache.org/jira/browse/FELIX-2822
>>>              Project: Felix
>>>           Issue Type: Bug
>>>           Components: Framework
>>>     Affects Versions: framework-3.0.8
>>>             Reporter: Richard S. Hall
>>>             Assignee: Richard S. Hall
>>>             Priority: Minor
>>>              Fix For: framework-3.2.0
>>> Normally when a bundle is refreshed, we throw away its module and then recreate
it, so we are always starting with a fresh module. For the system bundle, when we stop and
restart the framework, the system bundle module is reused. When the framework is restarted,
the system bundle module state is still resolved, so when we re-resolve it in Framework.init(),
it doesn't get empty wires injected into it since the resolver thinks it's resolved. This
leads to subsequent NPEs when the resolver tries to wire later modules to the system bundle.

View raw message