Hi Jan, I know about the fileinstall solution, but I have problems with it. The issue comes with factories. Configadmin generates a pid for that with an UUID. Configadmin implementation disallows any programmers to create a configuration with pre-defined PID. As this is not possible, solutions like fileinstall start using a workaround that there is some mapping between the real PID and the one picked up from a location. What are the problems with this?
- It is not possible to export back the configuration to the source repository if the developer creates a new configuration on the webconsole. - If a workaround is done for the first issue that mapping works in the other direction, too, it is still a workaround. It expects that it knows about the logic of every technology, but it does not. What if the newly created pid is referenced from another configuration? E.g.: Within a service filter of a component reference. - If the server is started with a new configuration, ConfigAdmin must pick up the deprecated config first and then the new config can be applied. We cannot upgrade configuration offline. Having a “refresh” on ConfigAdmin suggests that you’re directly mangling > the back- > end storage of ConfigAdmin. This seems a nice way of doing things, but in > the long > term will bite you one way or the other (concurrency issues of filesystem > level, > etc.). That is true if there is a chance that the filesystem is modified parallel. In my use-cases, it does not happen. My use-cases are not based on regular automatic polls, but event driven calls where two events will hardly happen at the same time. But let's say this is an issue, and I agree that it could cause an inconsistent state. Here is another idea: What if we have a low-level function that can create a configuration with a pre-defined PID? I guess 100 of developers asked for this previously, and they were rejected as it would break the consistency of the ConfigurationAdmin interface. But would it? What do we win with this? We feel safer? Those developers, who would break the concept with this low-level function, will find other ways to break it with workarounds. E.g.: They will create a solution that makes the system start with the deprecated config first and then applies the new one, and also prevents another solution that can export the configuration ;-). In my opinion, if it is noted in the Javadoc, that the function should be used in exceptional cases, it should be enough. Thanks and regards *Balázs **Zsoldos* On Fri, Apr 1, 2016 at 12:39 PM, Jan Willem Janssen < [email protected]> wrote: > > > On 01 Apr 2016, at 12:09, Balázs Zsoldos <[email protected]> > wrote: > > > > I would like a function in felix-configadmin, that loads all of the > > configuration from the storage, and if there are any changes, it applies > > them. > > IIRC ConfigAdmin is already quite smart in that it only provisions > configurations > that are changed/deleted. This would only mean that you need to figure out > that > you need to ask ConfigAdmin to re-provision such a configuration in case > it changed. > > How these changes are passed to ConfigAdmin is the responsibility of > another > entity. Amdatu Configurator, Felix AutoConf resource processor or Felix > FileInstall > are examples of such entities. These entities can do all kinds of “smart" > things, > like watch Git repositories, Etcd spaces or get notified in case of > changes, and > push forward the changes to ConfigAdmin. > > Having a “refresh” on ConfigAdmin suggests that you’re directly mangling > the back- > end storage of ConfigAdmin. This seems a nice way of doing things, but in > the long > term will bite you one way or the other (concurrency issues of filesystem > level, > etc.). I’d rather not go this way. > > > -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > > My world is something with Amdatu and Apache > > Luminis Technologies > Churchillplein 1 > 7314 BZ Apeldoorn > +31 88 586 46 00 > > https://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8170.94.441.B.01 > >
