ConfigurationAdmin, PropertyPlaceholder, Chicken and Egg

[dlaidlaw]

There is a little gap in the osgix:cm-properties support in spring-powered bundles, and the ability to get configuration injected into ConfigurationAdmin. This is particularly true for integration testing.

It is highly desirable for integration tests to be able to inject test-specific configuration into ConfigurationAdmin, and allow the code being tested to consume that configuration. It is trivial to write a bundle to read test configuration property files from a system path or the bundle being tested and inject them into ConfigurationAdmin PIDs. But delaying the test bundle startup so that the configuration is injected before it is consumed is extremely hard.

The problem here seems to be in the startup of a spring-powered bundle. The property placeholder attached to the osgix:cm-properties is resolved before the bundle pauses to satisfy its service dependencies. Service dependencies are the only dependency pause point provided by DM, and so if you want to try to make sure everything is available before the spring context is refreshed, you need to use service dependencies. There is no way to tell the bundle not to even begin context creation until a set of conditions are satisfied. Therefore you can't prevent the PropertyPlaceholder from reading from ConfigurationAdmin when the spring context is created, but before the context is refreshed.

Having such a feature would certainly help in defining a complete platform against which a bundle under test could be tested against. Of course, the same problem can happen in full deployment if you require an initial startup to first load configuration data into ConfigurationAdmin.

Or is there another way that has escaped me?

[andypiper]

There is a little gap in the osgix:cm-properties support in spring-powered bundles, and the ability to get configuration injected into ConfigurationAdmin. This is particularly true for integration testing.

It is highly desirable for integration tests to be able to inject test-specific configuration into ConfigurationAdmin, and allow the code being tested to consume that configuration. It is trivial to write a bundle to read test configuration property files from a system path or the bundle being tested and inject them into ConfigurationAdmin PIDs. But delaying the test bundle startup so that the configuration is injected before it is consumed is extremely hard.

The problem here seems to be in the startup of a spring-powered bundle. The property placeholder attached to the osgix:cm-properties is resolved before the bundle pauses to satisfy its service dependencies. Service dependencies are the only dependency pause point provided by DM, and so if you want to try to make sure everything is available before the spring context is refreshed, you need to use service dependencies. There is no way to tell the bundle not to even begin context creation until a set of conditions are satisfied. Therefore you can't prevent the PropertyPlaceholder from reading from ConfigurationAdmin when the spring context is created, but before the context is refreshed.

Having such a feature would certainly help in defining a complete platform against which a bundle under test could be tested against. Of course, the same problem can happen in full deployment if you require an initial startup to first load configuration data into ConfigurationAdmin.

Or is there another way that has escaped me?

Don, you are right it is a thorny problem. I introduced DependencyInitializationAwareBeanPostProcessor and DependencyAwareBeanFactoryPostProcessor to address the general problem of how do you invoke BPP's and BFPP's later in the cycle only after dependencies have been satisfied. I think perhaps the latter could be used to modify the PropertyPlaceholder to give the behaviour you are after but I have not tried it and it would obviously require some changes to Spring DM to be fully integrated.

[dlaidlaw]

Don, you are right it is a thorny problem. I introduced DependencyInitializationAwareBeanPostProcessor and DependencyAwareBeanFactoryPostProcessor to address the general problem of how do you invoke BPP's and BFPP's later in the cycle only after dependencies have been satisfied. I think perhaps the latter could be used to modify the PropertyPlaceholder to give the behaviour you are after but I have not tried it and it would obviously require some changes to Spring DM to be fully integrated.

That is true. I may have to provide an implementation of DependencyAwareBeanFactoryPostProcessor that gets the configuration from CM, then post processes the bean factory with those properties at that time. I will look into that.

But there is a related problem that has come up. In the Spring-DM doc for version 1.2.0 it is recommended to use configuration admin like:

   <!-- Configuration Admin entry -->
   <osgix:cm-properties id="cmProps" persistent-id="com.xyz.myapp">
      <prop key="host">localhost</prop>
   </osgix:cm-properties>

   <!-- placeholder configurer -->
   <ctx:property-placeholder properties-ref="cmProps" />

The problem with this is one of timing as well. The property placeholder is actually evaluated in the first stage of application context refresh by OsgiBundleXmlApplicationContext(AbstractDelegatedE xecutionApplicationContext).startRefresh() line: 247

That stage is executed before waiting for dependencies. So even if there is a dependency on CM, the PropertyPlaceholderConfigurer has already post processed the bean factory without getting the CM properties first unless CM just happened to already be available. If CM was not available you usually get error messages like "could not resolve placeholder x".

