Description Urs 2010-11-26 17:00:49 EST

Build Identifier: virgo-web-server-2.1.0.RELEASE

When a value in a configuration artifact (properties file) is updated then the properties of a (container/bean) managed bean, which is linked to this configuration artifact, are not refreshed. 
(Updating means manually adjusting the properties file it in the pickup folder directly or uninstall it and reinstall a changed version.) 
Only a refresh of the bundle containing the (container/bean) managed bean will cause the adjusted value to be reloaded.
After investigating this issue I found the reason of this in my eyes incorrect behaviour:
1. When Spring initializes the managed bean it looks up the ConfigurationAdmin and retrieves the Configuration belonging to the managed bean eagerly. The retrieved Configuration is then used to eagerly populate the properties of the managed bean. As part of the initialization process a ConfigurationWatcher is registered as ManagedService in order to listen to configuration updates. (See org.springframework.osgi.compendium.internal.cm.ConfigurationAdminManager) However, as I will explain later, the update method of the ManagedService will never be called. 
2. When the underlying configuration artifact is updated it *is* picked up by felix' ConfigurationManager implementation org.apache.felix.cm.impl.ConfigurationManager. However, the change is never propagated to Spring's ConfigurationWatcher ManagedService described in step 1. The reason can be found in the org.apache.felix.cm.impl.ConfigurationManager innerclass UpdateConfiguration.run method. When executed this method will lookup the correct ConfigurationWatcher ManagedService using the persistent id but the update method is never called because the *location* of the bundle containing the managed bean and the configuration artifact do not match. See code fragment: 
if ( !userRefLocation.equals( configBundleLocation ) ) {
 log( LogService.LOG_ERROR, "Cannot use configuration " + config.getPid() + "   for " + ConfigurationManager.toString( userRef ) + ": Configuration bound to bundle "+ configBundleLocation, null );
continue;
}
Consequently, I get the expected error message:
 *ERROR* Cannot use configuration org.eclipse.virgo.sample.configuration.my.prop for [org.osgi.service.cm.ManagedService, id=152, bundle=36]: Configuration bound to bundle file:lib/kernel/org.eclipse.virgo.kernel.deployer-2.1.0.RELEASE.jar
According to osgi’s configurationAdmin spec (http://www.osgi.org/download/r4v42/r4.cmpn.pdf see section: 104.4.4) it is indeed correct that the pid AND location must match in order for a properties change to be propagated. However, it conflicts with the Spring implementation, which assumes that the persistent id suffices to map managed beans to configuration artifact, making its ConfigurationWatcher ManagedBean useless. 

In order to reproduce this problem I included a simple test app, which contains a Timer, which continuously reads and prints a managed property value. As you can see the property value is never changed when the underlying configuration artifact is adjusted in any way until the bundle itself is restarted. A Debugger will prove that the ConfigurationWatcher’s update method will never be called.
Since we depend on this behaviour I chose severity Major. 
Thanks for looking into this in advanced.


Reproducible: Always

Steps to Reproduce:
1. Create a bundle containing a service bean with a managed property for instance: myProp listening to pid 'my.conf'
2. Create a configuration artifact 'my.conf.properties' with contents: myProp=someValue
3. Deploy the bundle and the configuration artifact by placing them in the pickup folder
4. Open my.conf.properties and change the value to 'someOtherValue'. Save the file.
5. Even though this change is detected by the ConfigurationAdmin it is never propagated to Spring's ConfigurationWatcher ManagedService. Instead, the following error message is logged: 
*ERROR* Cannot use configuration my.conf for [org.osgi.service.cm.ManagedService, id=152, bundle=36]: Configuration bound to bundle file:lib/kernel/org.eclipse.virgo.kernel.deployer-2.1.0.RELEASE.jar
PS: under step 4, the configuration artifact my.conf.properties can also be uninstalled, and a new version with a changed property value can be installed. The unwanted behavior stays the same.
PPS: Preferably run test app