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