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.
