Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330678

Summary: ConfigurationListener.configurationEvent() called twice when a configuration is changed in pickup directory
Product: [RT] Virgo Reporter: Peter Lauri <peterlauri>
Component: unknownAssignee: Glyn Normington <glyn.normington>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P3 CC: glyn.normington, zteve.powell
Version: 2.1.0.RELEASE   
Target Milestone: 3.0.0.M01   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Log output when running the attached bundle
none
Maven2 project that contains bundle that registeres ConfigurationListener none

Description Peter Lauri CLA 2010-11-19 11:24:54 EST 
Build Identifier: virgo-web-server-2.1.0.RELEASE

A bundle that registers the ConfigurationListener will get two updates when a configuration that was put in the pickup directory is modified on file system. Same if deploying configurations via virgo web admin.

Reproducible: Always

Steps to Reproduce:
1. Install bundle that registers ConfigurationAdmin listening to com.pjotr
2. Install configuration by copy properties file to pickup. Correct event is gotten (just one time).
3. Change the configuration file in the pickup directory, the configurationEvent will be called twice.
Comment 1 Peter Lauri CLA 2010-11-19 11:26:33 EST 
Created attachment 183483 [details]
Log output when running the attached bundle
Comment 2 Peter Lauri CLA 2010-11-19 11:27:27 EST 
Created attachment 183484 [details]
Maven2 project that contains bundle that registeres ConfigurationListener
Comment 3 Peter Lauri CLA 2010-11-20 15:18:33 EST 
Tested on Windows and Linux and got same result.
Comment 4 Steve Powell CLA 2010-12-08 05:09:42 EST 
Glyn,
I've set this assigned, since you are to look at this in this sprint.

I'm not at all sure that this isn't 'working as designed'.  If the configuration artifact is modified in the pickup directory, then it will trigger a redeploy, and the update will be called for undeploy as well as deploy.  It would be really interesting to see what the configuration dictionary contains for these two update calls—my bet is that it is empty(null) on the first update call, and then populated on the second.

There appears to be no way of uninstalling a configuration, save that of reporting a null dictionary update to the registered ManagedService.
Comment 5 Glyn Normington CLA 2010-12-08 11:13:17 EST 
The behaviour is incorrect. Updating the properties file in pickup causes it to be deployed. The install portion of deploy is optimised to do a refresh (expected since the configuration is already deployed) and this causes the configuration to be updated. The start portion of deploy causes the configuration to be updated again. Unlike bundles, where start of an ACTIVE artifact has no effect, start of an ACTIVE configuration artifact produces an extraneous update.

The fix is to improve the handling of all install artifacts so that start processing is skipped if the artifact is already ACTIVE. I also added a regression test along similar lines to the testcase you provided so this bug won't accidentally creep back in.

Thanks for being observant and bothering to raise this bug. It will benefit others longer term.