Thank You Grzegorz!! I created the sample project using the camel-archetype-blueprint, and it introduced that configuration. I’ve verified that the configuration for the maven-bundle-plugin changed between v 2.14 and 2.15.0.
I created https://issues.apache.org/jira/browse/CAMEL-9519 <https://issues.apache.org/jira/browse/CAMEL-9519> to fix the archetype, and I’m working on a PR for it now. I’m going to include Blueprint property placeholders in the archetype and test so the fix can be verified. Fixing the archetype is sufficient for me, but should I be creating another JIRA for the behavior when the maven-bundle-plugin is configured in the manner below? Quinn Stevenson > On Jan 15, 2016, at 11:07 AM, Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: > > 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>
