0

I'd like to create a Configuration object in OSGi, but one that won't be persisted, so it won't be there when the framework is restarted. Similar to START_TRANSIENT for bundles.

Some background: I've got an OSGi (Felix) based client side application, deployed over OBR. The configuration object I'm talking about effectively boots the application. That works fine, but sometimes the content has changed while the context was stopped. In that case, it boots the application as OSGi revives all bundles and adds all configuration options. Then I inject the correct configuration, the application stops and then restarts again.

So it does actually work, but the app starts twice, and I can't get access to the framework before it reconstructs its old state.

Any ideas?

Frank Lee
  • 2,728
  • 19
  • 30

3 Answers3

1

The OSGi Config Admin spec does not support this. I also do not know of a non-standard means either for any of the CM impls I am familiar with.

BJ Hargrave
  • 9,324
  • 1
  • 19
  • 27
1

As BJ said there is no standard support for this in the Configuration Admin spec.

However the Felix implementation supports two features which may help you. First, you can set the felix.cm.dir property which configures where the configadmin saves its internal state (which by default will be somewhere under the Framework storage directory). You could set this to a location that you control and then simply wipe it every time you start OSGi (you could also wipe out the entire OSGi Framework storage directory on every start... some people do this but it has wider consequences that what you asked for).

Second, if you need a bit more control, Felix ConfigAdmin supports customising its persistence with a PersistenceManager service. You could probably implement this and return empty/doesn't-exist for the particular pids that you want to control.

Neil Bartlett
  • 23,743
  • 4
  • 44
  • 77
  • Pity, I was afraid of that. I considered delaying starting the bundle that consumes the configuration using start levels, but that isn't going to work with OBR (? at least I see no way of setting start levels when deploying OBR). I'll think of some hack, none of the options are pretty ;-) Thanks man. – Frank Lee Jul 12 '12 at 07:07
0

Ok, what I did in the end was the following:

  • I created a special really small 'boot' bundle, which I do not provision from OBR, instead, I install it from the classpath.

  • That bundle controls the configuration, and I use START_TRANSIENT the moment I really want to load that configuration.

Not exactly pretty, it gets the job done. I do think transient configuration would make sense to have in OSGi.

Frank Lee
  • 2,728
  • 19
  • 30