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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>
