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 <[email protected]>
> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
