Author: buildbot
Date: Wed Mar 9 16:18:39 2016
New Revision: 982321
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/cdi-testing.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/cdi-testing.html
==============================================================================
--- websites/production/camel/content/cdi-testing.html (original)
+++ websites/production/camel/content/cdi-testing.html Wed Mar 9 16:18:39 2016
@@ -313,22 +313,78 @@ public class PaxCdiOsgiTest {
context.getStatus(), equalTo(ServiceStatus.Started));
}
}
-
]]></script>
-</div></div><p>You can see the tests in<span style="color:
rgb(0,0,0);"> the </span><span style="color:
rgb(0,0,0);"><code>camel-example-cdi-osgi</code> example for a complete
working example of testing a Camel CDI application deployed in an OSGi
container using PAX Exam.</span></p><h3 id="CDITesting-TestingPatterns">Testing
Patterns</h3><p>You can see the tests in<span style="color:
rgb(0,0,0);"> the </span><span style="color:
rgb(0,0,0);"><code>camel-example-cdi-test</code> example for a thorough
overview of the following testing patterns for Camel CDI
applications.</span></p><h4 id="CDITesting-RoutesadvisingwithadviceWith"><span
style="color: rgb(0,0,0);">Routes advising with
<code>adviceWith</code></span></h4><p><span style="color:
rgb(0,0,0);"><span><code><a shape="rect"
href="advicewith.html">AdviceWith</a></code> is used for testing Camel routes
where you can </span><em>advice</em><span> an existing route before
its being tested. It all
ows to add <a shape="rect" class="external-link"
href="http://camel.apache.org/intercept.html";>Intercept</a> or
<em>weave</em> routes for testing purpose, for example using the <a
shape="rect"
href="mock.html">Mock</a> component</span><span>.</span></span></p><p><span
style="color: rgb(0,0,0);">It is recommended to only advice routes which are
not started already. To meet that requirement, you can use
the </span><code>CamelContextStartingEvent</code> event by declaring an
observer method in which you use <code>adviceWith</code> to add a
<code>mock</code> endpoint at the end of your Camel route<span style="color:
rgb(0,0,0);">, e.g.:</span></p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[void advice(@Observes
CamelContextStartingEvent event,
- @Uri("mock:test") MockEndpoint messages,
- ModelCamelContext context) throws Exception {
+</div></div><p>You can see the tests in<span style="color:
rgb(0,0,0);"> the </span><span style="color:
rgb(0,0,0);"><code>camel-example-cdi-osgi</code> example for a complete
working example of testing a Camel CDI application deployed in an OSGi
container using PAX Exam.</span></p><h3 id="CDITesting-TestingPatterns">Testing
Patterns</h3><p>You can see the tests in<span style="color:
rgb(0,0,0);"> the </span><span style="color:
rgb(0,0,0);"><code>camel-example-cdi-test</code> example for a thorough
overview of the following testing patterns for Camel CDI
applications.</span></p><h4 id="CDITesting-Testroutes"><span style="color:
rgb(0,0,0);">Test routes</span></h4><p><span style="color: rgb(0,0,0);">You may
want to add some Camel routes to your Camel CDI applications for testing
purpose. For example to route some exchanges to a <code>MockEndpoint</code>
instance. You can do that by declaring a <code>RouteBuilder</code> bean within
the test class as you w
ould normally do in your application code, e.g.:</span></p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+Â
+ // Declare a RouteBuilder bean for testing purpose
+ // that is automatically added to the Camel context
+ static class TestRoute extends RouteBuilder {
- context.getRouteDefinition("route")
- .adviceWith(context, new AdviceWithRouteBuilder() {
- @Override
- public void configure() {
- weaveAddLast().to("mock:test");
- }
- });
+ @Override
+ public void configure() {
+
from("direct:out").routeId("test").to("mock:out");
+ }
+Â
+ // And retrieve the MockEndpoint for further assertions
+ @Inject
+ @Uri("mock:out")
+ MockEndpoint mock;
}]]></script>
-</div></div><h4 id="CDITesting-Beanalternatives"><span style="color:
rgb(0,0,0);">Bean alternatives</span></h4><p><span style="color:
rgb(0,0,0);"><br clear="none"></span></p><h4 id="CDITesting-Testroutes"><span
style="color: rgb(0,0,0);">Test routes</span></h4><p><span style="color:
rgb(0,0,0);"><br clear="none"></span></p><h4
id="CDITesting-Camelcontextcustomisation"><span style="color:
rgb(0,0,0);">Camel context customisation</span></h4><p><span style="color:
rgb(0,0,0);">You may need to customise your Camel contexts for testing purpose,
for example disabling JMX management to avoid TCP port allocation conflict. You
can do that by declaring a custom Camel context bean in your test class,
e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div></div><p><span style="color: rgb(0,0,0);">You can find more information
in <a shape="rect" href="cdi.html#CDI-Auto-detectingCamelroutes">auto-detecting
Camel routes</a>.</span></p><h4 id="CDITesting-Beanalternatives"><span
style="color: rgb(0,0,0);">Bean alternatives</span></h4><p><span style="color:
rgb(0,0,0);">You may want to replace a bean that is used in your Camel routes
by another bean for testing purpose, for example to mock it or change the
behaviour of the application bean.</span></p><p><span style="color:
rgb(0,0,0);">Imagine you have the following route in your
application:</span></p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[public class Application {
+
+ @ContextName("camel-test-cdi")
+ static class Hello extends RouteBuilder {
+
+ @Override
+ public void configure() {
+
from("direct:in").bean("bean").to("direct:out");
+ }
+ }]]></script>
+</div></div><p><span style="color: rgb(0,0,0);">And the corresponding
bean:</span></p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[@Named("bean")
+public class Bean {
+
+ public String process(@Body String body) {
+ return body;
+ }
+}]]></script>
+</div></div><p><span style="color: rgb(0,0,0);">Then you can replace the bean
above in your tests by declaring an <em>alternative</em> bean, annotated
with <code>@Alternative</code>, e.g.:</span></p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[@Alternative
+@Named("bean")
+public class AlternativeBean {
+
+ public String process(@Body String body) {
+ return body + " with alternative bean!";
+ }
+}]]></script>
+</div></div><p><span style="color: rgb(0,0,0);">And you need to activate
(a.k.a. <em>select</em> in CDI terminology) this alternative bean in your
tests. If your using the <code>CamelCdiRunner</code> JUnit runner, you can do
that with the <code>@Beans</code> annotation provided by the Camel CDI test
module, e.g.:</span></p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
+@Beans(alternatives = AlternativeBean.class)
+public class CamelCdiTest {
+
+ @Test
+ public void testAlternativeBean(@Uri("direct:in")
ProducerTemplate producer
+ @Uri("mock:out") MockEndpoint
mock) throws InterruptedException {
+ mock.expectedMessageCount(1);
+ mock.expectedBodiesReceived("test with alternative bean!");
+
+ producer.sendBody("test");
+
+ MockEndpoint.assertIsSatisfied(1L, TimeUnit.SECONDS, mock);
+ }
+
+ static class TestRoute extends RouteBuilder {
+
+ @Override
+ public void configure() {
+
from("direct:out").routeId("test").to("mock:out");
+ }
+ }
+}]]></script>
+</div></div><h4 id="CDITesting-Camelcontextcustomisation"><span style="color:
rgb(0,0,0);">Camel context customisation</span></h4><p><span style="color:
rgb(0,0,0);">You may need to customise your Camel contexts for testing purpose,
for example disabling JMX management to avoid TCP port allocation conflict. You
can do that by declaring a custom Camel context bean in your test class,
e.g.:</span></p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[@RunWith(CamelCdiRunner.class)
public class CamelCdiTest {
Â
@@ -343,7 +399,20 @@ public class CamelCdiTest {
}
}
}]]></script>
-</div></div><p><span style="color: rgb(0,0,0);">In that example, the custom
Camel context bean declared in the test class will be used during the test
execution instead of the default Camel context bean provided by the <a
shape="rect" href="cdi.html">Camel CDI component</a>.</span></p><p><span
style="color: rgb(0,0,0);font-weight: bold;">JUnit rules</span></p><p><span
style="color: rgb(0,0,0);">Camel CDI test starts the CDI container after all
the JUnit class rules have executed.</span></p><p><span style="color:
rgb(0,0,0);">That way, you can use JUnit class rules to initialise (resp.
clean-up) resources that your test classes would require during their execution
before the container initialises (resp. after the container has shutdown). For
example, you could use an embedded JMS broker like <span style="color:
rgb(0,0,0);"><a shape="rect" class="external-link"
href="https://activemq.apache.org/artemis/";>ActiveMQ Artemis</a> to test your
Camel JMS application</span>, e.g.:</span></p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><p><span style="color: rgb(0,0,0);">In that example, the custom
Camel context bean declared in the test class will be used during the test
execution instead of the default Camel context bean provided by the <a
shape="rect" href="cdi.html">Camel CDI component</a>.</span></p><h4
id="CDITesting-RoutesadvisingwithadviceWith"><span style="color:
rgb(0,0,0);">Routes advising with <code>adviceWith</code></span></h4><p><span
style="color: rgb(0,0,0);"><span><code><a shape="rect"
href="advicewith.html">AdviceWith</a></code> is used for testing Camel routes
where you can </span><em>advice</em><span> an existing route before
its being tested. It allows to add <a shape="rect" class="external-link"
href="http://camel.apache.org/intercept.html";>Intercept</a> or
<em>weave</em> routes for testing purpose, for example using the <a
shape="rect"
href="mock.html">Mock</a> component</span><span>.</span></span></p><p><span
style="color: rgb(0,0,0);">It is re
commended to only advice routes which are not started already. To meet that
requirement, you can use the </span><code>CamelContextStartingEvent</code>
event by declaring an observer method in which you use <code>adviceWith</code>
to add a <code>mock</code> endpoint at the end of your Camel route<span
style="color: rgb(0,0,0);">, e.g.:</span></p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[void advice(@Observes
CamelContextStartingEvent event,
+ @Uri("mock:test") MockEndpoint messages,
+ ModelCamelContext context) throws Exception {
+
+ context.getRouteDefinition("route")
+ .adviceWith(context, new AdviceWithRouteBuilder() {
+ @Override
+ public void configure() {
+ weaveAddLast().to("mock:test");
+ }
+ });
+}]]></script>
+</div></div><h4 id="CDITesting-JUnitrules"><span style="color:
rgb(0,0,0);">JUnit rules</span></h4><p><span style="color: rgb(0,0,0);">Camel
CDI test starts the CDI container after all the JUnit class rules have
executed.</span></p><p><span style="color: rgb(0,0,0);">That way, you can use
JUnit class rules to initialise (resp. clean-up) resources that your test
classes would require during their execution before the container initialises
(resp. after the container has shutdown). For example, you could use an
embedded JMS broker like <span><a shape="rect" class="external-link"
href="https://activemq.apache.org/artemis/";>ActiveMQ Artemis</a> to test
your Camel JMS application</span>, e.g.:</span></p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[import
org.apache.activemq.artemis.jms.server.embedded.EmbeddedJMS;
Â
@RunWith(CamelCdiRunner.class)
@@ -373,7 +442,7 @@ public class CamelCdiTest {
producer.sendBody("message");
}
}]]></script>
-</div></div><p><span style="color: rgb(0,0,0);">Another use case is to assert
the behaviour of your application after it has shutdown. In that case, you
can use the <code>Verifier</code> rule, e.g.:</span></p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p><span style="color: rgb(0,0,0);">Another use case is to assert
the behaviour of your application after it has shutdown. In that case, you
can use the <code>Verifier</code> rule, e.g.:</span></p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><