I support Christian's idea regarding <config pid="org.my.config" url="mvn:..."/> and <file> I'm not so sure about the configurator - I find it a bit confusing on first read but I haven't paid too much attention to it.
However I like the direction. In fact I was about to ask in this list if making "features" an independent (from Karaf) OSGi project is something you would consider. I recently installed it into Liferay and why playing with it I realize it makes some assumptions about Karaf specific structure but those are rather easy to fix. I for one would love to have this as independent project and I believe this way more people would be interested in it and perhaps contribute to it. Best, Milen On Fri, Dec 9, 2016 at 11:05 AM, Guillaume Nodet <[email protected]> wrote: > 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/ > -- http://about.me/milen
