3 Replies Latest reply on Jul 28, 2011 11:19 AM by Bob Blackard

    Help: Aries Blueprint handling of property-placeholder and substitution

    Bob Blackard Newbie

      Hi all,


      I'm having trouble with configuration properties in Aries Blueprint. 


      I've converted a small test application from Spring to Blueprint, and have successfully gotten OSGi service bindings, Camel routes and even CXF JAX-RS working - the last required moving to ServiceMix-4.4.0-FUSE-00-43 since CXF didn't have Blueprint support until version 2.4.  This, of course, involved moving my bundle context files out of , changing the namespaces, and making a few other adjustments.


      All in all, that went pretty well.  However, being a glutton for punishment I decided to add some configuration properties - I'm actually doing a proof of concept in preparation for work on the next release of a product I'm helping out with, and in addition to OSGi service bindings, Camel routes, and CXF producing JAX-RS RESTful interfaces, the current product uses configuration stuff.


      The test application is pretty simple.  There's a Common bundle that includes the model, common exceptions and service interface definitions, with the model being generated from an XSD using the XJC plugin.  There's a Producer bundle that exposes three REST calls (ProducerRest.java) and has three methods (ProducerImpl.java), as well as an OSGi service and a Camel endpoint allowing the three methods to be accessed by REST, OSGi or Camel.  Finally, there's a Consumer bundle that consumes the Produce bundle's OSGi and Camel endpoints.  All this stuff works perfectly well.  The only this that isn't behaving is configuration.


      Basically, none of the value="${...}" substitutions are happening.  After some experimentation, I finally decided to create a separate bundle with just a Camel route running off a timer to ping an interface that logs a string set by configuration property injection.  I created the bundle by copying the Producer bundle, changing package and class names, removing the CXF/JAX-RS and OSGi service stuff.


      I almost lost it when, after building this stand alone bundle, I deployed it and the configuration property substitutions worked.


      When I deploy the stand alone version, I see the following log entries:


      Retrieving property value msg.spit from configuration with pid org.none.proj.configPropTest

      Property not found in configuration

      Retrieving property msg.spit

      Retrieved property msg.spit value from defaults Mamma tol' me not to.

      Retrieving property value msg.sneeze from configuration with pid org.none.proj.configPropTest

      Found property value A'choo!



      Similar log entries do not appear associated with when I deploy Producer.


      Both bundles have a file bundle-context.xml in the /OSGI-INF/blueprint directory that looks like this:






      What is it that triggers processing of the property-placeholder goodies in a bundle, and what would cause one bundle to work and another to not work?


      Edited by: blackard on Jul 27, 2011 3:03 PM


      Edited by: blackard on Jul 27, 2011 3:05 PM

        • 1. Re: Help: Aries Blueprint handling of property-placeholder and substitution
          Bob Blackard Newbie

          I just realized I didn't include sample output.  Both bundles include Camel routes as follows (with names change to protect the guilty):






          Both bundles include Impl code as follows:



              /** The Logger used. */

              private static final Logger log = Logger.getLogger(ConfigPropTestImpl.class);


              /** Message content for Spit populated by dependency injection. */

              private String spit;


              /** Message content for Sneeze populated by dependency injection. */

              private String sneeze;


              public String spit() {

                   log.info("ProducerService.spit() - returning : '" + spit + "'" );

                   return spit;



              public String sneeze() {

                   log.info("ProducerService.sneeze() - returning : '" + sneeze + "'" );

                   return sneeze;



              public void setSpit(String spit) {

                    this.spit = spit;



              public void setSneeze(String sneeze) {

                    this.sneeze = sneeze;



              public void start() {

                   log.info("ProducerService.start() ..." );

                   log.info(" ... spit value : '" + spit + "'" );

                   log.info(" ... sneeze value : '" + sneeze + "'" );



              public void stop() {

                   log.info("ProducerService.stop() ..." );




          The stand alone bundle produces the following in the logs:



          ProducerService.spit() - returning : 'Mamma tol' me not to.'

          ProducerService.sneeze() - returning : 'A'choo!'



          The bundle that's behaving poorly produces the following in the logs:



          ProducerService.spit() - returning : '${msg.spit}'

          ProducerService.sneeze() - returning : '${msg.sneeze}'



          • 2. Re: Help: Aries Blueprint handling of property-placeholder and substitution
            Bob Blackard Newbie

            Another bit of information that only causes me more confusion.


            Something else I use the test application for is to check for behavior differences between various ServiceMix releases.  However, since I was specifically targeting CXF Blueprint support, I've done only limited Blueprint testing with previous versions.


            I just completed running both the ConfigPropTest (stand alone) and ProducerSansCXF (Producer without CXF JAX-RS) against three different releases of ServiceMix.  For each pass, I targeted the appropriate ServiceMix version and started with a completely clean local repository.  Since I'm using Camel Blueprint for the timers, I also made sure that the camel-blueprint feature was included in the featuresBoot setting of org.apache.karaf.features.cfg.


            The three targets were servicemix-4.4.0-fuse-00-43, servicemix-4.3.1-fuse-01-15 and servicemix-4.3.0-fuse-02-00.  ServiceMix 4.4 is included since that's where CXF 2.4 with support for Blueprint was introduced.  ServiceMix 4.3.0 was included since that's the current platform version our product is being released on.  ServiceMix 4.3.1 is included since that's where Camel 2.6 was introduced.


            Well, the results are that ConfigPropTest works (see note below) in all three ServiceMix releases.  ProducerSansCXF works only in ServiceMix 4.3.0.


            NOTE: When I say ConfigPropTest 'works' in all three releases, one thing I did notice is that there seems to be some sort of timing issue at play.  Sometimes when I deploy ConfigPropTest (ie. osgi:install -s mvn:org.none.proj/ConfigPropTest) to loads, starts and begins reporting the proper values.  Very rarely it loads, starts and begins reporting the unsubstituted ${msg...} value.  If it begins reporting the ${msg...} value, and I stop ServiceMix and restart it, the proper value is getting reported after restart, and sometimes it takes two passes at stop/restart.  I've stopped and restarted ProducerSansCXF more than 10 times in a row without the problem going away.


            NOTE: My dev/test environment is Windows 7 with Java 1.6 update 24.


            Something that I'm not sure is related, but which I also with both 4.3.1 and 4.4.0, is an issue I reported here at 6:07 pm on June 27th... which led to this defect.  Basically, ${...} substitutions in org.ops4j.pax.url.mvn.cfg aren't being done.

            • 3. Re: Help: Aries Blueprint handling of property-placeholder and substitution
              Bob Blackard Newbie

              Well, I was able to get it to work, but I think this exposes a defect in the current Aries Blueprint bundle's properties handling - or it's a defect in my understanding :-).


              I've been playing around with this, and another colleague has provided both help and guidance.


              The first thing we tried was placing the property-placeholder definition before the bean definition.  Weirdly, this worked for the Consumer project, but not the Producer project.


              Then we took the four separate files (we had bundle-context.xml, bundle-context-camel.xml, bundle-context-jaxrs.xml and bundle-context-osgi.xml all under OSGI-INF/blueprint) and combined them into a single file (bundle-context.xml).  This results in apparently perfect behavior from both Consumer and Producer.


              I'd still appreciate some feedback from anyone that can answer my original question about what triggers property-placeholder substitution in a bundle.