You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2011/02/09 23:51:00 UTC
[jira] Closed: (FELIX-2822) [Framework] System bundle module's
state not reset when framework restarted leading to NPE
[ 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 next.
> [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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Closed: (FELIX-2822) [Framework] System bundle module's
state not reset when framework restarted leading to NPE
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Thanks for the clarification.
Am Donnerstag, den 10.02.2011, 14:27 +0000 schrieb Richard S. Hall:
>
> 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.
This makes my case simpler because I can just install/update and
continue...
But take some more care for updates.
Regards
Felix
>
> > * 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.
>
> Karl?
>
> 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 next.
> >>
> >>> [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.
> >
Re: [jira] Closed: (FELIX-2822) [Framework] System bundle module's
state not reset when framework restarted leading to NPE
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
Karl?
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 next.
>>
>>> [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.
>
Re: [jira] Closed: (FELIX-2822) [Framework] System bundle module's
state not reset when framework restarted leading to NPE
Posted by Felix Meschberger <fm...@adobe.com>.
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.
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)
* 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 ;-)
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 next.
>
> > [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.
>