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 <[email protected]>:
> Weird ;)
> I'll check it - sounds interesting!
>
> regards
> Grzegorz
>
> 2016-01-15 17:16 GMT+01:00 Quinn Stevenson <[email protected]>:
>> 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
>> [email protected]
>> (801) 244-7758
>>
>>
>>
>>> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <[email protected]> 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 <[email protected]>:
>>>> 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 <[email protected]>:
>>>>> 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
>>>>>> <[email protected]> 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
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> (801) 244-7758
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson
>>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>>> 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 <[email protected]
>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>> <[email protected] <mailto:[email protected]>>:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
