>
> 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
to much interferences of two projects for my taste and absolutely not OSGi
way ...
This is a tight coupling and not loose coupling.
regards, Achim
2016-12-09 11:36 GMT+01:00 Christian Schneider :
> You are right. This will be a problem. Maybe we can feed this into the
> development at felix.
>
You are right. This will be a problem. Maybe we can feed this into the
development at felix.
As fileinstall is also at felix they might be interested to solve this
anyway.
I will open an issue.
Christian
On 09.12.2016 11:32, Achim Nierbeck wrote:
But this will only work, if the configuration
But this will only work, if the configuration passed through the
file-installer is faster then the extender ...
and this timing I really don't want to rely on.
regards, Achim
2016-12-09 11:30 GMT+01:00 Christian Schneider :
> As far as I understood the config from inside the bundle is only appli
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
As far as I understood the config from inside the bundle is only applied
if config admin does not already have a config.
So if there is a config in etc or in plain config admin it will always
be prefered over the default.
I think the configurator would currently work in karaf like the old
conf
Thanks, I'm reading it as well ;)
Regards
JB
On 12/09/2016 11:05 AM, Guillaume Nodet 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:4
I support Christian's idea regarding and
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 proje
OK, so assuming the corresponding file is in etc folder (so the
configuration is in configadmin), the user can still change in the cfg
file in config.
So, basically, instead of having the configuration file "external" to
the bundle, the configuration is embedded in the bundle, which make
sens
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
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 migh
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é :
> Hi Christian,
>
> I like your idea ! However, definitely,
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
I would ike to make a different proposal.
We could add a url to config. So people could use this:
In this case the config would be deployed to the etc dir and config
admin would be updated immediately.
would then be used exclusively to deploy files that are not
related to config admin. I t
14 matches
Mail list logo
