[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Framework state updated due to Bundle#getResources() against a bundle with dynamic import

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 <tjwatson@xxxxxxxxxx> 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 <briandealwis@xxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx





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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev