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="http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0";
xsi:schemaLocation="
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0
http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
<!-- blueprint property placeholders, that will use etc/stuff.cfg as the
properties file -->
<cm:property-placeholder persistent-id="stuff" update-strategy="reload">
<cm:default-properties>
<cm:property name="greeting" value="Hello" />
<cm:property name="echo" value="Hey" />
<cm:property name="destination" value="mock:original" />
</cm:default-properties>
</cm:property-placeholder>
<!-- 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}"/>
</bean>
<camelContext xmlns="http://camel.apache.org/schema/blueprint";>
<route>
<from uri="direct:start"/>
<bean ref="myCoolBean" method="saySomething"/>
<to uri="{{destination}}"/>
<bean ref="myCoolBean" method="echoSomething"/>
<to uri="{{destination}}"/>
</route>
</camelContext>
</blueprint>
And here is the JUnit test
public class ConfigAdminLoadConfigurationFileAndOverrideTest extends
CamelBlueprintTestSupport {
@Override
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";
}
@Override
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"};
}
@Override
protected String useOverridePropertiesWithConfigAdmin(Dictionary props)
throws Exception {
// override / add extra properties
props.put("destination", "mock:extra");
// return the persistence-id to use
return "stuff";
}
@Test
public void testConfigAdmin() throws Exception {
// mock:original comes from <cm:default-properties>/<cm:property
name="destination" value="mock:original" />
getMockEndpoint("mock:original").setExpectedMessageCount(0);
// mock:result comes from loadConfigAdminConfigurationFile()
getMockEndpoint("mock:result").setExpectedMessageCount(0);
// mock:extra comes from useOverridePropertiesWithConfigAdmin()
getMockEndpoint("mock:extra").expectedBodiesReceived("Bye World", "Yay
Bye WorldYay Bye World");
template.sendBody("direct:start", "World");
assertMockEndpointsSatisfied();
}
}
Quinn Stevenson
[email protected]
(801) 244-7758
> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <[email protected]>
> 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 https://github.com/hqstevenson/camel-blueprint-test-properties.git
> <https://github.com/hqstevenson/camel-blueprint-test-properties.git>
>
> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> 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: http://ggrzybek.blogspot.com/2015/12/camel-blueprint-test-support.html
>> <http://ggrzybek.blogspot.com/2015/12/camel-blueprint-test-support.html>
>> 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 <[email protected]
>> <mailto:[email protected]>>:
>>> 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
>>>
>>>
>>>
>>>
>
