As an example lets see how you can use this provider to configure Pax Logging. Pax Logging can be configured via Configuration Admin via a Managed Service with pid "org.ops4j.pax.logging". The configuration properties are the same as the ones used to configure log4j.
Lets say that we want to configure Pax Logging that in certain circumstances to use an INFO log level and sometimes to use DEBUG. To do this you can:

• create a bundle that has the following structure (let's call it log.config.info):

  META-INF |- config |- org.ops4j.pax.logging.properties

  The content of org.ops4j.pax.logging.properties could be:

  log4j.rootLogger=INFO, CONSOLE log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.layout=org.apache.log4j.TTCCLayout

• create another bundle that with the same structure as above (let's call it log.config.debug), and the content of org.ops4j.pax.logging.properties could be:

  log4j.rootLogger=DEBUG, CONSOLE log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.layout=org.apache.log4j.TTCCLayout

To use this two bundles you can start your preferred OSGi framework, provisioning Pax Coin bundles, Pax Coin Bundle Content Configuration Provider and your bundles that perform logging. Also install but do not start the two bundles from above (that this feel hard? Then you missed Pax Runner).
Once everything is up and running, start log.config.info bundle and do something that triggers logging. You should see now only INFO messages. Then stop this bundle and start log.config.debug and do again that something that triggered logging. You should see now also DEBUG messages.

Can you see how useful it can be in an production environment? You can go by default with a bundle containing logging configuration for ERROR and as soon as there is a problem and you want to trace it start another bundle that contains a logging configuration for DEBUG. You are done? Start the ERROR one again.