camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: Potential Bug in CamelBlueprintTestSupport
Date Fri, 15 Jan 2016 16:17:45 GMT
Weird ;)
I'll check it - sounds interesting!

regards
Grzegorz

2016-01-15 17:16 GMT+01:00 Quinn Stevenson <quinn@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
> quinn@pronoia-solutions.com
> (801) 244-7758
>
>
>
>> On Jan 15, 2016, at 3:23 AM, Grzegorz Grzybek <gr.grzybek@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.grzybek@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 <quinn@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 <quinn@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
>>>>> quinn@pronoia-solutions.com <mailto:quinn@pronoia-solutions.com>
>>>>> (801) 244-7758
>>>>>
>>>>>
>>>>>
>>>>>> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com
<mailto:quinn@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.grzybek@gmail.com
<mailto:gr.grzybek@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 <quinn@pronoia-solutions.com
<mailto:quinn@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>

Mime
View raw message