I assume you have some code that is calling methods like Bundle.start() which persistently mark a bundle to be activated when the framework is restarted. If you do not want a bundle to be persistently marked for activation then you should use a transient start flag [1] when calling Bundle.start(options) methods.
Tom [1] http://www.osgi.org/javadoc/r5/core/org/osgi/framework/Bundle.html#START_TRANSIENT From: Brian de Alwis <[email protected]> To: Equinox development mailing list <[email protected]>, Date: 06/26/2013 02:02 PM Subject: Re: [equinox-dev] Framework state updated due to Bundle#getResources() against a bundle with dynamic import Sent by: [email protected] Hi Tom. Your question about the cached restart has just triggered a memory — we're running with osgi.clean so as to avoid re-starting bundles as we had some very expensive activators. Time to revisit the need for that flag. Is there any way to tell Equinox to not persist the bundle activation state? Brian. On 25-Jun-2013, at 4:12 PM, Thomas Watson <[email protected]> wrote: Hi Brian, Is this from a cached restart? This bit of code is supposed to track both dynamic resolution successes and failures. I would expect that on a cached restart the dynamic resolution misses (for META-INF) would all have been recorded and it should not cause another dynamic resolution if you are calling find resources on all the bundles again. Tom <graycol.gif>Brian de Alwis ---06/25/2013 02:51:12 PM---I have some somewhat badly-behaved code that searches through all bundles to find resources by a par From: Brian de Alwis <[email protected]> To: Equinox development mailing list <[email protected]>, Date: 06/25/2013 02:51 PM Subject: [equinox-dev] Framework state updated due to Bundle#getResources() against a bundle with dynamic import Sent by: [email protected] I have some somewhat badly-behaved code that searches through all bundles to find resources by a particular name ("META-INF/AppRegistration.xml"). I've found that this causes the framework state's timestamp to be updated, even though there's been no configuration change. This behaviour is a bit problematic as we were using this state timestamp to determine if the framework configuration had changed. In digging through the code, the state timestamp is updated if the dynamic cache changes. StateManager#saveNeeded(): public boolean saveNeeded() { return systemState.getTimeStamp() != lastTimeStamp || systemState .dynamicCacheChanged(); } StateImpl#setDynamicCacheChanged() is called a whenever a Bundle#getResources() is called on a bundle with a DynamicImport-Package or some other dynamic import — regardless of whether the lookup was successful. A stack snippet is below: Thread [main] (Suspended (entry into method setDynamicCacheChanged in StateImpl)) owns: Object (id=205) SystemState(StateImpl).setDynamicCacheChanged(boolean) line: 1167 SystemState(StateImpl).linkDynamicImport(BundleDescription, String) line: 1046 BundleLoader.findDynamicSource(String) line: 1167 BundleLoader.findResources(String) line: 692 BundleLoader.getResources(String) line: 795 BundleHost.getResources(String) line: 290 Activator.getResources(String) line: 216 findDynamicSource(): private PackageSource findDynamicSource(String pkgName) { if (isDynamicallyImported(pkgName)) { ExportPackageDescription exportPackage = bundle.getFramework ().getAdaptor().getState().linkDynamicImport(proxy .getBundleDescription(), pkgName); if (exportPackage != null) { This happens with any bundle that has a "DynamicImport-Package: *", such as org.drools.api or org.mybatis.mybatis. I'm a bit surprised that a dynamic lookup resets the timestamp since the actual framework configuration hasn't changed, and presumably this lookup should be deterministic? Brian. _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
