cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: OSGi Bundles, Re: svn commit: r292305
Date Sun, 02 Oct 2005 09:50:42 GMT
Niclas Hedhman wrote:

>On Sunday 02 October 2005 00:40, Daniel Fagerstrom wrote:
>>The metatype service in R4 is schema driven like the Knopflerfish one,
>>don't know if there are any open source implementations yet.
>Ok. Then I need to take a look at that.
>>For server use it is impractical with interactive parameter
>>modification. Here we could develop a configuration file driven
>>configuration service implementation. That either use a large
>>configuration file that configures everything in the app or a set of
>>configuration snippets, for making configuration less monolithic.
>This is an area I am struggling with conviction at the moment.
>OSGi is built on the premise that a platform restart will bring back the last 
>"known state", including the Configuration set for a ManagedService.
The key issue is the form of the "known state". If it is in some obscure 
binary format, I wouldn't trust it for my interactvely added data. If it 
instead was in some explicit and readable form, like XML. Then I might 
belive that I could restart the framework from an inconsistent state 
after having tweaked the state description, or after having resumed an 
earlier one from backup.

I think this is an important point for the Felix project to find a way 
to handle persistance that we can use in enterprise systems.

>If I dared to make this a reality, the interactive config actually makes 
> 1. The ManagedService exposes its expected configuration in its registration,
>    by publishing the defaults for everything.
> 2. The Config service manages the persistence.
> 3. One or many Config Admin services can be created to modify the
>    configuration in runtime, and the Config service will track it correctly.
>I guess a "Export" functionality in the Config Admin service would be needed 
>to allow to restore the configuration after a real "cold start" (removal of 
>OSGi cache directories).

>I am just not comfortable at the moment to let OSGi start from 'previously 
>known state'... Guess I don't have faith in my own bundles. :o)
Neither have I, yet. And if I had to put faith in that all third party 
bundles are good citisens as well for being able to restart the system, 
it rather shows that the mechanism is to fragile. So we need explicit 
state as discussed above.


View raw message