I'm familiar with the managedservice that's part of the specification. But i have always thought that it was slightly lacking in features.
What this project does is that it translates an interface with get methods into an object that handles metatypes and configuration updates automatically. Being just an interface, the configuration is also very easy to mock in unit tests, as it can be replaced by anything really. It is by no means a finished product, there are more features to add. But i think the current version works l, and reflects where i want to go with the project. I hope someone can use it at least. Im still getting into osgi, so there are no fancy DS integrations or anything, but it is easy to use, and removes the nees for a lot of code, especially in bundles that doesn't do DS. On 20 Nov 2016 8:27 p.m., "Jean-Baptiste Onofré" <[email protected]> wrote: > Hi Martin, > > I gonna take a look. > > By the way, you have a ManagedProperties sample in Karaf samples: > > https://github.com/jbonofre/karaf-samples/tree/master/osgi- > config-managed-service-bundle > > Regards > JB > > On 11/18/2016 11:21 PM, Martin Nielsen wrote: > >> Hello karaf users. >> >> I have been working on what i believe to be a simplification of the >> configuration handling in OSGi containers. The project is slated to be >> able to handle different sources, but for now the the only configuration >> source is the felix config admin. >> >> https://github.com/TDC-Netdesign/ManagedProperties >> >> The way it works is that you register an annotated interface, which is >> turned into a proxy that keeps track of the configuration for you. The >> proxy object is transparently updated whenever the configuration >> changes. It is also possible to register mappers, which can parse values >> into other types, for example a String to a File or an Long to an Instant. >> >> Most importantly the filters allow for validating data. This allows for >> checking the validity of the configuration before applying it. The >> MangedProperties object will revert to the last accepted configuration >> if a new configuration fails, eliminating the situation where the config >> admin holds a config set that was never applied. >> >> Two other features worth mentioning is the locking a callback functions. >> The properties object can lock itself, allowing any update to the >> configuration to be postponed. This is useful for combinations like >> username-password, where you do not want the configuration to change in >> between the calls. For example, you can lock the configuration before >> calling config.getUsername() and config.getPassword(). >> The last function is a ConfigurationCallback, that can be registered on >> the configuration object. When the configuration is updated the callback >> is called afterwards, allowing for restarts of message queues, rest >> clients or whatever is using the configuration but requires restarts >> with new configurations. >> >> I hope you will take a look at this project and use it/comment and >> participate, I look forward to your comments and i hope someone will >> find it useful. >> >> >> -Martin >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
