Hi Angelo, I analyzed the patch. If I'm correct the changes are:
- Configuration files are moved from each individual bundle to one central config bundle - Use of fileinstall to automatically create configuration entries in ConfigAdmin and set defaults is replaced by a service that does so upon starting the service I have the following remarks: - By moving all individual configuration files to one central configuration bundle, the idea of each bundle must manage its own configuration is a bit lost; the bundle itself and its configuration are disconnected (see this discussion: http://amdatu.org/confluence/display/Amdatu/Configuration+management). Another issue is that all bundles that use configuration (which will be a lot) will now depend on this one bundle. Effectively, when the config bundle needs to be updated because of a config change in bundle A, all other bundles that use configuration will go through stop/start as well. So from that perspective, I doubt that this is the proper approach. - In the fileinstall approach, configs could be managed by editing the files on disk. This is an advantage for system administrators who cannot change and deploy bundles. In the new approach when a config needs to be changed the bundle needs to be updated by a developer since configuration is updated each time the central config service starts. The latter could be fixed however, configuration properties could be added/set only if they don't exist yet. A positive thing now is that you can use ConfigAdmin to update configuration entries while in case of fileinstall this had to be done by editing the files on disk. However, the patch proposed looks very similar to the situation prior to introducing fileinstall. In my opinion the fileinstall approach is better, though it still needs some improvements: - Currently you can only update configuration by changing files on disk. It should be possible to use the ConfigAdmin java api for that too , so fileinstall should listen to changes in ConfigAdmin and write them back to the config files on disk. - I agree that copying the config files in the install phase of maven is not the proper way; when the config is changed updating the bundle would not change it on a runtime environment. Instead it should copy its config file to the fileinstall deploy directory when going thought the update phase of the OSGi lifecyle (however, without overwriting any changes). Marcel, what is your opinion about this issue? Regards, Ivo From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Ivo Ladage-van Doorn Sent: woensdag 6 oktober 2010 14:13 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Moving bundle configuration out of their source Hi Angelo, Before raising my opinion, could you attach the patch to the issue or send it? Just to make sure exactly what change you suggest. Regards, Ivo From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Angelo van der Sijpt Sent: woensdag 6 oktober 2010 14:04 To: amdatu-developers at amdatu.org Subject: [Amdatu-developers] Moving bundle configuration out of their source Hi, While going through the sources, I noticed that service configuration files are currently located in the sources of the bundles that use them, and that they're copied to the 'right' location during mvn install. This looks a little weird to me, so I created an issue about this. http://jira.amdatu.org/jira/browse/AMDATU-91 The best solution, until we have some nicer mechanism to handle configuration, is to place all configuration inside a single bundle, and have that bundle pass the configuration on to Config Admin. I have a patch waiting that just does that. Does anyone else have an opinion about this? Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101006/e114751b/attachment-0001.html
