You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/10/08 14:33:59 UTC
File install vs bundle cache
I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
I use iPOJO (1.6.4) to create service factories that are instantiated by
file install by dropping a configuration file in a dedicated directory. When
I update the configuration file, file install immediately propagates, the
changes to the instantiated service.
However, I can also change my configuration properties using configuration
manager directly (e g via the Felix web console). When I change
configuration properties this way, the properties are stored in
configuration manager's bundle cache but they are not propagated back to
file install and my configuration file.
This means that my configuration file (used by file install) can differ from
the configuration actually used and what is stored in the bundle cache. An
important question regarding this is which configuration takes precedence on
startup?
My tests indicate that what I specify in my configuration file (which is
picked up by file install) is the configuration that will be used directly
after startup. I need to know whether this behavior is guaranteed
(deterministic) or if this is just the way it happens to work in my case.
I think I can live with either scenario - file install taking precedence or
the bundle cache taking precedence - as long as the behavior is
deterministic.
/Bengt
Re: File install vs bundle cache
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 11.10.2010 14:21, Guillaume Nodet wrote:
> The Felix implementation has such a store abstraction, but unfortunately,
> it's not bi-directional, meaning it's really possible to let the store push
Yes, it is so by intent. The abstraction just allows the implementation
to use different persistence layers for its own internal store assuming
it is in full control of the layer and all changes go through the
official API as it is intended to be.
Regards
Felix
> some changes to config admin.
> Also, I haven't used that since I did not really want to have the karaf etc/
> folder poluted by lots of configurations and I wanted the user to be in
> control of those.
>
> On Mon, Oct 11, 2010 at 14:14, Bengt Rodehav <be...@rodehav.com> wrote:
>
>> Yes, you're of course right that there is a small period where the
>> configuration is not up-to-date. Probably the best we can do at this point
>> though.
>>
>> Ultimately I feel that some kind of SPI interface would be needed for
>> configuration admin. I mean what file install basically does is providing a
>> persistent store for certain configurations - *without the configuration
>> admin being aware of this*. Should there exist a formalised way to interact
>> with configuration admin (e g provide a means to register who will provide
>> the persistence of certain configurations) then this would work a lot
>> better. Do you know if anything is in the works in the OSGi specs?
>>
>> /Bengt
>>
>>
>> 2010/10/11 Guillaume Nodet <gn...@gmail.com>
>>
>>> On Mon, Oct 11, 2010 at 11:47, Bengt Rodehav <be...@rodehav.com> wrote:
>>>
>>>> The use of system properties as well? In that case, yes it would be a
>>> nice
>>>> feature.
>>>>
>>>> What we have in the feature shell is that if the end result
>> (interpolated
>>> value) has not changed, the original won't be changed either.
>>> However, if you modify a value which was interpolated, the interpolation
>>> will be lost.
>>> So the idea is that only diffs are written back.
>>>
>>>
>>>> I've been thinking about the risk with "unlucky timing" - is there
>> really
>>>> such a risk? I think configuration manager publishes an OSGi service
>> and
>>>> file install I imagine will require that service. If configuration
>>> manager
>>>> restores its state from the cache prior to publishing its service then
>>> the
>>>> startup sequence should be guaranteed - right?
>>>>
>>>
>>> Yes, AFAIK, the ConfigAdmin publishes its service when ready, but if its
>>> internal cache and the fileinstall config files aren't synchronized,
>> you'll
>>> still have a period during which the configuration will have the values
>>> they
>>> had at the previous shutdown, but will be overwritten by fileinstall
>> later
>>> on.
>>>
>>>
>>>>
>>>> /Bengt
>>>>
>>>> 2010/10/11 Guillaume Nodet <gn...@gmail.com>
>>>>
>>>>> The comments and formatting can all be preserved. I've done that as
>>> part
>>>>> of
>>>>> FELIX-1718, and I don't see why it could not be done from fileinstall
>>>>> itself.
>>>>>
>>>>> On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <be...@rodehav.com>
>>> wrote:
>>>>>
>>>>>> Felix and Guillaume,
>>>>>>
>>>>>> Yes I think that this must be the responsibility of file install
>>>>> (possible
>>>>>> configurable). However, this approach is generally a bit tricky
>>> since
>>>>> the
>>>>>> original configuration files would be overwritten programmatically.
>> I
>>>>> have
>>>>>> bad experience from this kind of approach.
>>>>>>
>>>>>> The configuration files need to be readable by humans and
>> will/should
>>>>>> contain comments and is probably formatted the way a user wants it.
>>>> Thus
>>>>>> this approach must preserver comments and formatting.
>>>>>>
>>>>>> Also, the configuration files might use system properties, e g
>>>>> ${mybasedir}
>>>>>> that must be honored. I think the "write back" approach can only
>> work
>>>> in
>>>>>> very simple scenarios (not mine I think).
>>>>>>
>>>>>> Currently, we regard changes done in the web console as "not
>>>> persistent"
>>>>>> and
>>>>>> tell our users that the values in the configuration files are the
>>>>>> persistent
>>>>>> values. Maybe not ideal but it works if we can guarantee this.
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>> 2010/10/11 Felix Meschberger <fm...@gmail.com>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 11.10.2010 08:51, Guillaume Nodet wrote:
>>>>>>>> On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <bengt@rodehav.com
>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install
>>>> 3.0.2.
>>>>>>>>>
>>>>>>>>> I use iPOJO (1.6.4) to create service factories that are
>>>>> instantiated
>>>>>> by
>>>>>>>>> file install by dropping a configuration file in a dedicated
>>>>>> directory.
>>>>>>>>> When
>>>>>>>>> I update the configuration file, file install immediately
>>>>> propagates,
>>>>>>> the
>>>>>>>>> changes to the instantiated service.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The files in etc/*.cfg are monitored by fileinstall and are
>> used
>>> to
>>>>>> feed
>>>>>>>> ConfigAdmin
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, I can also change my configuration properties using
>>>>>>> configuration
>>>>>>>>> manager directly (e g via the Felix web console). When I
>> change
>>>>>>>>> configuration properties this way, the properties are stored
>> in
>>>>>>>>> configuration manager's bundle cache but they are not
>> propagated
>>>>> back
>>>>>> to
>>>>>>>>> file install and my configuration file.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, it's a bit of a problem. Maybe a good thing would be to
>>>> have
>>>>>> the
>>>>>>>> webconsole plugin update the properties file directly when
>> inside
>>>>>> karaf,
>>>>>>> as
>>>>>>>> the command console do.
>>>>>>>
>>>>>>> As I said already, this would not be a good thing since the Web
>>>> Console
>>>>>>> only talks to the Configuration Admin service and does not know
>>> (and
>>>>>>> must not know) of other configuration sources.
>>>>>>>
>>>>>>> Instead File Install should probably implement a
>>>> ConfigurationListener
>>>>>>> which writes back modified configuration: File Install knows it
>>> sets
>>>>>>> configuration and it knows where it reads the config from and it
>>>> knows
>>>>>>> the file format. So it is File Install only which can safely
>> write
>>>> back
>>>>>>> (if required). See FELIX-2571.
>>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This means that my configuration file (used by file install)
>> can
>>>>>> differ
>>>>>>>>> from
>>>>>>>>> the configuration actually used and what is stored in the
>> bundle
>>>>>> cache.
>>>>>>> An
>>>>>>>>> important question regarding this is which configuration takes
>>>>>>> precedence
>>>>>>>>> on
>>>>>>>>> startup?
>>>>>>>>>
>>>>>>>>> My tests indicate that what I specify in my configuration file
>>>>> (which
>>>>>> is
>>>>>>>>> picked up by file install) is the configuration that will be
>>> used
>>>>>>> directly
>>>>>>>>> after startup. I need to know whether this behavior is
>>> guaranteed
>>>>>>>>> (deterministic) or if this is just the way it happens to work
>> in
>>>> my
>>>>>>> case.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, the files in etc/*.cfg should take precedence because
>>>>> fileinstall
>>>>>>> will
>>>>>>>> update all the configurations with what it founds in there, so
>>> any
>>>>>> change
>>>>>>>> done by another mean in ConfigAdmin will certainly be
>> overwritten
>>>> by
>>>>>>>> fileinstall.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I can live with either scenario - file install taking
>>>>>> precedence
>>>>>>> or
>>>>>>>>> the bundle cache taking precedence - as long as the behavior
>> is
>>>>>>>>> deterministic.
>>>>>>>>>
>>>>>>>>> /Bengt
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: File install vs bundle cache
Posted by Guillaume Nodet <gn...@gmail.com>.
The Felix implementation has such a store abstraction, but unfortunately,
it's not bi-directional, meaning it's really possible to let the store push
some changes to config admin.
Also, I haven't used that since I did not really want to have the karaf etc/
folder poluted by lots of configurations and I wanted the user to be in
control of those.
On Mon, Oct 11, 2010 at 14:14, Bengt Rodehav <be...@rodehav.com> wrote:
> Yes, you're of course right that there is a small period where the
> configuration is not up-to-date. Probably the best we can do at this point
> though.
>
> Ultimately I feel that some kind of SPI interface would be needed for
> configuration admin. I mean what file install basically does is providing a
> persistent store for certain configurations - *without the configuration
> admin being aware of this*. Should there exist a formalised way to interact
> with configuration admin (e g provide a means to register who will provide
> the persistence of certain configurations) then this would work a lot
> better. Do you know if anything is in the works in the OSGi specs?
>
> /Bengt
>
>
> 2010/10/11 Guillaume Nodet <gn...@gmail.com>
>
> > On Mon, Oct 11, 2010 at 11:47, Bengt Rodehav <be...@rodehav.com> wrote:
> >
> > > The use of system properties as well? In that case, yes it would be a
> > nice
> > > feature.
> > >
> > > What we have in the feature shell is that if the end result
> (interpolated
> > value) has not changed, the original won't be changed either.
> > However, if you modify a value which was interpolated, the interpolation
> > will be lost.
> > So the idea is that only diffs are written back.
> >
> >
> > > I've been thinking about the risk with "unlucky timing" - is there
> really
> > > such a risk? I think configuration manager publishes an OSGi service
> and
> > > file install I imagine will require that service. If configuration
> > manager
> > > restores its state from the cache prior to publishing its service then
> > the
> > > startup sequence should be guaranteed - right?
> > >
> >
> > Yes, AFAIK, the ConfigAdmin publishes its service when ready, but if its
> > internal cache and the fileinstall config files aren't synchronized,
> you'll
> > still have a period during which the configuration will have the values
> > they
> > had at the previous shutdown, but will be overwritten by fileinstall
> later
> > on.
> >
> >
> > >
> > > /Bengt
> > >
> > > 2010/10/11 Guillaume Nodet <gn...@gmail.com>
> > >
> > > > The comments and formatting can all be preserved. I've done that as
> > part
> > > > of
> > > > FELIX-1718, and I don't see why it could not be done from fileinstall
> > > > itself.
> > > >
> > > > On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <be...@rodehav.com>
> > wrote:
> > > >
> > > > > Felix and Guillaume,
> > > > >
> > > > > Yes I think that this must be the responsibility of file install
> > > > (possible
> > > > > configurable). However, this approach is generally a bit tricky
> > since
> > > > the
> > > > > original configuration files would be overwritten programmatically.
> I
> > > > have
> > > > > bad experience from this kind of approach.
> > > > >
> > > > > The configuration files need to be readable by humans and
> will/should
> > > > > contain comments and is probably formatted the way a user wants it.
> > > Thus
> > > > > this approach must preserver comments and formatting.
> > > > >
> > > > > Also, the configuration files might use system properties, e g
> > > > ${mybasedir}
> > > > > that must be honored. I think the "write back" approach can only
> work
> > > in
> > > > > very simple scenarios (not mine I think).
> > > > >
> > > > > Currently, we regard changes done in the web console as "not
> > > persistent"
> > > > > and
> > > > > tell our users that the values in the configuration files are the
> > > > > persistent
> > > > > values. Maybe not ideal but it works if we can guarantee this.
> > > > >
> > > > > /Bengt
> > > > >
> > > > > 2010/10/11 Felix Meschberger <fm...@gmail.com>
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On 11.10.2010 08:51, Guillaume Nodet wrote:
> > > > > > > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <bengt@rodehav.com
> >
> > > > wrote:
> > > > > > >
> > > > > > >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install
> > > 3.0.2.
> > > > > > >>
> > > > > > >> I use iPOJO (1.6.4) to create service factories that are
> > > > instantiated
> > > > > by
> > > > > > >> file install by dropping a configuration file in a dedicated
> > > > > directory.
> > > > > > >> When
> > > > > > >> I update the configuration file, file install immediately
> > > > propagates,
> > > > > > the
> > > > > > >> changes to the instantiated service.
> > > > > > >>
> > > > > > >
> > > > > > > The files in etc/*.cfg are monitored by fileinstall and are
> used
> > to
> > > > > feed
> > > > > > > ConfigAdmin
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> However, I can also change my configuration properties using
> > > > > > configuration
> > > > > > >> manager directly (e g via the Felix web console). When I
> change
> > > > > > >> configuration properties this way, the properties are stored
> in
> > > > > > >> configuration manager's bundle cache but they are not
> propagated
> > > > back
> > > > > to
> > > > > > >> file install and my configuration file.
> > > > > > >>
> > > > > > >
> > > > > > > Yeah, it's a bit of a problem. Maybe a good thing would be to
> > > have
> > > > > the
> > > > > > > webconsole plugin update the properties file directly when
> inside
> > > > > karaf,
> > > > > > as
> > > > > > > the command console do.
> > > > > >
> > > > > > As I said already, this would not be a good thing since the Web
> > > Console
> > > > > > only talks to the Configuration Admin service and does not know
> > (and
> > > > > > must not know) of other configuration sources.
> > > > > >
> > > > > > Instead File Install should probably implement a
> > > ConfigurationListener
> > > > > > which writes back modified configuration: File Install knows it
> > sets
> > > > > > configuration and it knows where it reads the config from and it
> > > knows
> > > > > > the file format. So it is File Install only which can safely
> write
> > > back
> > > > > > (if required). See FELIX-2571.
> > > > > >
> > > > > > Regards
> > > > > > Felix
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> This means that my configuration file (used by file install)
> can
> > > > > differ
> > > > > > >> from
> > > > > > >> the configuration actually used and what is stored in the
> bundle
> > > > > cache.
> > > > > > An
> > > > > > >> important question regarding this is which configuration takes
> > > > > > precedence
> > > > > > >> on
> > > > > > >> startup?
> > > > > > >>
> > > > > > >> My tests indicate that what I specify in my configuration file
> > > > (which
> > > > > is
> > > > > > >> picked up by file install) is the configuration that will be
> > used
> > > > > > directly
> > > > > > >> after startup. I need to know whether this behavior is
> > guaranteed
> > > > > > >> (deterministic) or if this is just the way it happens to work
> in
> > > my
> > > > > > case.
> > > > > > >>
> > > > > > >
> > > > > > > Yes, the files in etc/*.cfg should take precedence because
> > > > fileinstall
> > > > > > will
> > > > > > > update all the configurations with what it founds in there, so
> > any
> > > > > change
> > > > > > > done by another mean in ConfigAdmin will certainly be
> overwritten
> > > by
> > > > > > > fileinstall.
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> I think I can live with either scenario - file install taking
> > > > > precedence
> > > > > > or
> > > > > > >> the bundle cache taking precedence - as long as the behavior
> is
> > > > > > >> deterministic.
> > > > > > >>
> > > > > > >> /Bengt
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > > > For additional commands, e-mail: users-help@felix.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > > ------------------------
> > > > Blog: http://gnodet.blogspot.com/
> > > > ------------------------
> > > > Open Source SOA
> > > > http://fusesource.com
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: File install vs bundle cache
Posted by Bengt Rodehav <be...@rodehav.com>.
Yes, you're of course right that there is a small period where the
configuration is not up-to-date. Probably the best we can do at this point
though.
Ultimately I feel that some kind of SPI interface would be needed for
configuration admin. I mean what file install basically does is providing a
persistent store for certain configurations - *without the configuration
admin being aware of this*. Should there exist a formalised way to interact
with configuration admin (e g provide a means to register who will provide
the persistence of certain configurations) then this would work a lot
better. Do you know if anything is in the works in the OSGi specs?
/Bengt
2010/10/11 Guillaume Nodet <gn...@gmail.com>
> On Mon, Oct 11, 2010 at 11:47, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > The use of system properties as well? In that case, yes it would be a
> nice
> > feature.
> >
> > What we have in the feature shell is that if the end result (interpolated
> value) has not changed, the original won't be changed either.
> However, if you modify a value which was interpolated, the interpolation
> will be lost.
> So the idea is that only diffs are written back.
>
>
> > I've been thinking about the risk with "unlucky timing" - is there really
> > such a risk? I think configuration manager publishes an OSGi service and
> > file install I imagine will require that service. If configuration
> manager
> > restores its state from the cache prior to publishing its service then
> the
> > startup sequence should be guaranteed - right?
> >
>
> Yes, AFAIK, the ConfigAdmin publishes its service when ready, but if its
> internal cache and the fileinstall config files aren't synchronized, you'll
> still have a period during which the configuration will have the values
> they
> had at the previous shutdown, but will be overwritten by fileinstall later
> on.
>
>
> >
> > /Bengt
> >
> > 2010/10/11 Guillaume Nodet <gn...@gmail.com>
> >
> > > The comments and formatting can all be preserved. I've done that as
> part
> > > of
> > > FELIX-1718, and I don't see why it could not be done from fileinstall
> > > itself.
> > >
> > > On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <be...@rodehav.com>
> wrote:
> > >
> > > > Felix and Guillaume,
> > > >
> > > > Yes I think that this must be the responsibility of file install
> > > (possible
> > > > configurable). However, this approach is generally a bit tricky
> since
> > > the
> > > > original configuration files would be overwritten programmatically. I
> > > have
> > > > bad experience from this kind of approach.
> > > >
> > > > The configuration files need to be readable by humans and will/should
> > > > contain comments and is probably formatted the way a user wants it.
> > Thus
> > > > this approach must preserver comments and formatting.
> > > >
> > > > Also, the configuration files might use system properties, e g
> > > ${mybasedir}
> > > > that must be honored. I think the "write back" approach can only work
> > in
> > > > very simple scenarios (not mine I think).
> > > >
> > > > Currently, we regard changes done in the web console as "not
> > persistent"
> > > > and
> > > > tell our users that the values in the configuration files are the
> > > > persistent
> > > > values. Maybe not ideal but it works if we can guarantee this.
> > > >
> > > > /Bengt
> > > >
> > > > 2010/10/11 Felix Meschberger <fm...@gmail.com>
> > > >
> > > > > Hi,
> > > > >
> > > > > On 11.10.2010 08:51, Guillaume Nodet wrote:
> > > > > > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com>
> > > wrote:
> > > > > >
> > > > > >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install
> > 3.0.2.
> > > > > >>
> > > > > >> I use iPOJO (1.6.4) to create service factories that are
> > > instantiated
> > > > by
> > > > > >> file install by dropping a configuration file in a dedicated
> > > > directory.
> > > > > >> When
> > > > > >> I update the configuration file, file install immediately
> > > propagates,
> > > > > the
> > > > > >> changes to the instantiated service.
> > > > > >>
> > > > > >
> > > > > > The files in etc/*.cfg are monitored by fileinstall and are used
> to
> > > > feed
> > > > > > ConfigAdmin
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> However, I can also change my configuration properties using
> > > > > configuration
> > > > > >> manager directly (e g via the Felix web console). When I change
> > > > > >> configuration properties this way, the properties are stored in
> > > > > >> configuration manager's bundle cache but they are not propagated
> > > back
> > > > to
> > > > > >> file install and my configuration file.
> > > > > >>
> > > > > >
> > > > > > Yeah, it's a bit of a problem. Maybe a good thing would be to
> > have
> > > > the
> > > > > > webconsole plugin update the properties file directly when inside
> > > > karaf,
> > > > > as
> > > > > > the command console do.
> > > > >
> > > > > As I said already, this would not be a good thing since the Web
> > Console
> > > > > only talks to the Configuration Admin service and does not know
> (and
> > > > > must not know) of other configuration sources.
> > > > >
> > > > > Instead File Install should probably implement a
> > ConfigurationListener
> > > > > which writes back modified configuration: File Install knows it
> sets
> > > > > configuration and it knows where it reads the config from and it
> > knows
> > > > > the file format. So it is File Install only which can safely write
> > back
> > > > > (if required). See FELIX-2571.
> > > > >
> > > > > Regards
> > > > > Felix
> > > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> This means that my configuration file (used by file install) can
> > > > differ
> > > > > >> from
> > > > > >> the configuration actually used and what is stored in the bundle
> > > > cache.
> > > > > An
> > > > > >> important question regarding this is which configuration takes
> > > > > precedence
> > > > > >> on
> > > > > >> startup?
> > > > > >>
> > > > > >> My tests indicate that what I specify in my configuration file
> > > (which
> > > > is
> > > > > >> picked up by file install) is the configuration that will be
> used
> > > > > directly
> > > > > >> after startup. I need to know whether this behavior is
> guaranteed
> > > > > >> (deterministic) or if this is just the way it happens to work in
> > my
> > > > > case.
> > > > > >>
> > > > > >
> > > > > > Yes, the files in etc/*.cfg should take precedence because
> > > fileinstall
> > > > > will
> > > > > > update all the configurations with what it founds in there, so
> any
> > > > change
> > > > > > done by another mean in ConfigAdmin will certainly be overwritten
> > by
> > > > > > fileinstall.
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> I think I can live with either scenario - file install taking
> > > > precedence
> > > > > or
> > > > > >> the bundle cache taking precedence - as long as the behavior is
> > > > > >> deterministic.
> > > > > >>
> > > > > >> /Bengt
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > > For additional commands, e-mail: users-help@felix.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > > ------------------------
> > > Open Source SOA
> > > http://fusesource.com
> > >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: File install vs bundle cache
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Oct 11, 2010 at 11:47, Bengt Rodehav <be...@rodehav.com> wrote:
> The use of system properties as well? In that case, yes it would be a nice
> feature.
>
> What we have in the feature shell is that if the end result (interpolated
value) has not changed, the original won't be changed either.
However, if you modify a value which was interpolated, the interpolation
will be lost.
So the idea is that only diffs are written back.
> I've been thinking about the risk with "unlucky timing" - is there really
> such a risk? I think configuration manager publishes an OSGi service and
> file install I imagine will require that service. If configuration manager
> restores its state from the cache prior to publishing its service then the
> startup sequence should be guaranteed - right?
>
Yes, AFAIK, the ConfigAdmin publishes its service when ready, but if its
internal cache and the fileinstall config files aren't synchronized, you'll
still have a period during which the configuration will have the values they
had at the previous shutdown, but will be overwritten by fileinstall later
on.
>
> /Bengt
>
> 2010/10/11 Guillaume Nodet <gn...@gmail.com>
>
> > The comments and formatting can all be preserved. I've done that as part
> > of
> > FELIX-1718, and I don't see why it could not be done from fileinstall
> > itself.
> >
> > On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <be...@rodehav.com> wrote:
> >
> > > Felix and Guillaume,
> > >
> > > Yes I think that this must be the responsibility of file install
> > (possible
> > > configurable). However, this approach is generally a bit tricky since
> > the
> > > original configuration files would be overwritten programmatically. I
> > have
> > > bad experience from this kind of approach.
> > >
> > > The configuration files need to be readable by humans and will/should
> > > contain comments and is probably formatted the way a user wants it.
> Thus
> > > this approach must preserver comments and formatting.
> > >
> > > Also, the configuration files might use system properties, e g
> > ${mybasedir}
> > > that must be honored. I think the "write back" approach can only work
> in
> > > very simple scenarios (not mine I think).
> > >
> > > Currently, we regard changes done in the web console as "not
> persistent"
> > > and
> > > tell our users that the values in the configuration files are the
> > > persistent
> > > values. Maybe not ideal but it works if we can guarantee this.
> > >
> > > /Bengt
> > >
> > > 2010/10/11 Felix Meschberger <fm...@gmail.com>
> > >
> > > > Hi,
> > > >
> > > > On 11.10.2010 08:51, Guillaume Nodet wrote:
> > > > > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com>
> > wrote:
> > > > >
> > > > >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install
> 3.0.2.
> > > > >>
> > > > >> I use iPOJO (1.6.4) to create service factories that are
> > instantiated
> > > by
> > > > >> file install by dropping a configuration file in a dedicated
> > > directory.
> > > > >> When
> > > > >> I update the configuration file, file install immediately
> > propagates,
> > > > the
> > > > >> changes to the instantiated service.
> > > > >>
> > > > >
> > > > > The files in etc/*.cfg are monitored by fileinstall and are used to
> > > feed
> > > > > ConfigAdmin
> > > > >
> > > > >
> > > > >>
> > > > >> However, I can also change my configuration properties using
> > > > configuration
> > > > >> manager directly (e g via the Felix web console). When I change
> > > > >> configuration properties this way, the properties are stored in
> > > > >> configuration manager's bundle cache but they are not propagated
> > back
> > > to
> > > > >> file install and my configuration file.
> > > > >>
> > > > >
> > > > > Yeah, it's a bit of a problem. Maybe a good thing would be to
> have
> > > the
> > > > > webconsole plugin update the properties file directly when inside
> > > karaf,
> > > > as
> > > > > the command console do.
> > > >
> > > > As I said already, this would not be a good thing since the Web
> Console
> > > > only talks to the Configuration Admin service and does not know (and
> > > > must not know) of other configuration sources.
> > > >
> > > > Instead File Install should probably implement a
> ConfigurationListener
> > > > which writes back modified configuration: File Install knows it sets
> > > > configuration and it knows where it reads the config from and it
> knows
> > > > the file format. So it is File Install only which can safely write
> back
> > > > (if required). See FELIX-2571.
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >> This means that my configuration file (used by file install) can
> > > differ
> > > > >> from
> > > > >> the configuration actually used and what is stored in the bundle
> > > cache.
> > > > An
> > > > >> important question regarding this is which configuration takes
> > > > precedence
> > > > >> on
> > > > >> startup?
> > > > >>
> > > > >> My tests indicate that what I specify in my configuration file
> > (which
> > > is
> > > > >> picked up by file install) is the configuration that will be used
> > > > directly
> > > > >> after startup. I need to know whether this behavior is guaranteed
> > > > >> (deterministic) or if this is just the way it happens to work in
> my
> > > > case.
> > > > >>
> > > > >
> > > > > Yes, the files in etc/*.cfg should take precedence because
> > fileinstall
> > > > will
> > > > > update all the configurations with what it founds in there, so any
> > > change
> > > > > done by another mean in ConfigAdmin will certainly be overwritten
> by
> > > > > fileinstall.
> > > > >
> > > > >
> > > > >>
> > > > >> I think I can live with either scenario - file install taking
> > > precedence
> > > > or
> > > > >> the bundle cache taking precedence - as long as the behavior is
> > > > >> deterministic.
> > > > >>
> > > > >> /Bengt
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > For additional commands, e-mail: users-help@felix.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: File install vs bundle cache
Posted by Bengt Rodehav <be...@rodehav.com>.
The use of system properties as well? In that case, yes it would be a nice
feature.
I've been thinking about the risk with "unlucky timing" - is there really
such a risk? I think configuration manager publishes an OSGi service and
file install I imagine will require that service. If configuration manager
restores its state from the cache prior to publishing its service then the
startup sequence should be guaranteed - right?
/Bengt
2010/10/11 Guillaume Nodet <gn...@gmail.com>
> The comments and formatting can all be preserved. I've done that as part
> of
> FELIX-1718, and I don't see why it could not be done from fileinstall
> itself.
>
> On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > Felix and Guillaume,
> >
> > Yes I think that this must be the responsibility of file install
> (possible
> > configurable). However, this approach is generally a bit tricky since
> the
> > original configuration files would be overwritten programmatically. I
> have
> > bad experience from this kind of approach.
> >
> > The configuration files need to be readable by humans and will/should
> > contain comments and is probably formatted the way a user wants it. Thus
> > this approach must preserver comments and formatting.
> >
> > Also, the configuration files might use system properties, e g
> ${mybasedir}
> > that must be honored. I think the "write back" approach can only work in
> > very simple scenarios (not mine I think).
> >
> > Currently, we regard changes done in the web console as "not persistent"
> > and
> > tell our users that the values in the configuration files are the
> > persistent
> > values. Maybe not ideal but it works if we can guarantee this.
> >
> > /Bengt
> >
> > 2010/10/11 Felix Meschberger <fm...@gmail.com>
> >
> > > Hi,
> > >
> > > On 11.10.2010 08:51, Guillaume Nodet wrote:
> > > > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com>
> wrote:
> > > >
> > > >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
> > > >>
> > > >> I use iPOJO (1.6.4) to create service factories that are
> instantiated
> > by
> > > >> file install by dropping a configuration file in a dedicated
> > directory.
> > > >> When
> > > >> I update the configuration file, file install immediately
> propagates,
> > > the
> > > >> changes to the instantiated service.
> > > >>
> > > >
> > > > The files in etc/*.cfg are monitored by fileinstall and are used to
> > feed
> > > > ConfigAdmin
> > > >
> > > >
> > > >>
> > > >> However, I can also change my configuration properties using
> > > configuration
> > > >> manager directly (e g via the Felix web console). When I change
> > > >> configuration properties this way, the properties are stored in
> > > >> configuration manager's bundle cache but they are not propagated
> back
> > to
> > > >> file install and my configuration file.
> > > >>
> > > >
> > > > Yeah, it's a bit of a problem. Maybe a good thing would be to have
> > the
> > > > webconsole plugin update the properties file directly when inside
> > karaf,
> > > as
> > > > the command console do.
> > >
> > > As I said already, this would not be a good thing since the Web Console
> > > only talks to the Configuration Admin service and does not know (and
> > > must not know) of other configuration sources.
> > >
> > > Instead File Install should probably implement a ConfigurationListener
> > > which writes back modified configuration: File Install knows it sets
> > > configuration and it knows where it reads the config from and it knows
> > > the file format. So it is File Install only which can safely write back
> > > (if required). See FELIX-2571.
> > >
> > > Regards
> > > Felix
> > >
> > > >
> > > >
> > > >>
> > > >> This means that my configuration file (used by file install) can
> > differ
> > > >> from
> > > >> the configuration actually used and what is stored in the bundle
> > cache.
> > > An
> > > >> important question regarding this is which configuration takes
> > > precedence
> > > >> on
> > > >> startup?
> > > >>
> > > >> My tests indicate that what I specify in my configuration file
> (which
> > is
> > > >> picked up by file install) is the configuration that will be used
> > > directly
> > > >> after startup. I need to know whether this behavior is guaranteed
> > > >> (deterministic) or if this is just the way it happens to work in my
> > > case.
> > > >>
> > > >
> > > > Yes, the files in etc/*.cfg should take precedence because
> fileinstall
> > > will
> > > > update all the configurations with what it founds in there, so any
> > change
> > > > done by another mean in ConfigAdmin will certainly be overwritten by
> > > > fileinstall.
> > > >
> > > >
> > > >>
> > > >> I think I can live with either scenario - file install taking
> > precedence
> > > or
> > > >> the bundle cache taking precedence - as long as the behavior is
> > > >> deterministic.
> > > >>
> > > >> /Bengt
> > > >>
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: File install vs bundle cache
Posted by Guillaume Nodet <gn...@gmail.com>.
The comments and formatting can all be preserved. I've done that as part of
FELIX-1718, and I don't see why it could not be done from fileinstall
itself.
On Mon, Oct 11, 2010 at 10:02, Bengt Rodehav <be...@rodehav.com> wrote:
> Felix and Guillaume,
>
> Yes I think that this must be the responsibility of file install (possible
> configurable). However, this approach is generally a bit tricky since the
> original configuration files would be overwritten programmatically. I have
> bad experience from this kind of approach.
>
> The configuration files need to be readable by humans and will/should
> contain comments and is probably formatted the way a user wants it. Thus
> this approach must preserver comments and formatting.
>
> Also, the configuration files might use system properties, e g ${mybasedir}
> that must be honored. I think the "write back" approach can only work in
> very simple scenarios (not mine I think).
>
> Currently, we regard changes done in the web console as "not persistent"
> and
> tell our users that the values in the configuration files are the
> persistent
> values. Maybe not ideal but it works if we can guarantee this.
>
> /Bengt
>
> 2010/10/11 Felix Meschberger <fm...@gmail.com>
>
> > Hi,
> >
> > On 11.10.2010 08:51, Guillaume Nodet wrote:
> > > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com> wrote:
> > >
> > >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
> > >>
> > >> I use iPOJO (1.6.4) to create service factories that are instantiated
> by
> > >> file install by dropping a configuration file in a dedicated
> directory.
> > >> When
> > >> I update the configuration file, file install immediately propagates,
> > the
> > >> changes to the instantiated service.
> > >>
> > >
> > > The files in etc/*.cfg are monitored by fileinstall and are used to
> feed
> > > ConfigAdmin
> > >
> > >
> > >>
> > >> However, I can also change my configuration properties using
> > configuration
> > >> manager directly (e g via the Felix web console). When I change
> > >> configuration properties this way, the properties are stored in
> > >> configuration manager's bundle cache but they are not propagated back
> to
> > >> file install and my configuration file.
> > >>
> > >
> > > Yeah, it's a bit of a problem. Maybe a good thing would be to have
> the
> > > webconsole plugin update the properties file directly when inside
> karaf,
> > as
> > > the command console do.
> >
> > As I said already, this would not be a good thing since the Web Console
> > only talks to the Configuration Admin service and does not know (and
> > must not know) of other configuration sources.
> >
> > Instead File Install should probably implement a ConfigurationListener
> > which writes back modified configuration: File Install knows it sets
> > configuration and it knows where it reads the config from and it knows
> > the file format. So it is File Install only which can safely write back
> > (if required). See FELIX-2571.
> >
> > Regards
> > Felix
> >
> > >
> > >
> > >>
> > >> This means that my configuration file (used by file install) can
> differ
> > >> from
> > >> the configuration actually used and what is stored in the bundle
> cache.
> > An
> > >> important question regarding this is which configuration takes
> > precedence
> > >> on
> > >> startup?
> > >>
> > >> My tests indicate that what I specify in my configuration file (which
> is
> > >> picked up by file install) is the configuration that will be used
> > directly
> > >> after startup. I need to know whether this behavior is guaranteed
> > >> (deterministic) or if this is just the way it happens to work in my
> > case.
> > >>
> > >
> > > Yes, the files in etc/*.cfg should take precedence because fileinstall
> > will
> > > update all the configurations with what it founds in there, so any
> change
> > > done by another mean in ConfigAdmin will certainly be overwritten by
> > > fileinstall.
> > >
> > >
> > >>
> > >> I think I can live with either scenario - file install taking
> precedence
> > or
> > >> the bundle cache taking precedence - as long as the behavior is
> > >> deterministic.
> > >>
> > >> /Bengt
> > >>
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: File install vs bundle cache
Posted by Bengt Rodehav <be...@rodehav.com>.
Felix and Guillaume,
Yes I think that this must be the responsibility of file install (possible
configurable). However, this approach is generally a bit tricky since the
original configuration files would be overwritten programmatically. I have
bad experience from this kind of approach.
The configuration files need to be readable by humans and will/should
contain comments and is probably formatted the way a user wants it. Thus
this approach must preserver comments and formatting.
Also, the configuration files might use system properties, e g ${mybasedir}
that must be honored. I think the "write back" approach can only work in
very simple scenarios (not mine I think).
Currently, we regard changes done in the web console as "not persistent" and
tell our users that the values in the configuration files are the persistent
values. Maybe not ideal but it works if we can guarantee this.
/Bengt
2010/10/11 Felix Meschberger <fm...@gmail.com>
> Hi,
>
> On 11.10.2010 08:51, Guillaume Nodet wrote:
> > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com> wrote:
> >
> >> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
> >>
> >> I use iPOJO (1.6.4) to create service factories that are instantiated by
> >> file install by dropping a configuration file in a dedicated directory.
> >> When
> >> I update the configuration file, file install immediately propagates,
> the
> >> changes to the instantiated service.
> >>
> >
> > The files in etc/*.cfg are monitored by fileinstall and are used to feed
> > ConfigAdmin
> >
> >
> >>
> >> However, I can also change my configuration properties using
> configuration
> >> manager directly (e g via the Felix web console). When I change
> >> configuration properties this way, the properties are stored in
> >> configuration manager's bundle cache but they are not propagated back to
> >> file install and my configuration file.
> >>
> >
> > Yeah, it's a bit of a problem. Maybe a good thing would be to have the
> > webconsole plugin update the properties file directly when inside karaf,
> as
> > the command console do.
>
> As I said already, this would not be a good thing since the Web Console
> only talks to the Configuration Admin service and does not know (and
> must not know) of other configuration sources.
>
> Instead File Install should probably implement a ConfigurationListener
> which writes back modified configuration: File Install knows it sets
> configuration and it knows where it reads the config from and it knows
> the file format. So it is File Install only which can safely write back
> (if required). See FELIX-2571.
>
> Regards
> Felix
>
> >
> >
> >>
> >> This means that my configuration file (used by file install) can differ
> >> from
> >> the configuration actually used and what is stored in the bundle cache.
> An
> >> important question regarding this is which configuration takes
> precedence
> >> on
> >> startup?
> >>
> >> My tests indicate that what I specify in my configuration file (which is
> >> picked up by file install) is the configuration that will be used
> directly
> >> after startup. I need to know whether this behavior is guaranteed
> >> (deterministic) or if this is just the way it happens to work in my
> case.
> >>
> >
> > Yes, the files in etc/*.cfg should take precedence because fileinstall
> will
> > update all the configurations with what it founds in there, so any change
> > done by another mean in ConfigAdmin will certainly be overwritten by
> > fileinstall.
> >
> >
> >>
> >> I think I can live with either scenario - file install taking precedence
> or
> >> the bundle cache taking precedence - as long as the behavior is
> >> deterministic.
> >>
> >> /Bengt
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: File install vs bundle cache
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 11.10.2010 08:51, Guillaume Nodet wrote:
> On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com> wrote:
>
>> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
>>
>> I use iPOJO (1.6.4) to create service factories that are instantiated by
>> file install by dropping a configuration file in a dedicated directory.
>> When
>> I update the configuration file, file install immediately propagates, the
>> changes to the instantiated service.
>>
>
> The files in etc/*.cfg are monitored by fileinstall and are used to feed
> ConfigAdmin
>
>
>>
>> However, I can also change my configuration properties using configuration
>> manager directly (e g via the Felix web console). When I change
>> configuration properties this way, the properties are stored in
>> configuration manager's bundle cache but they are not propagated back to
>> file install and my configuration file.
>>
>
> Yeah, it's a bit of a problem. Maybe a good thing would be to have the
> webconsole plugin update the properties file directly when inside karaf, as
> the command console do.
As I said already, this would not be a good thing since the Web Console
only talks to the Configuration Admin service and does not know (and
must not know) of other configuration sources.
Instead File Install should probably implement a ConfigurationListener
which writes back modified configuration: File Install knows it sets
configuration and it knows where it reads the config from and it knows
the file format. So it is File Install only which can safely write back
(if required). See FELIX-2571.
Regards
Felix
>
>
>>
>> This means that my configuration file (used by file install) can differ
>> from
>> the configuration actually used and what is stored in the bundle cache. An
>> important question regarding this is which configuration takes precedence
>> on
>> startup?
>>
>> My tests indicate that what I specify in my configuration file (which is
>> picked up by file install) is the configuration that will be used directly
>> after startup. I need to know whether this behavior is guaranteed
>> (deterministic) or if this is just the way it happens to work in my case.
>>
>
> Yes, the files in etc/*.cfg should take precedence because fileinstall will
> update all the configurations with what it founds in there, so any change
> done by another mean in ConfigAdmin will certainly be overwritten by
> fileinstall.
>
>
>>
>> I think I can live with either scenario - file install taking precedence or
>> the bundle cache taking precedence - as long as the behavior is
>> deterministic.
>>
>> /Bengt
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: File install vs bundle cache
Posted by Guillaume Nodet <gn...@gmail.com>.
THere is certainly a point in time, between when the config admin is started
and when the configuration are given to it by fileinstall where the
configuration may not have the right values.
This could happen if someone modified the configurations by another mean
that file install.
Felix is right that fileinstall would be better to listen for such changes
and write them back to the config files.
I'll try to find some time to fix that.
On Mon, Oct 11, 2010 at 09:57, Bengt Rodehav <be...@rodehav.com> wrote:
> Guillaume,
>
> Are you sure that this always works? Could "unlucky timing" cause the
> bundle
> cache to take precedence over file install?
>
> Doesn't this require that configuration manager's cached values have been
> restored BEFORE file install starts to propagate changes? Is this
> guaranteed?
>
> /Bengt
>
> 2010/10/11 Guillaume Nodet <gn...@gmail.com>
>
> > On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com> wrote:
> >
> > > I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
> > >
> > > I use iPOJO (1.6.4) to create service factories that are instantiated
> by
> > > file install by dropping a configuration file in a dedicated directory.
> > > When
> > > I update the configuration file, file install immediately propagates,
> the
> > > changes to the instantiated service.
> > >
> >
> > The files in etc/*.cfg are monitored by fileinstall and are used to feed
> > ConfigAdmin
> >
> >
> > >
> > > However, I can also change my configuration properties using
> > configuration
> > > manager directly (e g via the Felix web console). When I change
> > > configuration properties this way, the properties are stored in
> > > configuration manager's bundle cache but they are not propagated back
> to
> > > file install and my configuration file.
> > >
> >
> > Yeah, it's a bit of a problem. Maybe a good thing would be to have the
> > webconsole plugin update the properties file directly when inside karaf,
> as
> > the command console do.
> >
> >
> > >
> > > This means that my configuration file (used by file install) can differ
> > > from
> > > the configuration actually used and what is stored in the bundle cache.
> > An
> > > important question regarding this is which configuration takes
> precedence
> > > on
> > > startup?
> > >
> > > My tests indicate that what I specify in my configuration file (which
> is
> > > picked up by file install) is the configuration that will be used
> > directly
> > > after startup. I need to know whether this behavior is guaranteed
> > > (deterministic) or if this is just the way it happens to work in my
> case.
> > >
> >
> > Yes, the files in etc/*.cfg should take precedence because fileinstall
> will
> > update all the configurations with what it founds in there, so any change
> > done by another mean in ConfigAdmin will certainly be overwritten by
> > fileinstall.
> >
> >
> > >
> > > I think I can live with either scenario - file install taking
> precedence
> > or
> > > the bundle cache taking precedence - as long as the behavior is
> > > deterministic.
> > >
> > > /Bengt
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: File install vs bundle cache
Posted by Bengt Rodehav <be...@rodehav.com>.
Guillaume,
Are you sure that this always works? Could "unlucky timing" cause the bundle
cache to take precedence over file install?
Doesn't this require that configuration manager's cached values have been
restored BEFORE file install starts to propagate changes? Is this
guaranteed?
/Bengt
2010/10/11 Guillaume Nodet <gn...@gmail.com>
> On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
> >
> > I use iPOJO (1.6.4) to create service factories that are instantiated by
> > file install by dropping a configuration file in a dedicated directory.
> > When
> > I update the configuration file, file install immediately propagates, the
> > changes to the instantiated service.
> >
>
> The files in etc/*.cfg are monitored by fileinstall and are used to feed
> ConfigAdmin
>
>
> >
> > However, I can also change my configuration properties using
> configuration
> > manager directly (e g via the Felix web console). When I change
> > configuration properties this way, the properties are stored in
> > configuration manager's bundle cache but they are not propagated back to
> > file install and my configuration file.
> >
>
> Yeah, it's a bit of a problem. Maybe a good thing would be to have the
> webconsole plugin update the properties file directly when inside karaf, as
> the command console do.
>
>
> >
> > This means that my configuration file (used by file install) can differ
> > from
> > the configuration actually used and what is stored in the bundle cache.
> An
> > important question regarding this is which configuration takes precedence
> > on
> > startup?
> >
> > My tests indicate that what I specify in my configuration file (which is
> > picked up by file install) is the configuration that will be used
> directly
> > after startup. I need to know whether this behavior is guaranteed
> > (deterministic) or if this is just the way it happens to work in my case.
> >
>
> Yes, the files in etc/*.cfg should take precedence because fileinstall will
> update all the configurations with what it founds in there, so any change
> done by another mean in ConfigAdmin will certainly be overwritten by
> fileinstall.
>
>
> >
> > I think I can live with either scenario - file install taking precedence
> or
> > the bundle cache taking precedence - as long as the behavior is
> > deterministic.
> >
> > /Bengt
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: File install vs bundle cache
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Oct 8, 2010 at 14:33, Bengt Rodehav <be...@rodehav.com> wrote:
> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
>
> I use iPOJO (1.6.4) to create service factories that are instantiated by
> file install by dropping a configuration file in a dedicated directory.
> When
> I update the configuration file, file install immediately propagates, the
> changes to the instantiated service.
>
The files in etc/*.cfg are monitored by fileinstall and are used to feed
ConfigAdmin
>
> However, I can also change my configuration properties using configuration
> manager directly (e g via the Felix web console). When I change
> configuration properties this way, the properties are stored in
> configuration manager's bundle cache but they are not propagated back to
> file install and my configuration file.
>
Yeah, it's a bit of a problem. Maybe a good thing would be to have the
webconsole plugin update the properties file directly when inside karaf, as
the command console do.
>
> This means that my configuration file (used by file install) can differ
> from
> the configuration actually used and what is stored in the bundle cache. An
> important question regarding this is which configuration takes precedence
> on
> startup?
>
> My tests indicate that what I specify in my configuration file (which is
> picked up by file install) is the configuration that will be used directly
> after startup. I need to know whether this behavior is guaranteed
> (deterministic) or if this is just the way it happens to work in my case.
>
Yes, the files in etc/*.cfg should take precedence because fileinstall will
update all the configurations with what it founds in there, so any change
done by another mean in ConfigAdmin will certainly be overwritten by
fileinstall.
>
> I think I can live with either scenario - file install taking precedence or
> the bundle cache taking precedence - as long as the behavior is
> deterministic.
>
> /Bengt
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: File install vs bundle cache
Posted by Bengt Rodehav <be...@rodehav.com>.
I'm not entirely sure that you guys understand my point of view. Yes, I
think its a good idea to have something like file install to administrate
and store my configurations. Yes, I would like the possibility to plug in my
own configuration manager as well - personally I would appreciate a database
based approach to this when the number of configurations become large.
However, configuration admin (as specified by OSGi I assume) today has too
many responsibilities. It is in charge of:
- Storing configurations persistently ("model")
- Propagating configurations ("view")
- Change configurations ("controller")
I think that OSGi should split that up a bit (kind of like MVC). I probably
have no need to implement my own propagation mechanism for configurations. I
would probably always use the configuration admin for that. However, storing
and changing existing configurations is something I would most likely like
to plug-in using different mechanisms. But this requires the configuration
admin (the spec - not the Felix implementation of it) to open up for this.
Ultimately, it's not a matter of having file install listen for
configuration changes by configuration admin to update itself. This may be
the best we can do right now but the real solution is to register file
install as a configuration "provider" for certain configurations.
Configuration admin should know that a specific configuration is managed by
file install and should always ask file install for those configurations.
When any configuration is changed, configuration admin should propagate it
back to the owner (e g file install).
/Bengt
I think there is definitely a need for improvement in the OSGi specification
in the area of configuration admin...
/Bengt
2010/10/11 Richard S. Hall <he...@ungoverned.org>
> I see this was thoroughly discussed already...I guess I should read ahead.
> ;-)
>
> -> richard
>
>
>
> On 10/11/10 9:42, Richard S. Hall wrote:
>
>> Felix Meschberger thinks this is because File Install keeps overwriting
>> any new values set through the web console with the old values in the config
>> file. I don't think this is necessarily by design and relates to:
>>
>> https://issues.apache.org/jira/browse/FELIX-2571
>>
>> -> richard
>>
>>
>> On 10/8/10 8:33, Bengt Rodehav wrote:
>>
>>> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
>>>
>>> I use iPOJO (1.6.4) to create service factories that are instantiated by
>>> file install by dropping a configuration file in a dedicated directory.
>>> When
>>> I update the configuration file, file install immediately propagates, the
>>> changes to the instantiated service.
>>>
>>> However, I can also change my configuration properties using
>>> configuration
>>> manager directly (e g via the Felix web console). When I change
>>> configuration properties this way, the properties are stored in
>>> configuration manager's bundle cache but they are not propagated back to
>>> file install and my configuration file.
>>>
>>> This means that my configuration file (used by file install) can differ
>>> from
>>> the configuration actually used and what is stored in the bundle cache.
>>> An
>>> important question regarding this is which configuration takes precedence
>>> on
>>> startup?
>>>
>>> My tests indicate that what I specify in my configuration file (which is
>>> picked up by file install) is the configuration that will be used
>>> directly
>>> after startup. I need to know whether this behavior is guaranteed
>>> (deterministic) or if this is just the way it happens to work in my case.
>>>
>>> I think I can live with either scenario - file install taking precedence
>>> or
>>> the bundle cache taking precedence - as long as the behavior is
>>> deterministic.
>>>
>>> /Bengt
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: File install vs bundle cache
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I see this was thoroughly discussed already...I guess I should read
ahead. ;-)
-> richard
On 10/11/10 9:42, Richard S. Hall wrote:
> Felix Meschberger thinks this is because File Install keeps
> overwriting any new values set through the web console with the old
> values in the config file. I don't think this is necessarily by design
> and relates to:
>
> https://issues.apache.org/jira/browse/FELIX-2571
>
> -> richard
>
>
> On 10/8/10 8:33, Bengt Rodehav wrote:
>> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
>>
>> I use iPOJO (1.6.4) to create service factories that are instantiated by
>> file install by dropping a configuration file in a dedicated
>> directory. When
>> I update the configuration file, file install immediately propagates,
>> the
>> changes to the instantiated service.
>>
>> However, I can also change my configuration properties using
>> configuration
>> manager directly (e g via the Felix web console). When I change
>> configuration properties this way, the properties are stored in
>> configuration manager's bundle cache but they are not propagated back to
>> file install and my configuration file.
>>
>> This means that my configuration file (used by file install) can
>> differ from
>> the configuration actually used and what is stored in the bundle
>> cache. An
>> important question regarding this is which configuration takes
>> precedence on
>> startup?
>>
>> My tests indicate that what I specify in my configuration file (which is
>> picked up by file install) is the configuration that will be used
>> directly
>> after startup. I need to know whether this behavior is guaranteed
>> (deterministic) or if this is just the way it happens to work in my
>> case.
>>
>> I think I can live with either scenario - file install taking
>> precedence or
>> the bundle cache taking precedence - as long as the behavior is
>> deterministic.
>>
>> /Bengt
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: File install vs bundle cache
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Felix Meschberger thinks this is because File Install keeps
overwriting any new values set through the web console with the old
values in the config file. I don't think this is necessarily by design
and relates to:
https://issues.apache.org/jira/browse/FELIX-2571
-> richard
On 10/8/10 8:33, Bengt Rodehav wrote:
> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
>
> I use iPOJO (1.6.4) to create service factories that are instantiated by
> file install by dropping a configuration file in a dedicated directory. When
> I update the configuration file, file install immediately propagates, the
> changes to the instantiated service.
>
> However, I can also change my configuration properties using configuration
> manager directly (e g via the Felix web console). When I change
> configuration properties this way, the properties are stored in
> configuration manager's bundle cache but they are not propagated back to
> file install and my configuration file.
>
> This means that my configuration file (used by file install) can differ from
> the configuration actually used and what is stored in the bundle cache. An
> important question regarding this is which configuration takes precedence on
> startup?
>
> My tests indicate that what I specify in my configuration file (which is
> picked up by file install) is the configuration that will be used directly
> after startup. I need to know whether this behavior is guaranteed
> (deterministic) or if this is just the way it happens to work in my case.
>
> I think I can live with either scenario - file install taking precedence or
> the bundle cache taking precedence - as long as the behavior is
> deterministic.
>
> /Bengt
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: File install vs bundle cache
Posted by Bengt Rodehav <be...@rodehav.com>.
Can anyone explain how this works? Maybe someone working with file install?
/Bengt
2010/10/8 Bengt Rodehav <be...@rodehav.com>
> I'm using Karaf 1.6.0 (Felix 2.0.5 I think) and File install 3.0.2.
>
> I use iPOJO (1.6.4) to create service factories that are instantiated by
> file install by dropping a configuration file in a dedicated directory. When
> I update the configuration file, file install immediately propagates, the
> changes to the instantiated service.
>
> However, I can also change my configuration properties using configuration
> manager directly (e g via the Felix web console). When I change
> configuration properties this way, the properties are stored in
> configuration manager's bundle cache but they are not propagated back to
> file install and my configuration file.
>
> This means that my configuration file (used by file install) can differ
> from the configuration actually used and what is stored in the bundle cache.
> An important question regarding this is which configuration takes precedence
> on startup?
>
> My tests indicate that what I specify in my configuration file (which is
> picked up by file install) is the configuration that will be used directly
> after startup. I need to know whether this behavior is guaranteed
> (deterministic) or if this is just the way it happens to work in my case.
>
> I think I can live with either scenario - file install taking precedence or
> the bundle cache taking precedence - as long as the behavior is
> deterministic.
>
> /Bengt
>