karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSS] <config/> & <configfile/> in feature (KARAF-4829)
Date Fri, 09 Dec 2016 10:05:39 GMT
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é <jb@nanthrax.net>:

> 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 <gnodet@apache.org>
>>> 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 <gnodet@apache.org>:
>>>>
>>>>
>>>>> 2016-12-08 15:27 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>>>>
>>>>> 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é <jb@nanthrax.net>:
>>>>>>>
>>>>>>> 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é
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Red Hat, Open Source Integration
>>>>>
>>>>> Email: gnodet@redhat.com
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gnodet.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message