Hello Ivo, Angelo, Since Ivo asked my opinion, I'm taking Angelo's reply as the base and I added some comments in-line below.
On 6 Oct 2010, at 16:44 , Angelo van der Sijpt wrote: > On Oct 6, 2010, at 4:10 PM, Ivo Ladage-van Doorn wrote: > >> 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 > > That is exactly what I intended. This bundle should make sure to only add or update a configuration if it really changed (compared to the data already in the Configuration Admin 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). One of the primary features of Configuration Admin is that it decouples managing the configuration of a service from the implementation of that service. So the concept that each bundle has its own configuration (opposed to bundles sharing a configuration) still exists, it's just not "managed" by the bundle that implements the service anymore. This, in my opinion, is not a bad thing. >> 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. I do not think this observation is true. First of all, when the bundle holding configurations for all other bundles is updated, it should probably (on being stopped) not remove any configuration it added in its "start" method (or rather, in the start method of the component that has a dependency on Configuration Admin). With that assumption, plus the comment made above that the bundle should not update a configuration unless it actually has a different one, means that you can update the configuration bundle at will, it will not affect already running bundles. Configuration changes will never stop bundles. They will also not stop services that have a dependency on a configuration. They will keep running and just be invoked on their ManagedService.updated(Dictionary) method. All in all, updating the configuration bundle will not cause any services or bundles to restart. > I agree that this is not _the_ proper approach, and it is not production > ready; the best approach would be one based on some external configuration > mechanism. However, I do believe that for the time being, we should move away > from the 'let's put file in the right location on the disc'-approach. The configuration bundle is just something we need as long as we do not have a mechanism to externally configure a framework. In the end, when moving to the cloud, configurations will probably be centrally managed and updated, sent to a framework as part of a deployment package. In that scenario, it's unlikely that any human will ever touch files on disk (in a cloud node). For cases where system administrators still have access to nodes, we should still consider some interface for them to edit the configuration that then gets translated into configurations for the services (as the link that Ivo mentioned above explains). >> - 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. > > Services should be able to cope with this (this is another point: I noticed > that many services have a very basic approach to 'getting' configurations, we > should use ManagedService for this). Not only "should", we "must" use ManagedService, because that is how the specification was intended. > By the way, if you need to update configuration while developing, and you > don't feel like deploying, you could use a shell command for this. I think this is where the Apache Felix Web Console can be used (or indeed the shell). However, in the end we need to work towards a situation where we can very rapidly deploy updates from within our development environment. To be honest, in my opinion, File install should never be used in production environments. It's a tool for developers, and that's the only place where we should use it. Managing configurations via files has a lot of issues that are hard to solve (partially written files that get picked up ending in "incomplete" configurations being pushed out, expensive polling mechanisms, little control over the exact moment at which updated configurations are "set", ...). >> 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. > > Hm, do you mean that we should keep a copy of the configuration that is in > Config Admin, on the disk? I think that defeats the purpose of having config > admin in the first place. I agree with Angelo on this one, we should not try to sync configurations from Configuration Admin back to disk. That could easily create silly loops where Configuration Admin changes, triggering an update of the file, which again triggers an update of the configuration. Configurations should be in Configuration Admin, and that service has mechanisms for manipulating configurations. >> - 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? My 2 cents... :) Greetings, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101007/bcd78502/attachment-0001.html
