karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [DISCUSS] <config/> & <configfile/> in feature (KARAF-4829)
Date Fri, 09 Dec 2016 10:18:09 GMT
I'm not really sure I like the bundle approach,
it has some down-sides.

Especially in the context of Karaf, the external configuration via the etc
folder is well known and works reliable.
I know it's a bit cumbersome if "NO" extra config is needed, but especially
in a dev/ops separated environment (still the most-commonly-used) ops
people just need to adapt the configurations.

How is an Update handled? When will the bundle-based or the etc-based
config be used?

It's ok for environments like the enroute one, where the result is a
self-contained all-in-one executable jar with no extras like
what we have in a container with Karaf.

regards, Achim



2016-12-09 11:11 GMT+01:00 Christian Schneider <chris@die-schneider.net>:

> The default config is in the bundle. Basically it simply uses an extender
> bundle that looks for the config in all bundles and writes the config to
> config admin
> if there is not already a config.
>
> So if the user wants to change a config he does it using config admin.
>
> I think the configurator might even work with karaf already.
>
> Christian
>
>
>
> On 09.12.2016 10:45, Jean-Baptiste Onofré wrote:
>
>> 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/
>>>>>
>>>>
>>>
>>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 

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

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