You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Quinn Stevenson <qu...@pronoia-solutions.com> on 2016/01/06 19:16:33 UTC
Potential Bug in CamelBlueprintTestSupport
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.
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thank You Grzegorz!!
I created the sample project using the camel-archetype-blueprint, and it introduced that configuration. I’ve verified that the configuration for the maven-bundle-plugin changed between v 2.14 and 2.15.0.
I created https://issues.apache.org/jira/browse/CAMEL-9519 <https://issues.apache.org/jira/browse/CAMEL-9519> to fix the archetype, and I’m working on a PR for it now. I’m going to include Blueprint property placeholders in the archetype and test so the fix can be verified.
Fixing the archetype is sufficient for me, but should I be creating another JIRA for the behavior when the maven-bundle-plugin is configured in the manner below?
Quinn Stevenson
> On Jan 15, 2016, at 11:07 AM, Grzegorz Grzybek <gr...@gmail.com> wrote:
>
> The problem is that your example lead to two bundles in felix-connect
> OSGi registy:
> 2016-01-15 18:32:54,172 DEBUG CamelBlueprintHelper - Bundle #0 ->
> jar:file:/data/ggrzybek/sources/github.com/_other/camel-blueprint-test-properties/target/test-bundles/configadminloadconfigurationfileandoverridetest-1452879174127.jar!/
> 2016-01-15 18:32:54,172 DEBUG CamelBlueprintHelper - Bundle #1 ->
> file:/data/ggrzybek/sources/github.com/_other/camel-blueprint-test-properties/target/classes/
>
> both entries had blueprint XML inside.
> you should not use:
> <executions>
> <execution>
> <id>bundle-manifest</id>
> <phase>process-classes</phase>
> <goals>
> <goal>manifest</goal>
> </goals>
> </execution>
> </executions>
>
> this goal generates target/classes/META-INF/MANIFEST.MF and it
> (target/classes directory) is scanned by felix-connect as
> fully-fledged bundle. looks like it confuses the test.
>
> and because you've generated using camel archetype, looks like we have
> to change the archetype...
>
> regards
> Grzegorz
>
> 2016-01-15 17:17 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
>> Weird ;)
>> I'll check it - sounds interesting!
>>
>> regards
>> Grzegorz
>>
>> 2016-01-15 17:16 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>>> Hi Grzegorz -
>>>
>>> Sorry I missed you on the IRC - I left my client open last night.
>>>
>>> I put the project I’m using on GitHub https://github.com/hqstevenson/camel-blueprint-test-properties.git <https://github.com/hqstevenson/camel-blueprint-test-properties.git>
>>>
>>> The results for me are indeterminate - I have had the simple test pass almost as much as it fails, but I still get somewhat random failures. The one thing that is very consistent is the number of times the camel context is created. When the blueprint file is in src/test/resources/… it gets created twice, but when the blueprint file is in src/main/resources/…. I’ve seen the camel context created up to 30 times - the exact number varies, but it’s always more than 2.
>>>
>>> Here’s a snipped from the log the last time I ran this and the test passed.
>>>
>>> [ main] BlueprintCamelContext INFO Apache Camel 2.17-SNAPSHOT (CamelContext: camel-27) is shutdown in 0.001 seconds
>>> [ main] BlueprintExtender INFO Destroying BlueprintContainer for bundle ConfigAdminLoadConfigurationFileAndOverrideTest/1.0.0
>>>
>>> Quinn Stevenson
>>> quinn@pronoia-solutions.com
>>> (801) 244-7758
>>>
>>>
>>>
>>>> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <gr...@gmail.com> wrote:
>>>>
>>>> Hello Quinn
>>>>
>>>> Hmm... I've run `for n in `seq 1 30`; do echo $n; mvn test
>>>> -Dtest=ConfigAdminLoadConfigurationFileAndOverrideTest|grep BUILD;
>>>> done` after moving `configadmin-loadfileoverride.xml` from
>>>> src/test/resources to src/main/resources and everything is fine.
>>>>
>>>> Are you doing it in your own project? Maybe you've set maven filtering
>>>> on src/main/resources?
>>>>
>>>> regards
>>>> Grzegorz
>>>>
>>>> 2016-01-14 16:48 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
>>>>> Hello Quinn
>>>>>
>>>>> Excuse me that I've missed your emails - your findings are interesting
>>>>> - I'll try to test your scenarios tomorrow (Friday) morning CET. ok?
>>>>>
>>>>> regards
>>>>> Grzegorz
>>>>>
>>>>> 2016-01-14 16:42 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>>>>>> Hi Grzegorz -
>>>>>>
>>>>>> So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
>>>>>>
>>>>>> Quinn Stevenson
>>>>>>
>>>>>>
>>>>>>> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>>>>>>
>>>>>>> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
>>>>>>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
>>>>>>> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
>>>>>>> (801) 244-7758
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Grzegorz Grzybek <gr...@gmail.com>.
The problem is that your example lead to two bundles in felix-connect
OSGi registy:
2016-01-15 18:32:54,172 DEBUG CamelBlueprintHelper - Bundle #0 ->
jar:file:/data/ggrzybek/sources/github.com/_other/camel-blueprint-test-properties/target/test-bundles/configadminloadconfigurationfileandoverridetest-1452879174127.jar!/
2016-01-15 18:32:54,172 DEBUG CamelBlueprintHelper - Bundle #1 ->
file:/data/ggrzybek/sources/github.com/_other/camel-blueprint-test-properties/target/classes/
both entries had blueprint XML inside.
you should not use:
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
this goal generates target/classes/META-INF/MANIFEST.MF and it
(target/classes directory) is scanned by felix-connect as
fully-fledged bundle. looks like it confuses the test.
and because you've generated using camel archetype, looks like we have
to change the archetype...
regards
Grzegorz
2016-01-15 17:17 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
> Weird ;)
> I'll check it - sounds interesting!
>
> regards
> Grzegorz
>
> 2016-01-15 17:16 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>> Hi Grzegorz -
>>
>> Sorry I missed you on the IRC - I left my client open last night.
>>
>> I put the project I’m using on GitHub https://github.com/hqstevenson/camel-blueprint-test-properties.git <https://github.com/hqstevenson/camel-blueprint-test-properties.git>
>>
>> The results for me are indeterminate - I have had the simple test pass almost as much as it fails, but I still get somewhat random failures. The one thing that is very consistent is the number of times the camel context is created. When the blueprint file is in src/test/resources/… it gets created twice, but when the blueprint file is in src/main/resources/…. I’ve seen the camel context created up to 30 times - the exact number varies, but it’s always more than 2.
>>
>> Here’s a snipped from the log the last time I ran this and the test passed.
>>
>> [ main] BlueprintCamelContext INFO Apache Camel 2.17-SNAPSHOT (CamelContext: camel-27) is shutdown in 0.001 seconds
>> [ main] BlueprintExtender INFO Destroying BlueprintContainer for bundle ConfigAdminLoadConfigurationFileAndOverrideTest/1.0.0
>>
>> Quinn Stevenson
>> quinn@pronoia-solutions.com
>> (801) 244-7758
>>
>>
>>
>>> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <gr...@gmail.com> wrote:
>>>
>>> Hello Quinn
>>>
>>> Hmm... I've run `for n in `seq 1 30`; do echo $n; mvn test
>>> -Dtest=ConfigAdminLoadConfigurationFileAndOverrideTest|grep BUILD;
>>> done` after moving `configadmin-loadfileoverride.xml` from
>>> src/test/resources to src/main/resources and everything is fine.
>>>
>>> Are you doing it in your own project? Maybe you've set maven filtering
>>> on src/main/resources?
>>>
>>> regards
>>> Grzegorz
>>>
>>> 2016-01-14 16:48 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
>>>> Hello Quinn
>>>>
>>>> Excuse me that I've missed your emails - your findings are interesting
>>>> - I'll try to test your scenarios tomorrow (Friday) morning CET. ok?
>>>>
>>>> regards
>>>> Grzegorz
>>>>
>>>> 2016-01-14 16:42 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>>>>> Hi Grzegorz -
>>>>>
>>>>> So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
>>>>>
>>>>> Quinn Stevenson
>>>>>
>>>>>
>>>>>> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>>>>>
>>>>>> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
>>>>>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
>>>>>> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
>>>>>> (801) 244-7758
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Weird ;)
I'll check it - sounds interesting!
regards
Grzegorz
2016-01-15 17:16 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
> Hi Grzegorz -
>
> Sorry I missed you on the IRC - I left my client open last night.
>
> I put the project I’m using on GitHub https://github.com/hqstevenson/camel-blueprint-test-properties.git <https://github.com/hqstevenson/camel-blueprint-test-properties.git>
>
> The results for me are indeterminate - I have had the simple test pass almost as much as it fails, but I still get somewhat random failures. The one thing that is very consistent is the number of times the camel context is created. When the blueprint file is in src/test/resources/… it gets created twice, but when the blueprint file is in src/main/resources/…. I’ve seen the camel context created up to 30 times - the exact number varies, but it’s always more than 2.
>
> Here’s a snipped from the log the last time I ran this and the test passed.
>
> [ main] BlueprintCamelContext INFO Apache Camel 2.17-SNAPSHOT (CamelContext: camel-27) is shutdown in 0.001 seconds
> [ main] BlueprintExtender INFO Destroying BlueprintContainer for bundle ConfigAdminLoadConfigurationFileAndOverrideTest/1.0.0
>
> Quinn Stevenson
> quinn@pronoia-solutions.com
> (801) 244-7758
>
>
>
>> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <gr...@gmail.com> wrote:
>>
>> Hello Quinn
>>
>> Hmm... I've run `for n in `seq 1 30`; do echo $n; mvn test
>> -Dtest=ConfigAdminLoadConfigurationFileAndOverrideTest|grep BUILD;
>> done` after moving `configadmin-loadfileoverride.xml` from
>> src/test/resources to src/main/resources and everything is fine.
>>
>> Are you doing it in your own project? Maybe you've set maven filtering
>> on src/main/resources?
>>
>> regards
>> Grzegorz
>>
>> 2016-01-14 16:48 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
>>> Hello Quinn
>>>
>>> Excuse me that I've missed your emails - your findings are interesting
>>> - I'll try to test your scenarios tomorrow (Friday) morning CET. ok?
>>>
>>> regards
>>> Grzegorz
>>>
>>> 2016-01-14 16:42 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>>>> Hi Grzegorz -
>>>>
>>>> So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
>>>>
>>>> Quinn Stevenson
>>>>
>>>>
>>>>> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>>>>
>>>>> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
>>>>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
>>>>> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
>>>>> (801) 244-7758
>>>>>
>>>>>
>>>>>
>>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Hi Grzegorz -
Sorry I missed you on the IRC - I left my client open last night.
I put the project I’m using on GitHub https://github.com/hqstevenson/camel-blueprint-test-properties.git <https://github.com/hqstevenson/camel-blueprint-test-properties.git>
The results for me are indeterminate - I have had the simple test pass almost as much as it fails, but I still get somewhat random failures. The one thing that is very consistent is the number of times the camel context is created. When the blueprint file is in src/test/resources/… it gets created twice, but when the blueprint file is in src/main/resources/…. I’ve seen the camel context created up to 30 times - the exact number varies, but it’s always more than 2.
Here’s a snipped from the log the last time I ran this and the test passed.
[ main] BlueprintCamelContext INFO Apache Camel 2.17-SNAPSHOT (CamelContext: camel-27) is shutdown in 0.001 seconds
[ main] BlueprintExtender INFO Destroying BlueprintContainer for bundle ConfigAdminLoadConfigurationFileAndOverrideTest/1.0.0
Quinn Stevenson
quinn@pronoia-solutions.com
(801) 244-7758
> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <gr...@gmail.com> wrote:
>
> Hello Quinn
>
> Hmm... I've run `for n in `seq 1 30`; do echo $n; mvn test
> -Dtest=ConfigAdminLoadConfigurationFileAndOverrideTest|grep BUILD;
> done` after moving `configadmin-loadfileoverride.xml` from
> src/test/resources to src/main/resources and everything is fine.
>
> Are you doing it in your own project? Maybe you've set maven filtering
> on src/main/resources?
>
> regards
> Grzegorz
>
> 2016-01-14 16:48 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
>> Hello Quinn
>>
>> Excuse me that I've missed your emails - your findings are interesting
>> - I'll try to test your scenarios tomorrow (Friday) morning CET. ok?
>>
>> regards
>> Grzegorz
>>
>> 2016-01-14 16:42 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>>> Hi Grzegorz -
>>>
>>> So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
>>>
>>> Quinn Stevenson
>>>
>>>
>>>> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>>>
>>>> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
>>>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
>>>> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
>>>> (801) 244-7758
>>>>
>>>>
>>>>
>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello Quinn
Hmm... I've run `for n in `seq 1 30`; do echo $n; mvn test
-Dtest=ConfigAdminLoadConfigurationFileAndOverrideTest|grep BUILD;
done` after moving `configadmin-loadfileoverride.xml` from
src/test/resources to src/main/resources and everything is fine.
Are you doing it in your own project? Maybe you've set maven filtering
on src/main/resources?
regards
Grzegorz
2016-01-14 16:48 GMT+01:00 Grzegorz Grzybek <gr...@gmail.com>:
> Hello Quinn
>
> Excuse me that I've missed your emails - your findings are interesting
> - I'll try to test your scenarios tomorrow (Friday) morning CET. ok?
>
> regards
> Grzegorz
>
> 2016-01-14 16:42 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
>> Hi Grzegorz -
>>
>> So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
>>
>> Quinn Stevenson
>>
>>
>>> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>>
>>> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
>>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
>>> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
>>> (801) 244-7758
>>>
>>>
>>>
>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello Quinn
Excuse me that I've missed your emails - your findings are interesting
- I'll try to test your scenarios tomorrow (Friday) morning CET. ok?
regards
Grzegorz
2016-01-14 16:42 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
> Hi Grzegorz -
>
> So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
>
> Quinn Stevenson
>
>
>> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>
>> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
>> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
>> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
>> (801) 244-7758
>>
>>
>>
>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Hi Grzegorz -
So is this a bug? It seems like it is to me, but I don’t want to waste anybody’s time with the JIRA if it isn’t and I’m just doing something stupid.
Quinn Stevenson
> On Jan 6, 2016, at 3:30 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> 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 <http://www.osgi.org/xmlns/blueprint/v1.0.0>"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance <http://www.w3.org/2001/XMLSchema-instance>"
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 <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/blueprint/xmlns/blueprint-cm/v1.1.0> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd <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> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd <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 <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
> quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>
> (801) 244-7758
>
>
>
>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>
>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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
quinn@pronoia-solutions.com
(801) 244-7758
> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <qu...@pronoia-solutions.com> 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 <gr.grzybek@gmail.com <ma...@gmail.com>> 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 <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>>:
>>> 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
>>>
>>>
>>>
>>>
>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <gr...@gmail.com> 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
> 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 <qu...@pronoia-solutions.com>:
>> 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
>>
>>
>>
>>
Re: Potential Bug in CamelBlueprintTestSupport
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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
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 <qu...@pronoia-solutions.com>:
> 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
>
>
>
>