On Fri, Apr 1, 2016 at 8:09 AM, Balázs Zsoldos <[email protected]> wrote:
> Hi Raymond, > > must have been a lot of work :). We simply built it on top of our existing persistence and message-bus infrastructure so it wasn't really hard. > I will check it. May I ask, how you > trigger ConfigurationAdmin to call ManagedService or ConfigurationListener > services after a change is applied to the storage? > Every update to configurations is 1) persisted 2) triggers an message bus event propagated to peers in the cluster, they flush the local item from their cache (because there is an implementation of felix NotCachablePersitenceManager which does it's own caching) and ask the configuration to update (local framework only) using the typical update process. The implementation is open-source [1] if not "re-usable" in it's current form. You could use it for ideas. - Ray [1] https://github.com/liferay/liferay-portal/tree/master/modules/apps/foundation/portal-configuration > > Thanks and regards, > > *Balázs Zsoldos* > Rendszertervező | Software architect > > > On Fri, Apr 1, 2016 at 1:01 PM, Raymond Auge <[email protected]> > wrote: > > > You may want to know that config admin has a NotCachablePersitenceManager > > marker interface. With this interface you are able to implement stores > > which control their own cache and can trigger exactly the type of > external > > refresh you seek. > > > > With this we have implemented a db based persistence coupled with cluster > > link communication to trigger cluster wide updates. > > > > Coupled with fileinstall you could also have config files stored in VCS > dir > > which upon checkout are read simply by having a fileinstall instance > > pointing at said dir. > > > > HTH > > - Ray > > On Apr 1, 2016 6:39 AM, "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 > > > > > > > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
