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

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.