I guess this is the only way. -- Andrea Cosentino ---------------------------------- Apache Camel PMC Member Apache Karaf Committer Apache Servicemix Committer Email: [email protected] Twitter: @oscerd2 Github: oscerd
On Thursday, December 8, 2016 3:43 PM, Jean-Baptiste Onofré <[email protected]> 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/
