Community
Participate
Working Groups
Currently the Config Admin implements push mechanism to update targets with new configurations. A pull mechanism in addition to this is desirable. This pull mechanism should allow the call to getConfiguration to end in a custom component, which will return the configuration from custom storage, based on the calling context. Any caching of these configurations in the ConfigAdmin service is undesired.
Created attachment 197389 [details] equinox configuration manager patch allowing to replace file storage by custom implementation.
I also recently needed to replace default configuration persistent storage mechanism of equinox (replacing file by db storage). In order to avoid to write the whole thing I patched org.eclipse.equinox.cm. I just did a small code refactoring, extracting ina an interface, the code responsible for configuration saving/loading, and providing the existing file mechanism as default implementation. With the update I made on the code I can provide a custom persistence storage implementation, by packaging it in a fragment of org.eclipse.equinox.cm bundle, and giving the implementation to use, with an osgi.ini property or a System property I can share my patch here , if you think it can be useful
(In reply to comment #0) > Currently the Config Admin implements push mechanism to update targets with new > configurations. A pull mechanism in addition to this is desirable. This pull > mechanism should allow the call to getConfiguration to end in a custom > component, which will return the configuration from custom storage, based on > the calling context. Any caching of these configurations in the ConfigAdmin > service is undesired. Are you asking for anything more than the ability to configure a custom persistence mechanism?
(In reply to comment #3) > (In reply to comment #0) > > Currently the Config Admin implements push mechanism to update targets with new > > configurations. A pull mechanism in addition to this is desirable. This pull > > mechanism should allow the call to getConfiguration to end in a custom > > component, which will return the configuration from custom storage, based on > > the calling context. Any caching of these configurations in the ConfigAdmin > > service is undesired. > > Are you asking for anything more than the ability to configure a custom > persistence mechanism? The use case is to be able to get different configurations from a custom storage, based on call context information. Such logic for differentiating and getting different configuration could not be incorporated in the Configuration admin itself. That is why we need to be able to plug a custom component, which could take this decision, and to get the configuration from the custom storage - the call to getConfiguration() should be forwarded to the plugged component, and then the returned configuration should not be cached in the internal store of the Configuration admin. So probably this is more than providing custom store.
(In reply to comment #2) > I also recently needed to replace default configuration persistent storage > mechanism of equinox (replacing file by db storage). > > In order to avoid to write the whole thing I patched org.eclipse.equinox.cm. > I just did a small code refactoring, extracting ina an interface, the code > responsible for configuration saving/loading, and providing the existing file > mechanism as default implementation. > With the update I made on the code I can provide a custom persistence storage > implementation, by packaging it in a fragment of org.eclipse.equinox.cm bundle, > and giving the implementation to use, with an osgi.ini property or a System > property > > I can share my patch here , if you think it can be useful The problem was that we wanted to use the standard Configuration admin as much as possible, without forking the code and developing on our own. That is why we opened this enhancement request.
(In reply to comment #5) > The problem was that we wanted to use the standard Configuration admin as much > as possible, without forking the code and developing on our own. That is why we > opened this enhancement request. Same for me, but as it seems there is no way currently to customize configuration persistence, I had no choice. I hope there will be some mechanism provided later, in order to return back to the official code. While I was looking for opening an enhancement request, I found yours, that is quite related, even if it asks for more, so I decided to jump here
(In reply to comment #4) > The use case is to be able to get different configurations from a custom > storage, based on call context information. Do you need more contextual information than is already provided by the calls to the getConfiguration method (i.e. pid and location)?
(In reply to comment #7) > (In reply to comment #4) > > The use case is to be able to get different configurations from a custom > > storage, based on call context information. > > Do you need more contextual information than is already provided by the calls > to the getConfiguration method (i.e. pid and location)? With contextual information I mean information in the thread locale of the call, on which bases to determine exactly which configuration should be returned. This should be exactly a pull mechanism, which gets a configuration (no updates, just get) depending on information from the thread locale. And the configuration should be stored in a custom storage. This decision logic may be in a custom component, which could be plugged in the Configuration Admin.
Targeting this for review in 3.8. Would like to resolve Bug 348391 first. Bug 349191 and Bug 329688 may also affect the timing of this.
We are using June targets for next release.
Not happening for Juno.
I must say I don't fully understand the proposal for the pull mechanism here. I would need some more concrete proposal and likely a working patch that demostrates the desired behavior. I'm guessing the clients of the pull mechanism never use any of the traditional "push" ManagedService mechanisms to get configurations since there would be no context for such a push. For now I am closing as wontfix (In reply to Arnaud MERGEY from comment #1) > Created attachment 197389 [details] > equinox configuration manager patch allowing to replace file storage by > custom implementation. Arnaud, if you are still interested in this enhancement for custom storage I suggest you open a separate bug.
