camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <>
Subject Re: Potential Bug in CamelBlueprintTestSupport
Date Wed, 06 Jan 2016 22:30:03 GMT
I just re-ran the test against several versions of Camel and I’ve updated the POM in the
unit test with the results.

To summarize:
- When the blueprint.xml is in src/test/resources/OSGI-INF/blueprint -
    these versions work
      - 2.17-SNAPSHOT
      - 2.16.1
      - 2.16.0
      - 2.15.5
      - 2.15.4
    and these versions fail
      - 2.15.3
      - 2.15.2
      - 2.15.1
      - 2.15.0
      - 2.14.4
      - 2.14.3
      - 2.14.2
      - 2.14.1
      - 2.14.0
- When the blueprint.xml is in src/main/resources/OSGI-INF/blueprint -
  these versions were tested and all failed
      - 2.17-SNAPSHOT
      - 2.16.1
      - 2.16.0
      - 2.15.5
      - 2.15.4

Here is the blueprint I’m using

<blueprint xmlns=""

    <!-- blueprint property placeholders, that will use etc/stuff.cfg as the properties
file -->
    <cm:property-placeholder persistent-id="stuff" update-strategy="reload">
            <cm:property name="greeting" value="Hello" />
            <cm:property name="echo" value="Hey" />
            <cm:property name="destination" value="mock:original" />

    <!-- a bean that uses a blueprint property placeholder -->
    <bean id="myCoolBean" class="org.apache.camel.beans.MyCoolBean">
        <property name="say" value="${greeting}"/>
        <property name="echo" value="${echo}"/>

    <camelContext xmlns="">

            <from uri="direct:start"/>
            <bean ref="myCoolBean" method="saySomething"/>
            <to uri="{{destination}}"/>
            <bean ref="myCoolBean" method="echoSomething"/>
            <to uri="{{destination}}"/>



And here is the JUnit test

public class ConfigAdminLoadConfigurationFileAndOverrideTest extends CamelBlueprintTestSupport

    protected String getBlueprintDescriptor() {
        // which blueprint XML file to use for this test
   // If this file is in src/main/resources/OSGI-INF/blueprint, the test will fail most of
the time
   // If this file is in src/test/resources/OSGI-INF/blueprint, the test passes
        return "/OSGI-INF/blueprint/configadmin-loadfileoverride.xml";

    protected String[] loadConfigAdminConfigurationFile() {
        // which .cfg file to use, and the name of the persistence-id
        return new String[]{"src/test/resources/etc/stuff.cfg", "stuff"};

    protected String useOverridePropertiesWithConfigAdmin(Dictionary props) throws Exception
        // override / add extra properties
        props.put("destination", "mock:extra");

        // return the persistence-id to use
        return "stuff";

    public void testConfigAdmin() throws Exception {
        // mock:original comes from <cm:default-properties>/<cm:property name="destination"
value="mock:original" />
        // mock:result comes from loadConfigAdminConfigurationFile()
        // mock:extra comes from useOverridePropertiesWithConfigAdmin()
        getMockEndpoint("mock:extra").expectedBodiesReceived("Bye World", "Yay Bye WorldYay
Bye World");

        template.sendBody("direct:start", "World");



Quinn Stevenson
(801) 244-7758

> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <> wrote:
> Hi Grzegorz -
> Thank you for the link - I’ve read through it many times - it is very very helpful.
 From what I understand, this should work - the location of the blueprint file shouldn’t
effect the way the test runs, should it?  Maybe I’m missing something simple.
> It looks like my unit test attachment didn’t come through. Sorry - I didn’t think
about the mailing list filtering out attachments.  You can get to the test here
> I've been testing this primary against 2.17-SNAPSHOT, but I’ve tested against several
versions.  The POM for the unit test has the versions listed that I tested, but I was messing
with the test a little so I’m not sure the list is completely accurate.  I’ll verify those
and update the POM if needed.
> Quinn Stevenson
>> On Jan 6, 2016, at 12:21 PM, Grzegorz Grzybek < <>>
>> Hello Quinn
>> What Camel version do you use? I wrote a thorough explanation of
>> CamelTestBlueprint and the changes we've made to how tests are
>> performed and synchronized.
>> Here: <>
>> You can find there links to JIRA issues describing exactly the same
>> problems you have with `update-strategy="reload"`.
>> best regards
>> Grzegorz Grzybek
>> 2016-01-06 19:16 GMT+01:00 Quinn Stevenson < <>>:
>>> I’ve encountered an issue, but I’m not sure if this is a bug or a user error.
>>> I’m trying to write some tests using CamelBlueprintTestSupport for bundles
where the blueprint file is in src/main/resources/OSGI-INF/blueprint.  However, I’m getting
random failures in the test on startup.
>>> I’ve narrowed it down to using update-strategy = “reload” and overriding
properties in the test.  The tests fail (most of the time) when the actual blueprint file
is in src/main/resources/OSGI-INF/blueprint.  Even when the test doesn’t fail, you’ll
see multiple camel contexts get created during the test, while the test this is based on from
camel-test-blueprint only creates two camel contexts.
>>> However, if I move the blueprint file to src/test/resources/OSGI-INF/blueprint,
the test passes.
>>> Since I need the blueprint packaged in the bundle in OSGI-INF/blueprint, I can’t
move the blueprint file to the src/test/… area.
>>> Is there another way I should be testing this sort of thing?
>>> I’ve created a unit test based on the ConfigAdminLoadConfigurationFileAndOverrideTest
from the camel-test-blueprint module that demonstrates the issue.
>>> Quinn Stevenson

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message