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