The re-naming is ok for me, only the embedded config I don't think to be suited well with Karaf.
regarding features, yeah why not. It could be a real improvement to have a spec for this and it being a ref-implementation. But wasn't there some sort of spec for a similar thing? AFAIK there had been some talks about this in the past. regards, Achim 2016-12-09 11:20 GMT+01:00 Milen Dyankov <[email protected]>: > 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 > -- 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
