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