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