Here's the RFC: https://github.com/osgi/design/blob/master/rfcs/rfc0218/rfc-0218-Configurator.pdf and the impl https://github.com/apache/felix/tree/trunk/configurator
I'm reading it. 2016-12-09 10:45 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > 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/ >>>> >>> >> >> > -- > 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/