So the current state of things means there is no way to be sure your context will read its properties from CM, because property placeholder substitution happens in stage one (preRefresh) of the context, before dependency waiting happens. I think what is required here is a DependencyAwareBeanFactoryPostProcessor version of the property placeholder configurer so that properties will be applied to the bean factory in stage two, after dependency waiting. Plus, if that bean is used it should automatically generate a wait on the org.osgi.service.cm.ConfigurationAdmin service.

[andypiper]

That is true. I may have to provide an implementation of DependencyAwareBeanFactoryPostProcessor that gets the configuration from CM, then post processes the bean factory with those properties at that time. I will look into that.

But there is a related problem that has come up. In the Spring-DM doc for version 1.2.0 it is recommended to use configuration admin like:

   <!-- Configuration Admin entry -->
   <osgix:cm-properties id="cmProps" persistent-id="com.xyz.myapp">
      <prop key="host">localhost</prop>
   </osgix:cm-properties>

   <!-- placeholder configurer -->
   <ctx:property-placeholder properties-ref="cmProps" />

The problem with this is one of timing as well. The property placeholder is actually evaluated in the first stage of application context refresh by OsgiBundleXmlApplicationContext(AbstractDelegatedE xecutionApplicationContext).startRefresh() line: 247

That stage is executed before waiting for dependencies. So even if there is a dependency on CM, the PropertyPlaceholderConfigurer has already post processed the bean factory without getting the CM properties first unless CM just happened to already be available. If CM was not available you usually get error messages like "could not resolve placeholder x".

So the current state of things means there is no way to be sure your context will read its properties from CM, because property placeholder substitution happens in stage one (preRefresh) of the context, before dependency waiting happens. I think what is required here is a DependencyAwareBeanFactoryPostProcessor version of the property placeholder configurer so that properties will be applied to the bean factory in stage two, after dependency waiting. Plus, if that bean is used it should automatically generate a wait on the org.osgi.service.cm.ConfigurationAdmin service.

I agree 100%. I have not used Spring DM's CM support, but we have a custom PropertyPlaceholderConfigurer implementation that does exactly this for exactly the reasons you suggest.

Would you be able to raise a JIRA issue for this?

[dlaidlaw]

I agree 100%. I have not used Spring DM's CM support, but we have a custom PropertyPlaceholderConfigurer implementation that does exactly this for exactly the reasons you suggest.

Would you be able to raise a JIRA issue for this?

Done. Issue OSGI-780 created.

By "custom PropertyPlaceholderConfigurer implementation" do you mean you already have this class somewhere that can be used? I have also created a custom wrapper class for PropertyPlaceholderConfigurer that implements DependencyAwareBeanFactoryPostProcessor and verified that this actually does work as expected. It is pretty simple to do.

[dlaidlaw]

I have documented this problem and a solution that works for me in my blog.

[Costin Leau]

Thanks for the suggestion Don. I've added in trunk an option to the cm-properties element so it can wait until an entry is present.

[StimpyCat]

I have a similar problem that I'd like to throw into the mix as it centers around this problem.

I have a bundle which is deployed onto a number of different servers each with their own properties file configuration. To load this properties file in we'd like to use a -D property on start up (SpringDM Server) which is then plugged into the compendium entry. The problem here is that the value is never put in and the properties file is never associated with the bundle.

    <context:property-placeholder properties-ref="latticeWorkerProperties"/>
    <osgi-compendium:cm-properties id="latticeWorkerProperties" persistent-id="${worker.properties.file}"/>

[andypiper]

I have a similar problem that I'd like to throw into the mix as it centers around this problem.

I have a bundle which is deployed onto a number of different servers each with their own properties file configuration. To load this properties file in we'd like to use a -D property on start up (SpringDM Server) which is then plugged into the compendium entry. The problem here is that the value is never put in and the properties file is never associated with the bundle.

    <context:property-placeholder properties-ref="latticeWorkerProperties"/>
    <osgi-compendium:cm-properties id="latticeWorkerProperties" persistent-id="${worker.properties.file}"/>

I'm not sure this is the same problem is it? The config admin support in Spring DM is generally for retrieving properties rather than setting them.

[StimpyCat]

I can see where your coming from Andy, but I saw it was a bit of the chicken and the egg part of I'm try to set a property which should be possible, but due to the start up sequence it's not being set in time. I saw it as something that should be considered while working in this section of code.

If this is possible please let me know and I can sort myself out and remove the post.


cheers.