On Saturday 01 October 2016 11:34:48 Carsten Ziegeler wrote: > Oliver Lietz wrote > > > On Friday 30 September 2016 14:00:23 Carsten Ziegeler wrote: > >> Atm the provisioning model has a slightly larger function set as karaf > >> features. We have support for framework properties and things like the > >> repo init stuff. > > > > I didn't find the statement in the OSGi spec (R6 core) you mentioned at > > adaptTo() which says framework properties can be set at runtime. > > > > I'm quite sure I looked at Felix source and docs (e.g. [1]) when it was a > > topic last year and didn't find anything there also. > > > > Can you point me to any significant source? (just to make sure it makes > > sense to have framework properties in features at all) > > It's true that you can't set framework properties at runtime, but you > can set system properties at runtime. And the documentation of > BundleContext#getProperty(String) says: > "Returns the value of the specified property. If the key is not found in > the Framework properties, the system properties are then searched". > > And this is the back door to set framework properties at runtime. Which > of course means that if a framework property is already set, setting it > through a system property is not possible, deleting is also not > possible. But I think all these cases are neglectable. As soon as two > features are providing values for a single property it gets difficult > anyway. > > However, if the launcher does not use framework properties at all and > relies on system properties completely this is dynamic as you can > add/remove/delete these at runtime. But of course the code needs to be > aware of this, usually bundles read the properties at > startup/activation, changing the props after they are started has > usually no effect. Changing the properties for the framework at runtime > usually has no effect either. I think all of this is fine. So we just > have to document the restrictions/behaviour clearly
Because of this difficulties (and portability between OSGi containers) I do prefer OSGi configurations where possible. And I agree that we have to much of them for getting Sling up and running (but that's an Oak issue). Regards, O. > Regards > > Carsten
