> > 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 Perhaps you mean subsystems? If so, than I see that more of a kar alternative. I think features are great thing to be a spec. You can then make kar or subsystem or whatever you want On Fri, Dec 9, 2016 at 11:30 AM, Achim Nierbeck <[email protected]> wrote: > 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 > -- http://about.me/milen
