karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSS] <config/> & <configfile/> in feature (KARAF-4829)
Date Fri, 09 Dec 2016 09:25:38 GMT
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/


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


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