I'm not really sure I like the bundle approach, it has some down-sides. Especially in the context of Karaf, the external configuration via the etc folder is well known and works reliable. I know it's a bit cumbersome if "NO" extra config is needed, but especially in a dev/ops separated environment (still the most-commonly-used) ops people just need to adapt the configurations.
How is an Update handled? When will the bundle-based or the etc-based config be used? It's ok for environments like the enroute one, where the result is a self-contained all-in-one executable jar with no extras like what we have in a container with Karaf. regards, Achim 2016-12-09 11:11 GMT+01:00 Christian Schneider <[email protected]>: > The default config is in the bundle. Basically it simply uses an extender > bundle that looks for the config in all bundles and writes the config to > config admin > if there is not already a config. > > So if the user wants to change a config he does it using config admin. > > I think the configurator might even work with karaf already. > > Christian > > > > On 09.12.2016 10:45, Jean-Baptiste Onofré wrote: > >> Hi Christian, >> >> I like your idea ! However, definitely, it means it's for Karaf 4.1.x at >> least (not 4.0.x) as it's kind of breaking change. >> >> For the enroute configurer, does it mean that the config file is part of >> the bundle ? How the user is changing/updating the configuration ? >> Can you point where does it live at Felix (I didn't see it) ? >> Thanks ! >> >> Regards >> JB >> >> On 12/09/2016 10:25 AM, Christian Schneider wrote: >> >>> I would ike to make a different proposal. >>> >>> We could add a url to config. So people could use this: >>> <config pid="org.my.config" url="mvn:..."/> >>> >>> In this case the config would be deployed to the etc dir and config >>> admin would be updated immediately. >>> >>> <configFile> would then be used exclusively to deploy files that are not >>> related to config admin. I think we could then even rename the element >>> to <file> so the purpose is more clear. We could do this whenever we >>> need a new feature xsd. >>> >>> Apart from this I really like the approach of the enroute configurer >>> which seems to be a spec now with impl at felix. There default configs >>> are deployed inside bundles in a special directory. I think this >>> approach is even better than refering to config files in the feature. >>> 1. It is easier to do in the build as you just put the config into >>> src/main/resources. No need to change the pom. >>> 2. The approach also works outside karaf as it does not rely on the >>> karaf features. We could even enhance this by optionally copying the >>> config files into etc to achieve the current karaf behaviour. >>> >>> So in the long run I could imagine to rely on configurer for config >>> admin configs and only use an element <file> to deploy arbitrary files. >>> >>> Christian// >>> >>> On 08.12.2016 15:42, Jean-Baptiste Onofré wrote: >>> >>>> It means that we have to check on the final name (not the URL). And on >>>> the final name we have to check the target subfolder (cfg goes in etc >>>> but we can put something in bar folder using configfile for instance) >>>> and the extension of the final name (.cfg). >>>> >>>> Regards >>>> JB >>>> >>>> On Dec 8, 2016, 15:35, at 15:35, Guillaume Nodet <[email protected]> >>>> wrote: >>>> >>>>> Instead of trying to guess the format of the config file, we could >>>>> simpy >>>>> use the extension I think. >>>>> The <configfile> element has both the file name and the url. So if the >>>>> file name ends with ".cfg", we assume we can write the content to >>>>> configadmin directly. I'm not sure I see a real problem here. >>>>> >>>>> 2016-12-08 15:28 GMT+01:00 Guillaume Nodet <[email protected]>: >>>>> >>>>> >>>>>> 2016-12-08 15:27 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >>>>>> >>>>>> Yes, Achim already replied and I fully agree. >>>>>>> >>>>>>> So, I wonder if it makes sense to do ConfigAdmin configuration >>>>>>> >>>>>> creation >>>>> >>>>>> for <configfile/> as it would require to detect file format. >>>>>>> >>>>>>> Can we document that way: >>>>>>> 1. for cfg file, we recommend to use <config/> in feature XML >>>>>>> 2. for any other file format, we recommend to use <configfile/> in >>>>>>> feature XML >>>>>>> ? >>>>>>> >>>>>>> That sounds to me the exact reason why we create those two elements >>>>>> >>>>> in the >>>>> >>>>>> first place. ;-) >>>>>> >>>>>> >>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> >>>>>>> On 12/08/2016 03:24 PM, Guillaume Nodet wrote: >>>>>>> >>>>>>> The <configfile> element supports any kind of configuration file, >>>>>>>> >>>>>>> not >>>>> >>>>>> only >>>>>>>> properties file. For example we use it for the xml configuration >>>>>>>> >>>>>>> of >>>>> >>>>>> jetty >>>>>>>> in pax-web. >>>>>>>> >>>>>>>> 2016-12-08 15:08 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>>> Some weeks ago we discussed on the mailing list about the fact >>>>>>>>> >>>>>>>> that a >>>>> >>>>>> feature using <configfile/> just creates the cfg file in the etc >>>>>>>>> >>>>>>>> folder, >>>>> >>>>>> and the corresponding configuration is created later by >>>>>>>>> >>>>>>>> ConfigAdmin >>>>> >>>>>> (thanks >>>>>>>>> to FileInstall). >>>>>>>>> This can produce unfortunate behavior as the bundles in the >>>>>>>>> >>>>>>>> feature can >>>>> >>>>>> be >>>>>>>>> started before the creation of the configuration in ConfigAdmin. >>>>>>>>> Christian proposes to create the configuration in ConfigAdmin as >>>>>>>>> >>>>>>>> soon as >>>>> >>>>>> the FeatureService deals with <configfile/> tag. >>>>>>>>> >>>>>>>>> On the other hand, in Karaf 4.0.5, we improved the <config/> tag: >>>>>>>>> >>>>>>>> the >>>>> >>>>>> FeatureService now creates the corresponding cfg file in etc based >>>>>>>>> >>>>>>>> on >>>>> >>>>>> the >>>>>>>>> <config/> tag content. >>>>>>>>> >>>>>>>>> So, with KARAF-4829, we will have the same behavior using >>>>>>>>> >>>>>>>> <config/> and >>>>> >>>>>> <configfile/>: >>>>>>>>> * <config/> will create the configuration in ConfigAdmin and the >>>>>>>>> >>>>>>>> cfg >>>>> >>>>>> file >>>>>>>>> * <configfile/> will create the cfg file and the configuration in >>>>>>>>> ConfigAdmin >>>>>>>>> >>>>>>>>> The difference is where the configuration comes from: >>>>>>>>> - an existing file (mvn URL) in the case of <configfile/> >>>>>>>>> - inner properties in the case of <config/> >>>>>>>>> >>>>>>>>> I wonder: >>>>>>>>> 1. does it make sense to have both <config/> and <configfile/> in >>>>>>>>> >>>>>>>> the >>>>> >>>>>> future (Karaf 4.1.x) ? >>>>>>>>> 2. should we do the change on <configfile/> in Karaf 4.0.x ? >>>>>>>>> >>>>>>>>> Thoughts ? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> JB >>>>>>>>> -- >>>>>>>>> Jean-Baptiste Onofré >>>>>>>>> [email protected] >>>>>>>>> http://blog.nanthrax.net >>>>>>>>> Talend - http://www.talend.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Jean-Baptiste Onofré >>>>>>> [email protected] >>>>>>> http://blog.nanthrax.net >>>>>>> Talend - http://www.talend.com >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> ------------------------ >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Red Hat, Open Source Integration >>>>>> >>>>>> Email: [email protected] >>>>>> Web: http://fusesource.com >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> ------------------------ >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Red Hat, Open Source Integration >>>>> >>>>> Email: [email protected] >>>>> Web: http://fusesource.com >>>>> Blog: http://gnodet.blogspot.com/ >>>>> >>>> >>> >>> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
