Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
ConfigurationAdmin, PropertyPlaceholder, Chicken and Egg Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • ConfigurationAdmin, PropertyPlaceholder, Chicken and Egg

    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?

  • #2
    Originally posted by dlaidlaw View Post
    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.

    Comment


    • #3
      Another CM integration problem

      Originally posted by andypiper View Post
      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:
      Code:
         <!-- 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.

      Comment


      • #4
        Originally posted by dlaidlaw View Post
        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:
        Code:
           <!-- 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?

        Comment


        • #5
          Originally posted by andypiper View Post
          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.

          Comment


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

            Comment


            • #7
              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.

              Comment


              • #8
                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.

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

                Comment


                • #9
                  Originally posted by StimpyCat View Post
                  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.

                  Code:
                      <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.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Next Release ?

                      Originally posted by Costin Leau View Post
                      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.
                      When can we expect the next release/milestone with this issue fixed?

                      Regards
                      Felix

                      Comment


                      • #12
                        We're currently tracking the discussion about the CM support in the EEG group. Once an agreement on the overall schema and functionality will be reached, we'll release the current implementation to the public.
                        The alternative is to keep releasing milestones with significant differences between them which I think would create confusion rather then solving anything since one can always download and build the sources (or use the nightly build).

                        As for an ETA, it's really a rough one but I would like to see another release in 3-4 weeks from now.

                        Comment

                        Working...
                        X