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 <tjwat...@us.ibm.com> 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 <briandeal...@gmail.com>
> To: Equinox development mailing list <equinox-dev@eclipse.org>,
> 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: equinox-dev-boun...@eclipse.org
>
>
>
> 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
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
