camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <qu...@pronoia-solutions.com>
Subject Re: Potential Bug in CamelBlueprintTestSupport
Date Wed, 06 Jan 2016 22:30:03 GMT
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"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:cm="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/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/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">

        <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
(801) 244-7758



> On Jan 6, 2016, at 2:35 PM, Quinn Stevenson <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message