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.grzy...@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 >> qu...@pronoia-solutions.com >> (801) 244-7758 >> >> >> >>> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <gr.grzy...@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.grzy...@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 >>>>>> qu...@pronoia-solutions.com <mailto:qu...@pronoia-solutions.com> >>>>>> (801) 244-7758 >>>>>> >>>>>> >>>>>> >>>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson >>>>>>> <qu...@pronoia-solutions.com <mailto: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.grzy...@gmail.com >>>>>>>> <mailto:gr.grzy...@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 >>>>>>>> <qu...@pronoia-solutions.com <mailto: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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>