You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by fs <mh...@gmail.com> on 2013/09/09 08:36:15 UTC
camel blueprint - unit tests
Trying to get the following example working with blueprint but with no
success:
http://camel.apache.org/how-do-i-import-routes-from-other-xml-files.html
Test class:
public class BlueprintTest extends CamelBlueprintTestSupport {
@Override
protected String getBlueprintDescriptor() {
return "/OSGI-INF/blueprint/test-context_2.xml";
}
@Test
public void testRoute() throws Exception {
getMockEndpoint("mock:result").expectedMessageCount(1);
template.sendBody("direct:start", "test");
assertMockEndpointsSatisfied();
}
}
Blueprint configurations:
first:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<import resource="OSGI-INF/blueprint/test-context_1.xml"/>
<camelContext xmlns="http://camel.apache.org/schema/blueprint">
<routeContextRef ref="myCoolRoutes"/>
<route id="inside">
<from uri="direct:inside"/>
<to uri="mock:inside"/>
</route>
</camelContext>
</blueprint>
second:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<routeContext id="myCoolRoutes"
xmlns="http://camel.apache.org/schema/blueprint">
<route id="cool">
<from uri="direct:start"/>
<to uri="mock:result"/>
</route>
<route id="bar">
<from uri="direct:bar"/>
<to uri="mock:bar"/>
</route>
</routeContext>
</blueprint>
stacktrace:
testRoute(fi.eura2014.integration.BlueprintTest) Time elapsed: 30.806 sec
<<< ERROR!
java.lang.RuntimeException: Gave up waiting for service
(objectClass=org.apache.camel.CamelContext)
at
org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:203)
at
org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:165)
at
org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createCamelContext(CamelBlueprintTestSupport.java:116)
at
org.apache.camel.test.junit4.CamelTestSupport.doSetUp(CamelTestSupport.java:247)
at
org.apache.camel.test.junit4.CamelTestSupport.setUp(CamelTestSupport.java:217)
at
org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
--
View this message in context: http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738911.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel blueprint - unit tests
Posted by fs <mh...@gmail.com>.
Yes, this seems to be working
- removed the <import> element
- loaded both XML files via getBlueprintDescriptor()
@Override
protected String getBlueprintDescriptor() {
return
"/OSGI-INF/blueprint/test-context_2.xml,/OSGI-INF/blueprint/test-context_1.xml";
}
Thanks for the quick answers.
--
View this message in context: http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5739204.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel blueprint - unit tests
Posted by AlanFoster <al...@alanfoster.me>.
Hi there,
if you scroll up in your logging/console you may see that the route has
failed to deploy?
You also seem to be mixing Spring and Blueprint XML configuration, for
instance `import` is relevant to Spring, and not blueprint, and you can
safely delete the `<routeContextRef ref="myCoolRoutes"/>` code also.
It's also worth noting that a deployed camel app will allow you to use
blueprint routes defined within the OSGI-INF folder. However this does not
happen by default during testing. Therefore you if you want to load multiple
files within Camel's testing framework you will need to include the paths to
all of your files, using the comma delimiter.
@Override
protected String getBlueprintDescriptor() {
return "/OSGI-INF/blueprint/test-context_2.xml,"
"/OSGI-INF/blueprint/YOUR_FIRST_CONTEXT.xml";
}
Could you confirm there are not other errors in your logs?
Alan
--
View this message in context: http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738943.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel blueprint - unit tests
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
There is already itests for Karaf with pax-exam in Camel, in the
tests/camel-itest-osgi directory.
As an end user wanted to do this, this is not so easy as there is fair
amount of setup to do and whatnot.
The JIRA ticket I mentioned was to polish this and turn that into a
end user component, camel-test-karaf, and with good documentation to
go with that.
Then people can easier do this than today. Where they can copy some of
the source code from tests/camel-itest-osgi and use that in their own
pax-exam karaf tests of their Camel integration tests.
On Wed, Sep 11, 2013 at 8:55 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Agree with Achim, it's something that I plan for Camel (and other projects
> like ActiveMQ): pax-exam with the Karaf container allows good itests.
>
> We use it for Cellar: the itests, we can bootstrap a Karaf container,
> perform commands, check the result, etc.
>
> Regards
> JB
>
>
> On 09/11/2013 08:34 AM, Achim Nierbeck wrote:
>>
>> wow, now that is something I call a rant :D
>>
>> anyhow, you're only telling half the truth ;)
>> yes developing osgi might be cumbersome but to be hones EJB is the same
>> PITA
>> and I really hated working with JBoss and maven when I needed to work with
>> EJBs,
>> the turnaround cycles where awful and to me much better when developing
>> with Karaf and
>> dev:watch especially. (Sorry needed to rant about some EJB stuff too:) )
>> Anyway the unit-test with camel-blueprint are good but lack the support
>> for
>> JPA stuff
>> as it uses PojoSR wich just fails with the JPA stuff, and every now and
>> then you
>> just need to have this tested to so it fails.
>> About the Integration tests, we do have Pax-Exam at this point and it does
>> an
>> awful great job for testing also with Karaf as container.
>> And you might even are able to use this peace of Testing Framework for
>> your
>> unit
>> tests. I wrote a little blog entry about it at [1].
>>
>> At the end you'll always end up in the same situation with any container
>> (may it be a
>> JBoss, Tomcat or Karaf) you'll need some unit tests and some Integration
>> Tests.
>> And sometimes you want to have Integration tests that do work from the
>> inside of
>> the container not testing the outer interfaces but test some aspects from
>> Inside the container
>> and this is the point Pax-Exam comes real handy also for JBoss or Tomcat,
>> just take a
>> look at the latest versions.
>>
>> regards, Achim
>>
>> [1] -
>>
>> http://notizblog.nierbeck.de/2013/08/testing-camel-jpa-routes-with-pax-exam-and-karaf/
>>
>>
>> 2013/9/10 Claus Ibsen <cl...@gmail.com>
>>
>>> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <al...@alanfoster.me> wrote:
>>>>
>>>> @Claus - This is true when deployed to an OSGi container. However,
>>>
>>> within the
>>>>
>>>> context of camel testing this is not true. When using the camel testing
>>>> framework you need to supply all of the camel routes within your
>>>> `getBlueprintDescriptor`
>>>>
>>>> @fs I just wanted to add; In my experience i have found it is safer to
>>>
>>> test
>>>>
>>>> your deployed camel app end to end, and not rely on CamelBlueprintTests
>>>
>>> much
>>>>
>>>> - as they do not prove that your app will work when deployed to an OSGi
>>>> container, or work at runtime when deployed to a real OSGi container.
>>>>
>>>
>>> camel-test-blueprint is not a substitute for integration testing on
>>> the actual production like servers.
>>> IMHO you must always do this to ensure it works on your production
>>> environment.
>>>
>>> camel-test-blueprint makes development with blueprint much easier as
>>> you can do much quicker Camel development, and unit tests. And you can
>>> do debugging the same JVM etc. And much more.
>>>
>>> Doing development and running in Karaf is a pain. Even with the
>>> dev:watch command.
>>> IMHO camel-test-blueprint is a huge win, and I know some companies of
>>> ours that would hate us if we do not offer camel-test-blueprint. That
>>> said, the OSGI communities should making development with OSGi much
>>> easier and a pleasure, instead of what the state is here in the later
>>> half os 2013 currently is.
>>>
>>> Okay my development with OSGi is hard, rant is over (") comparing to
>>> what the norm is today.
>>>
>>> PS: Thought this reminds me, that we ought to offer a camel-test-karaf
>>> which makes doing integration testing with Karaf and Camel easier. We
>>> do have some code in tests/camel-itest-karaf we would need to dust off
>>> and make nicer, and as well document. There is a JIRA ticket for that.
>>>
>>> Again devlopment + unit test vs integration testing is IMHO two pieces
>>> that you need to have. But the former should be very easy to do, and
>>> camel-test-blueprint helps alot with that. Though unfortuntely it
>>> cannot do 100% the same as Karaf container so there can be some cases
>>> where you currently must deploy to karaf to do unit test also :(
>>>
>>>
>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>
>>>
>>> http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html
>>>>
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> Red Hat, Inc.
>>> Email: cibsen@redhat.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.com
>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: camel blueprint - unit tests
Posted by Christian Müller <ch...@gmail.com>.
What's the JIRA ticket where I can vote for it? ;-)
Best,
Christian
-----------------
Software Integration Specialist
Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Wed, Sep 11, 2013 at 8:55 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Agree with Achim, it's something that I plan for Camel (and other projects
> like ActiveMQ): pax-exam with the Karaf container allows good itests.
>
> We use it for Cellar: the itests, we can bootstrap a Karaf container,
> perform commands, check the result, etc.
>
> Regards
> JB
>
>
> On 09/11/2013 08:34 AM, Achim Nierbeck wrote:
>
>> wow, now that is something I call a rant :D
>>
>> anyhow, you're only telling half the truth ;)
>> yes developing osgi might be cumbersome but to be hones EJB is the same
>> PITA
>> and I really hated working with JBoss and maven when I needed to work with
>> EJBs,
>> the turnaround cycles where awful and to me much better when developing
>> with Karaf and
>> dev:watch especially. (Sorry needed to rant about some EJB stuff too:) )
>> Anyway the unit-test with camel-blueprint are good but lack the support
>> for
>> JPA stuff
>> as it uses PojoSR wich just fails with the JPA stuff, and every now and
>> then you
>> just need to have this tested to so it fails.
>> About the Integration tests, we do have Pax-Exam at this point and it does
>> an
>> awful great job for testing also with Karaf as container.
>> And you might even are able to use this peace of Testing Framework for
>> your
>> unit
>> tests. I wrote a little blog entry about it at [1].
>>
>> At the end you'll always end up in the same situation with any container
>> (may it be a
>> JBoss, Tomcat or Karaf) you'll need some unit tests and some Integration
>> Tests.
>> And sometimes you want to have Integration tests that do work from the
>> inside of
>> the container not testing the outer interfaces but test some aspects from
>> Inside the container
>> and this is the point Pax-Exam comes real handy also for JBoss or Tomcat,
>> just take a
>> look at the latest versions.
>>
>> regards, Achim
>>
>> [1] -
>> http://notizblog.nierbeck.de/**2013/08/testing-camel-jpa-**
>> routes-with-pax-exam-and-**karaf/<http://notizblog.nierbeck.de/2013/08/testing-camel-jpa-routes-with-pax-exam-and-karaf/>
>>
>>
>> 2013/9/10 Claus Ibsen <cl...@gmail.com>
>>
>> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <al...@alanfoster.me> wrote:
>>>
>>>> @Claus - This is true when deployed to an OSGi container. However,
>>>>
>>> within the
>>>
>>>> context of camel testing this is not true. When using the camel testing
>>>> framework you need to supply all of the camel routes within your
>>>> `getBlueprintDescriptor`
>>>>
>>>> @fs I just wanted to add; In my experience i have found it is safer to
>>>>
>>> test
>>>
>>>> your deployed camel app end to end, and not rely on CamelBlueprintTests
>>>>
>>> much
>>>
>>>> - as they do not prove that your app will work when deployed to an OSGi
>>>> container, or work at runtime when deployed to a real OSGi container.
>>>>
>>>>
>>> camel-test-blueprint is not a substitute for integration testing on
>>> the actual production like servers.
>>> IMHO you must always do this to ensure it works on your production
>>> environment.
>>>
>>> camel-test-blueprint makes development with blueprint much easier as
>>> you can do much quicker Camel development, and unit tests. And you can
>>> do debugging the same JVM etc. And much more.
>>>
>>> Doing development and running in Karaf is a pain. Even with the
>>> dev:watch command.
>>> IMHO camel-test-blueprint is a huge win, and I know some companies of
>>> ours that would hate us if we do not offer camel-test-blueprint. That
>>> said, the OSGI communities should making development with OSGi much
>>> easier and a pleasure, instead of what the state is here in the later
>>> half os 2013 currently is.
>>>
>>> Okay my development with OSGi is hard, rant is over (") comparing to
>>> what the norm is today.
>>>
>>> PS: Thought this reminds me, that we ought to offer a camel-test-karaf
>>> which makes doing integration testing with Karaf and Camel easier. We
>>> do have some code in tests/camel-itest-karaf we would need to dust off
>>> and make nicer, and as well document. There is a JIRA ticket for that.
>>>
>>> Again devlopment + unit test vs integration testing is IMHO two pieces
>>> that you need to have. But the former should be very easy to do, and
>>> camel-test-blueprint helps alot with that. Though unfortuntely it
>>> cannot do 100% the same as Karaf container so there can be some cases
>>> where you currently must deploy to karaf to do unit test also :(
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>> http://camel.465427.n5.nabble.**com/camel-blueprint-unit-**
>>> tests-tp5738925p5738960.html<http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html>
>>>
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> Red Hat, Inc.
>>> Email: cibsen@redhat.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.com
>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: camel blueprint - unit tests
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Agree with Achim, it's something that I plan for Camel (and other
projects like ActiveMQ): pax-exam with the Karaf container allows good
itests.
We use it for Cellar: the itests, we can bootstrap a Karaf container,
perform commands, check the result, etc.
Regards
JB
On 09/11/2013 08:34 AM, Achim Nierbeck wrote:
> wow, now that is something I call a rant :D
>
> anyhow, you're only telling half the truth ;)
> yes developing osgi might be cumbersome but to be hones EJB is the same
> PITA
> and I really hated working with JBoss and maven when I needed to work with
> EJBs,
> the turnaround cycles where awful and to me much better when developing
> with Karaf and
> dev:watch especially. (Sorry needed to rant about some EJB stuff too:) )
> Anyway the unit-test with camel-blueprint are good but lack the support for
> JPA stuff
> as it uses PojoSR wich just fails with the JPA stuff, and every now and
> then you
> just need to have this tested to so it fails.
> About the Integration tests, we do have Pax-Exam at this point and it does
> an
> awful great job for testing also with Karaf as container.
> And you might even are able to use this peace of Testing Framework for your
> unit
> tests. I wrote a little blog entry about it at [1].
>
> At the end you'll always end up in the same situation with any container
> (may it be a
> JBoss, Tomcat or Karaf) you'll need some unit tests and some Integration
> Tests.
> And sometimes you want to have Integration tests that do work from the
> inside of
> the container not testing the outer interfaces but test some aspects from
> Inside the container
> and this is the point Pax-Exam comes real handy also for JBoss or Tomcat,
> just take a
> look at the latest versions.
>
> regards, Achim
>
> [1] -
> http://notizblog.nierbeck.de/2013/08/testing-camel-jpa-routes-with-pax-exam-and-karaf/
>
>
> 2013/9/10 Claus Ibsen <cl...@gmail.com>
>
>> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <al...@alanfoster.me> wrote:
>>> @Claus - This is true when deployed to an OSGi container. However,
>> within the
>>> context of camel testing this is not true. When using the camel testing
>>> framework you need to supply all of the camel routes within your
>>> `getBlueprintDescriptor`
>>>
>>> @fs I just wanted to add; In my experience i have found it is safer to
>> test
>>> your deployed camel app end to end, and not rely on CamelBlueprintTests
>> much
>>> - as they do not prove that your app will work when deployed to an OSGi
>>> container, or work at runtime when deployed to a real OSGi container.
>>>
>>
>> camel-test-blueprint is not a substitute for integration testing on
>> the actual production like servers.
>> IMHO you must always do this to ensure it works on your production
>> environment.
>>
>> camel-test-blueprint makes development with blueprint much easier as
>> you can do much quicker Camel development, and unit tests. And you can
>> do debugging the same JVM etc. And much more.
>>
>> Doing development and running in Karaf is a pain. Even with the
>> dev:watch command.
>> IMHO camel-test-blueprint is a huge win, and I know some companies of
>> ours that would hate us if we do not offer camel-test-blueprint. That
>> said, the OSGI communities should making development with OSGi much
>> easier and a pleasure, instead of what the state is here in the later
>> half os 2013 currently is.
>>
>> Okay my development with OSGi is hard, rant is over (") comparing to
>> what the norm is today.
>>
>> PS: Thought this reminds me, that we ought to offer a camel-test-karaf
>> which makes doing integration testing with Karaf and Camel easier. We
>> do have some code in tests/camel-itest-karaf we would need to dust off
>> and make nicer, and as well document. There is a JIRA ticket for that.
>>
>> Again devlopment + unit test vs integration testing is IMHO two pieces
>> that you need to have. But the former should be very easy to do, and
>> camel-test-blueprint helps alot with that. Though unfortuntely it
>> cannot do 100% the same as Karaf container so there can be some cases
>> where you currently must deploy to karaf to do unit test also :(
>>
>>
>>
>>>
>>>
>>> --
>>> View this message in context:
>> http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: cibsen@redhat.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: camel blueprint - unit tests
Posted by Achim Nierbeck <bc...@googlemail.com>.
wow, now that is something I call a rant :D
anyhow, you're only telling half the truth ;)
yes developing osgi might be cumbersome but to be hones EJB is the same
PITA
and I really hated working with JBoss and maven when I needed to work with
EJBs,
the turnaround cycles where awful and to me much better when developing
with Karaf and
dev:watch especially. (Sorry needed to rant about some EJB stuff too:) )
Anyway the unit-test with camel-blueprint are good but lack the support for
JPA stuff
as it uses PojoSR wich just fails with the JPA stuff, and every now and
then you
just need to have this tested to so it fails.
About the Integration tests, we do have Pax-Exam at this point and it does
an
awful great job for testing also with Karaf as container.
And you might even are able to use this peace of Testing Framework for your
unit
tests. I wrote a little blog entry about it at [1].
At the end you'll always end up in the same situation with any container
(may it be a
JBoss, Tomcat or Karaf) you'll need some unit tests and some Integration
Tests.
And sometimes you want to have Integration tests that do work from the
inside of
the container not testing the outer interfaces but test some aspects from
Inside the container
and this is the point Pax-Exam comes real handy also for JBoss or Tomcat,
just take a
look at the latest versions.
regards, Achim
[1] -
http://notizblog.nierbeck.de/2013/08/testing-camel-jpa-routes-with-pax-exam-and-karaf/
2013/9/10 Claus Ibsen <cl...@gmail.com>
> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <al...@alanfoster.me> wrote:
> > @Claus - This is true when deployed to an OSGi container. However,
> within the
> > context of camel testing this is not true. When using the camel testing
> > framework you need to supply all of the camel routes within your
> > `getBlueprintDescriptor`
> >
> > @fs I just wanted to add; In my experience i have found it is safer to
> test
> > your deployed camel app end to end, and not rely on CamelBlueprintTests
> much
> > - as they do not prove that your app will work when deployed to an OSGi
> > container, or work at runtime when deployed to a real OSGi container.
> >
>
> camel-test-blueprint is not a substitute for integration testing on
> the actual production like servers.
> IMHO you must always do this to ensure it works on your production
> environment.
>
> camel-test-blueprint makes development with blueprint much easier as
> you can do much quicker Camel development, and unit tests. And you can
> do debugging the same JVM etc. And much more.
>
> Doing development and running in Karaf is a pain. Even with the
> dev:watch command.
> IMHO camel-test-blueprint is a huge win, and I know some companies of
> ours that would hate us if we do not offer camel-test-blueprint. That
> said, the OSGI communities should making development with OSGi much
> easier and a pleasure, instead of what the state is here in the later
> half os 2013 currently is.
>
> Okay my development with OSGi is hard, rant is over (") comparing to
> what the norm is today.
>
> PS: Thought this reminds me, that we ought to offer a camel-test-karaf
> which makes doing integration testing with Karaf and Camel easier. We
> do have some code in tests/camel-itest-karaf we would need to dust off
> and make nicer, and as well document. There is a JIRA ticket for that.
>
> Again devlopment + unit test vs integration testing is IMHO two pieces
> that you need to have. But the former should be very easy to do, and
> camel-test-blueprint helps alot with that. Though unfortuntely it
> cannot do 100% the same as Karaf container so there can be some cases
> where you currently must deploy to karaf to do unit test also :(
>
>
>
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>
Re: camel blueprint - unit tests
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <al...@alanfoster.me> wrote:
> @Claus - This is true when deployed to an OSGi container. However, within the
> context of camel testing this is not true. When using the camel testing
> framework you need to supply all of the camel routes within your
> `getBlueprintDescriptor`
>
> @fs I just wanted to add; In my experience i have found it is safer to test
> your deployed camel app end to end, and not rely on CamelBlueprintTests much
> - as they do not prove that your app will work when deployed to an OSGi
> container, or work at runtime when deployed to a real OSGi container.
>
camel-test-blueprint is not a substitute for integration testing on
the actual production like servers.
IMHO you must always do this to ensure it works on your production environment.
camel-test-blueprint makes development with blueprint much easier as
you can do much quicker Camel development, and unit tests. And you can
do debugging the same JVM etc. And much more.
Doing development and running in Karaf is a pain. Even with the
dev:watch command.
IMHO camel-test-blueprint is a huge win, and I know some companies of
ours that would hate us if we do not offer camel-test-blueprint. That
said, the OSGI communities should making development with OSGi much
easier and a pleasure, instead of what the state is here in the later
half os 2013 currently is.
Okay my development with OSGi is hard, rant is over (") comparing to
what the norm is today.
PS: Thought this reminds me, that we ought to offer a camel-test-karaf
which makes doing integration testing with Karaf and Camel easier. We
do have some code in tests/camel-itest-karaf we would need to dust off
and make nicer, and as well document. There is a JIRA ticket for that.
Again devlopment + unit test vs integration testing is IMHO two pieces
that you need to have. But the former should be very easy to do, and
camel-test-blueprint helps alot with that. Though unfortuntely it
cannot do 100% the same as Karaf container so there can be some cases
where you currently must deploy to karaf to do unit test also :(
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: camel blueprint - unit tests
Posted by AlanFoster <al...@alanfoster.me>.
@Claus - This is true when deployed to an OSGi container. However, within the
context of camel testing this is not true. When using the camel testing
framework you need to supply all of the camel routes within your
`getBlueprintDescriptor`
@fs I just wanted to add; In my experience i have found it is safer to test
your deployed camel app end to end, and not rely on CamelBlueprintTests much
- as they do not prove that your app will work when deployed to an OSGi
container, or work at runtime when deployed to a real OSGi container.
--
View this message in context: http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel blueprint - unit tests
Posted by Claus Ibsen <cl...@gmail.com>.
I think <import> is not supported in OSGi Blueprint.
Though if you add your xml files in the OSGI-INF/blueprint directory
then they are all automatic loaded and available, so you dont need to
use <import>
On Mon, Sep 9, 2013 at 8:36 AM, fs <mh...@gmail.com> wrote:
> Trying to get the following example working with blueprint but with no
> success:
>
> http://camel.apache.org/how-do-i-import-routes-from-other-xml-files.html
>
> Test class:
>
> public class BlueprintTest extends CamelBlueprintTestSupport {
>
> @Override
> protected String getBlueprintDescriptor() {
> return "/OSGI-INF/blueprint/test-context_2.xml";
> }
>
> @Test
> public void testRoute() throws Exception {
>
> getMockEndpoint("mock:result").expectedMessageCount(1);
>
> template.sendBody("direct:start", "test");
>
> assertMockEndpointsSatisfied();
> }
> }
>
> Blueprint configurations:
>
> first:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>
> <import resource="OSGI-INF/blueprint/test-context_1.xml"/>
>
> <camelContext xmlns="http://camel.apache.org/schema/blueprint">
>
> <routeContextRef ref="myCoolRoutes"/>
>
> <route id="inside">
> <from uri="direct:inside"/>
> <to uri="mock:inside"/>
> </route>
> </camelContext>
>
> </blueprint>
>
> second:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>
> <routeContext id="myCoolRoutes"
> xmlns="http://camel.apache.org/schema/blueprint">
> <route id="cool">
> <from uri="direct:start"/>
> <to uri="mock:result"/>
> </route>
> <route id="bar">
> <from uri="direct:bar"/>
> <to uri="mock:bar"/>
> </route>
> </routeContext>
>
> </blueprint>
>
> stacktrace:
>
> testRoute(fi.eura2014.integration.BlueprintTest) Time elapsed: 30.806 sec
> <<< ERROR!
> java.lang.RuntimeException: Gave up waiting for service
> (objectClass=org.apache.camel.CamelContext)
> at
> org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:203)
> at
> org.apache.camel.test.blueprint.CamelBlueprintHelper.getOsgiService(CamelBlueprintHelper.java:165)
> at
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createCamelContext(CamelBlueprintTestSupport.java:116)
> at
> org.apache.camel.test.junit4.CamelTestSupport.doSetUp(CamelTestSupport.java:247)
> at
> org.apache.camel.test.junit4.CamelTestSupport.setUp(CamelTestSupport.java:217)
> at
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>
>
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738911.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen