You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by ac...@apache.org on 2017/04/13 06:39:48 UTC
[1/2] camel git commit: CAMEL-10843 Aligned component adoc name
Repository: camel
Updated Branches:
refs/heads/master bb2d1fc71 -> 7042d7ae8
CAMEL-10843 Aligned component adoc name
Project: http://git-wip-us.apache.org/repos/asf/camel/repo
Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/94fa14a1
Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/94fa14a1
Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/94fa14a1
Branch: refs/heads/master
Commit: 94fa14a10bf889a234feeb019e2490924909efb8
Parents: bb2d1fc
Author: Tomohisa Igarashi <tm...@gmail.com>
Authored: Thu Apr 13 12:11:27 2017 +0900
Committer: Andrea Cosentino <an...@gmail.com>
Committed: Thu Apr 13 08:27:15 2017 +0200
----------------------------------------------------------------------
.../src/main/docs/shiro-security.adoc | 316 --------
components/camel-shiro/src/main/docs/shiro.adoc | 316 ++++++++
.../src/main/docs/spring-java-config.adoc | 98 ---
.../src/main/docs/spring-javaconfig.adoc | 98 +++
.../src/main/docs/cdi-testing.adoc | 749 -------------------
.../camel-test-cdi/src/main/docs/test-cdi.adoc | 749 +++++++++++++++++++
6 files changed, 1163 insertions(+), 1163 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/camel/blob/94fa14a1/components/camel-shiro/src/main/docs/shiro-security.adoc
----------------------------------------------------------------------
diff --git a/components/camel-shiro/src/main/docs/shiro-security.adoc b/components/camel-shiro/src/main/docs/shiro-security.adoc
deleted file mode 100644
index a0c0b86..0000000
--- a/components/camel-shiro/src/main/docs/shiro-security.adoc
+++ /dev/null
@@ -1,316 +0,0 @@
-[[ShiroSecurity-ShiroSecurityComponent]]
-Shiro Security Component
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-*Available as of Camel 2.5*
-
-The *shiro-security* component in Camel is a security focused component,
-based on the Apache Shiro security project.
-
-Apache Shiro is a powerful and flexible open-source security framework
-that cleanly handles authentication, authorization, enterprise session
-management and cryptography. The objective of the Apache Shiro project
-is to provide the most robust and comprehensive application security
-framework available while also being very easy to understand and
-extremely simple to use.
-
-This camel shiro-security component allows authentication and
-authorization support to be applied to different segments of a camel
-route.
-
-Shiro security is applied on a route using a Camel Policy. A Policy in
-Camel utilizes a strategy pattern for applying interceptors on Camel
-Processors. It offering the ability to apply cross-cutting concerns (for
-example. security, transactions etc) on sections/segments of a camel
-route.
-
-Maven users will need to add the following dependency to their `pom.xml`
-for this component:
-
-[source,xml]
-------------------------------------------------------------
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-shiro</artifactId>
- <version>x.x.x</version>
- <!-- use the same version as your Camel core version -->
-</dependency>
-------------------------------------------------------------
-
-[[ShiroSecurity-ShiroSecurityBasics]]
-Shiro Security Basics
-^^^^^^^^^^^^^^^^^^^^^
-
-To employ Shiro security on a camel route, a ShiroSecurityPolicy object
-must be instantiated with security configuration details (including
-users, passwords, roles etc). This object must then be applied to a
-camel route. This ShiroSecurityPolicy Object may also be registered in
-the Camel registry (JNDI or ApplicationContextRegistry) and then
-utilized on other routes in the Camel Context.
-
-Configuration details are provided to the ShiroSecurityPolicy using an
-Ini file (properties file) or an Ini object. The Ini file is a standard
-Shiro configuration file containing user/role details as shown below
-
-[source,java]
-------------------------------------------------------------------
-[users]
-# user 'ringo' with password 'starr' and the 'sec-level1' role
-ringo = starr, sec-level1
-george = harrison, sec-level2
-john = lennon, sec-level3
-paul = mccartney, sec-level3
-
-[roles]
-# 'sec-level3' role has all permissions, indicated by the
-# wildcard '*'
-sec-level3 = *
-
-# The 'sec-level2' role can do anything with access of permission
-# readonly (*) to help
-sec-level2 = zone1:*
-
-# The 'sec-level1' role can do anything with access of permission
-# readonly
-sec-level1 = zone1:readonly:*
-------------------------------------------------------------------
-
-[[ShiroSecurity-InstantiatingaShiroSecurityPolicyObject]]
-Instantiating a ShiroSecurityPolicy Object
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A ShiroSecurityPolicy object is instantiated as follows
-
-[source,java]
-----------------------------------------------------------------------------------------
- private final String iniResourcePath = "classpath:shiro.ini";
- private final byte[] passPhrase = {
- (byte) 0x08, (byte) 0x09, (byte) 0x0A, (byte) 0x0B,
- (byte) 0x0C, (byte) 0x0D, (byte) 0x0E, (byte) 0x0F,
- (byte) 0x10, (byte) 0x11, (byte) 0x12, (byte) 0x13,
- (byte) 0x14, (byte) 0x15, (byte) 0x16, (byte) 0x17};
- List<permission> permissionsList = new ArrayList<permission>();
- Permission permission = new WildcardPermission("zone1:readwrite:*");
- permissionsList.add(permission);
-
- final ShiroSecurityPolicy securityPolicy =
- new ShiroSecurityPolicy(iniResourcePath, passPhrase, true, permissionsList);
-----------------------------------------------------------------------------------------
-
-[[ShiroSecurity-ShiroSecurityPolicyOptions]]
-ShiroSecurityPolicy Options
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-[width="100%",cols="10%,10%,10%,90%",options="header",]
-|=======================================================================
-|Name |Default Value |Type |Description
-
-|`iniResourcePath or ini` |`none` |Resource String or Ini Object |A mandatory Resource String for the iniResourcePath or an instance of an
-Ini object must be passed to the security policy. Resources can be
-acquired from the file system, classpath, or URLs when prefixed with
-"file:, classpath:, or url:" respectively. For e.g "classpath:shiro.ini"
-
-|`passPhrase` |`An AES 128 based key` |byte[] |A passPhrase to decrypt ShiroSecurityToken(s) sent along with Message
-Exchanges
-
-|`alwaysReauthenticate` |`true` |boolean |Setting to ensure re-authentication on every individual request. If set
-to false, the user is authenticated and locked such than only requests
-from the same user going forward are authenticated.
-
-|`permissionsList` |`none` |List<Permission> |A List of permissions required in order for an authenticated user to be
-authorized to perform further action i.e continue further on the route.
-If no Permissions list or Roles List (see below) is provided to the
-ShiroSecurityPolicy object, then authorization is deemed as not
-required. Note that the default is that authorization is granted if any
-of the Permission Objects in the list are applicable.
-
-|`rolesList` |`none` |List<String> |*Camel 2.13:* A List of roles required in order for an authenticated
-user to be authorized to perform further action i.e continue further on
-the route. If no roles list or permissions list (see above) is provided
-to the ShiroSecurityPolicy object, then authorization is deemed as not
-required. Note that the default is that authorization is granted if any
-of the roles in the list are applicable.
-
-|`cipherService` |`AES` |org.apache.shiro.crypto.CipherService |Shiro ships with AES & Blowfish based CipherServices. You may use one
-these or pass in your own Cipher implementation
-
-|`base64` |`false` |`boolean` |*Camel 2.12:* To use base64 encoding for the security token header,
-which allows transferring the header over link:jms.html[JMS] etc. This
-option must also be set on `ShiroSecurityTokenInjector` as well.
-
-|`allPermissionsRequired` |`false` |`boolean` |*Camel 2.13:* The default is that authorization is granted if any of the
-Permission Objects in the permissionsList parameter are applicable. Set
-this to true to require all of the Permissions to be met.
-
-|`allRolesRequired` |`false` |`boolean` |*Camel 2.13:* The default is that authorization is granted if any of the
-roles in the rolesList parameter are applicable. Set this to true to
-require all of the roles to be met.
-|=======================================================================
-
-[[ShiroSecurity-ApplyingShiroAuthenticationonaCamelRoute]]
-Applying Shiro Authentication on a Camel Route
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The ShiroSecurityPolicy, tests and permits incoming message exchanges
-containing a encrypted SecurityToken in the Message Header to proceed
-further following proper authentication. The SecurityToken object
-contains a Username/Password details that are used to determine where
-the user is a valid user.
-
-[source,java]
------------------------------------------------------------------------
- protected RouteBuilder createRouteBuilder() throws Exception {
- final ShiroSecurityPolicy securityPolicy =
- new ShiroSecurityPolicy("classpath:shiro.ini", passPhrase);
-
- return new RouteBuilder() {
- public void configure() {
- onException(UnknownAccountException.class).
- to("mock:authenticationException");
- onException(IncorrectCredentialsException.class).
- to("mock:authenticationException");
- onException(LockedAccountException.class).
- to("mock:authenticationException");
- onException(AuthenticationException.class).
- to("mock:authenticationException");
-
- from("direct:secureEndpoint").
- to("log:incoming payload").
- policy(securityPolicy).
- to("mock:success");
- }
- };
- }
------------------------------------------------------------------------
-
-[[ShiroSecurity-ApplyingShiroAuthorizationonaCamelRoute]]
-Applying Shiro Authorization on a Camel Route
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Authorization can be applied on a camel route by associating a
-Permissions List with the ShiroSecurityPolicy. The Permissions List
-specifies the permissions necessary for the user to proceed with the
-execution of the route segment. If the user does not have the proper
-permission set, the request is not authorized to continue any further.
-
-[source,java]
--------------------------------------------------------------------------------------------
- protected RouteBuilder createRouteBuilder() throws Exception {
- final ShiroSecurityPolicy securityPolicy =
- new ShiroSecurityPolicy("./src/test/resources/securityconfig.ini", passPhrase);
-
- return new RouteBuilder() {
- public void configure() {
- onException(UnknownAccountException.class).
- to("mock:authenticationException");
- onException(IncorrectCredentialsException.class).
- to("mock:authenticationException");
- onException(LockedAccountException.class).
- to("mock:authenticationException");
- onException(AuthenticationException.class).
- to("mock:authenticationException");
-
- from("direct:secureEndpoint").
- to("log:incoming payload").
- policy(securityPolicy).
- to("mock:success");
- }
- };
- }
--------------------------------------------------------------------------------------------
-
-[[ShiroSecurity-CreatingaShiroSecurityTokenandinjectingitintoaMessageExchange]]
-Creating a ShiroSecurityToken and injecting it into a Message Exchange
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-A ShiroSecurityToken object may be created and injected into a Message
-Exchange using a Shiro Processor called ShiroSecurityTokenInjector. An
-example of injecting a ShiroSecurityToken using a
-ShiroSecurityTokenInjector in the client is shown below
-
-[source,java]
--------------------------------------------------------------------------------------
- ShiroSecurityToken shiroSecurityToken = new ShiroSecurityToken("ringo", "starr");
- ShiroSecurityTokenInjector shiroSecurityTokenInjector =
- new ShiroSecurityTokenInjector(shiroSecurityToken, passPhrase);
-
- from("direct:client").
- process(shiroSecurityTokenInjector).
- to("direct:secureEndpoint");
--------------------------------------------------------------------------------------
-
-[[ShiroSecurity-SendingMessagestoroutessecuredbyaShiroSecurityPolicy]]
-Sending Messages to routes secured by a ShiroSecurityPolicy
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Messages and Message Exchanges sent along the camel route where the
-security policy is applied need to be accompanied by a SecurityToken in
-the Exchange Header. The SecurityToken is an encrypted object that holds
-a Username and Password. The SecurityToken is encrypted using AES 128
-bit security by default and can be changed to any cipher of your choice.
-
-Given below is an example of how a request may be sent using a
-ProducerTemplate in Camel along with a SecurityToken
-
-[source,java]
--------------------------------------------------------------------------------------------------
-
- @Test
- public void testSuccessfulShiroAuthenticationWithNoAuthorization() throws Exception {
- //Incorrect password
- ShiroSecurityToken shiroSecurityToken = new ShiroSecurityToken("ringo", "stirr");
-
- // TestShiroSecurityTokenInjector extends ShiroSecurityTokenInjector
- TestShiroSecurityTokenInjector shiroSecurityTokenInjector =
- new TestShiroSecurityTokenInjector(shiroSecurityToken, passPhrase);
-
- successEndpoint.expectedMessageCount(1);
- failureEndpoint.expectedMessageCount(0);
-
- template.send("direct:secureEndpoint", shiroSecurityTokenInjector);
-
- successEndpoint.assertIsSatisfied();
- failureEndpoint.assertIsSatisfied();
- }
--------------------------------------------------------------------------------------------------
-
-[[ShiroSecurity-SendingMessagestoroutessecuredbyaShiroSecurityPolicymucheasierfromCamel2.12onwards]]
-Sending Messages to routes secured by a ShiroSecurityPolicy (much easier from Camel 2.12 onwards)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-From *Camel 2.12* onwards its even easier as you can provide the subject
-in two different ways.
-
-[[ShiroSecurity-UsingShiroSecurityToken]]
-Using ShiroSecurityToken
-++++++++++++++++++++++++
-
-You can send a message to a Camel route with a header of key
-`ShiroSecurityConstants.SHIRO_SECURITY_TOKEN` of the type
-`org.apache.camel.component.shiro.security.ShiroSecurityToken` that
-contains the username and password. For example:
-
-[source,java]
----------------------------------------------------------------------------------------------------------------------------------------------
- ShiroSecurityToken shiroSecurityToken = new ShiroSecurityToken("ringo", "starr");
-
- template.sendBodyAndHeader("direct:secureEndpoint", "Beatle Mania", ShiroSecurityConstants.SHIRO_SECURITY_TOKEN, shiroSecurityToken);
----------------------------------------------------------------------------------------------------------------------------------------------
-
-You can also provide the username and password in two different headers
-as shown below:
-
-[source,java]
---------------------------------------------------------------------------------------
- Map<String, Object> headers = new HashMap<String, Object>();
- headers.put(ShiroSecurityConstants.SHIRO_SECURITY_USERNAME, "ringo");
- headers.put(ShiroSecurityConstants.SHIRO_SECURITY_PASSWORD, "starr");
- template.sendBodyAndHeaders("direct:secureEndpoint", "Beatle Mania", headers);
---------------------------------------------------------------------------------------
-
-When you use the username and password headers, then the
-ShiroSecurityPolicy in the Camel route will automatic transform those
-into a single header with key
-ShiroSecurityConstants.SHIRO_SECURITY_TOKEN with the token. Then token
-is either a `ShiroSecurityToken` instance, or a base64 representation as
-a String (the latter is when you have set base64=true).
http://git-wip-us.apache.org/repos/asf/camel/blob/94fa14a1/components/camel-shiro/src/main/docs/shiro.adoc
----------------------------------------------------------------------
diff --git a/components/camel-shiro/src/main/docs/shiro.adoc b/components/camel-shiro/src/main/docs/shiro.adoc
new file mode 100644
index 0000000..a0c0b86
--- /dev/null
+++ b/components/camel-shiro/src/main/docs/shiro.adoc
@@ -0,0 +1,316 @@
+[[ShiroSecurity-ShiroSecurityComponent]]
+Shiro Security Component
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+*Available as of Camel 2.5*
+
+The *shiro-security* component in Camel is a security focused component,
+based on the Apache Shiro security project.
+
+Apache Shiro is a powerful and flexible open-source security framework
+that cleanly handles authentication, authorization, enterprise session
+management and cryptography. The objective of the Apache Shiro project
+is to provide the most robust and comprehensive application security
+framework available while also being very easy to understand and
+extremely simple to use.
+
+This camel shiro-security component allows authentication and
+authorization support to be applied to different segments of a camel
+route.
+
+Shiro security is applied on a route using a Camel Policy. A Policy in
+Camel utilizes a strategy pattern for applying interceptors on Camel
+Processors. It offering the ability to apply cross-cutting concerns (for
+example. security, transactions etc) on sections/segments of a camel
+route.
+
+Maven users will need to add the following dependency to their `pom.xml`
+for this component:
+
+[source,xml]
+------------------------------------------------------------
+<dependency>
+ <groupId>org.apache.camel</groupId>
+ <artifactId>camel-shiro</artifactId>
+ <version>x.x.x</version>
+ <!-- use the same version as your Camel core version -->
+</dependency>
+------------------------------------------------------------
+
+[[ShiroSecurity-ShiroSecurityBasics]]
+Shiro Security Basics
+^^^^^^^^^^^^^^^^^^^^^
+
+To employ Shiro security on a camel route, a ShiroSecurityPolicy object
+must be instantiated with security configuration details (including
+users, passwords, roles etc). This object must then be applied to a
+camel route. This ShiroSecurityPolicy Object may also be registered in
+the Camel registry (JNDI or ApplicationContextRegistry) and then
+utilized on other routes in the Camel Context.
+
+Configuration details are provided to the ShiroSecurityPolicy using an
+Ini file (properties file) or an Ini object. The Ini file is a standard
+Shiro configuration file containing user/role details as shown below
+
+[source,java]
+------------------------------------------------------------------
+[users]
+# user 'ringo' with password 'starr' and the 'sec-level1' role
+ringo = starr, sec-level1
+george = harrison, sec-level2
+john = lennon, sec-level3
+paul = mccartney, sec-level3
+
+[roles]
+# 'sec-level3' role has all permissions, indicated by the
+# wildcard '*'
+sec-level3 = *
+
+# The 'sec-level2' role can do anything with access of permission
+# readonly (*) to help
+sec-level2 = zone1:*
+
+# The 'sec-level1' role can do anything with access of permission
+# readonly
+sec-level1 = zone1:readonly:*
+------------------------------------------------------------------
+
+[[ShiroSecurity-InstantiatingaShiroSecurityPolicyObject]]
+Instantiating a ShiroSecurityPolicy Object
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A ShiroSecurityPolicy object is instantiated as follows
+
+[source,java]
+----------------------------------------------------------------------------------------
+ private final String iniResourcePath = "classpath:shiro.ini";
+ private final byte[] passPhrase = {
+ (byte) 0x08, (byte) 0x09, (byte) 0x0A, (byte) 0x0B,
+ (byte) 0x0C, (byte) 0x0D, (byte) 0x0E, (byte) 0x0F,
+ (byte) 0x10, (byte) 0x11, (byte) 0x12, (byte) 0x13,
+ (byte) 0x14, (byte) 0x15, (byte) 0x16, (byte) 0x17};
+ List<permission> permissionsList = new ArrayList<permission>();
+ Permission permission = new WildcardPermission("zone1:readwrite:*");
+ permissionsList.add(permission);
+
+ final ShiroSecurityPolicy securityPolicy =
+ new ShiroSecurityPolicy(iniResourcePath, passPhrase, true, permissionsList);
+----------------------------------------------------------------------------------------
+
+[[ShiroSecurity-ShiroSecurityPolicyOptions]]
+ShiroSecurityPolicy Options
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+[width="100%",cols="10%,10%,10%,90%",options="header",]
+|=======================================================================
+|Name |Default Value |Type |Description
+
+|`iniResourcePath or ini` |`none` |Resource String or Ini Object |A mandatory Resource String for the iniResourcePath or an instance of an
+Ini object must be passed to the security policy. Resources can be
+acquired from the file system, classpath, or URLs when prefixed with
+"file:, classpath:, or url:" respectively. For e.g "classpath:shiro.ini"
+
+|`passPhrase` |`An AES 128 based key` |byte[] |A passPhrase to decrypt ShiroSecurityToken(s) sent along with Message
+Exchanges
+
+|`alwaysReauthenticate` |`true` |boolean |Setting to ensure re-authentication on every individual request. If set
+to false, the user is authenticated and locked such than only requests
+from the same user going forward are authenticated.
+
+|`permissionsList` |`none` |List<Permission> |A List of permissions required in order for an authenticated user to be
+authorized to perform further action i.e continue further on the route.
+If no Permissions list or Roles List (see below) is provided to the
+ShiroSecurityPolicy object, then authorization is deemed as not
+required. Note that the default is that authorization is granted if any
+of the Permission Objects in the list are applicable.
+
+|`rolesList` |`none` |List<String> |*Camel 2.13:* A List of roles required in order for an authenticated
+user to be authorized to perform further action i.e continue further on
+the route. If no roles list or permissions list (see above) is provided
+to the ShiroSecurityPolicy object, then authorization is deemed as not
+required. Note that the default is that authorization is granted if any
+of the roles in the list are applicable.
+
+|`cipherService` |`AES` |org.apache.shiro.crypto.CipherService |Shiro ships with AES & Blowfish based CipherServices. You may use one
+these or pass in your own Cipher implementation
+
+|`base64` |`false` |`boolean` |*Camel 2.12:* To use base64 encoding for the security token header,
+which allows transferring the header over link:jms.html[JMS] etc. This
+option must also be set on `ShiroSecurityTokenInjector` as well.
+
+|`allPermissionsRequired` |`false` |`boolean` |*Camel 2.13:* The default is that authorization is granted if any of the
+Permission Objects in the permissionsList parameter are applicable. Set
+this to true to require all of the Permissions to be met.
+
+|`allRolesRequired` |`false` |`boolean` |*Camel 2.13:* The default is that authorization is granted if any of the
+roles in the rolesList parameter are applicable. Set this to true to
+require all of the roles to be met.
+|=======================================================================
+
+[[ShiroSecurity-ApplyingShiroAuthenticationonaCamelRoute]]
+Applying Shiro Authentication on a Camel Route
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ShiroSecurityPolicy, tests and permits incoming message exchanges
+containing a encrypted SecurityToken in the Message Header to proceed
+further following proper authentication. The SecurityToken object
+contains a Username/Password details that are used to determine where
+the user is a valid user.
+
+[source,java]
+-----------------------------------------------------------------------
+ protected RouteBuilder createRouteBuilder() throws Exception {
+ final ShiroSecurityPolicy securityPolicy =
+ new ShiroSecurityPolicy("classpath:shiro.ini", passPhrase);
+
+ return new RouteBuilder() {
+ public void configure() {
+ onException(UnknownAccountException.class).
+ to("mock:authenticationException");
+ onException(IncorrectCredentialsException.class).
+ to("mock:authenticationException");
+ onException(LockedAccountException.class).
+ to("mock:authenticationException");
+ onException(AuthenticationException.class).
+ to("mock:authenticationException");
+
+ from("direct:secureEndpoint").
+ to("log:incoming payload").
+ policy(securityPolicy).
+ to("mock:success");
+ }
+ };
+ }
+-----------------------------------------------------------------------
+
+[[ShiroSecurity-ApplyingShiroAuthorizationonaCamelRoute]]
+Applying Shiro Authorization on a Camel Route
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Authorization can be applied on a camel route by associating a
+Permissions List with the ShiroSecurityPolicy. The Permissions List
+specifies the permissions necessary for the user to proceed with the
+execution of the route segment. If the user does not have the proper
+permission set, the request is not authorized to continue any further.
+
+[source,java]
+-------------------------------------------------------------------------------------------
+ protected RouteBuilder createRouteBuilder() throws Exception {
+ final ShiroSecurityPolicy securityPolicy =
+ new ShiroSecurityPolicy("./src/test/resources/securityconfig.ini", passPhrase);
+
+ return new RouteBuilder() {
+ public void configure() {
+ onException(UnknownAccountException.class).
+ to("mock:authenticationException");
+ onException(IncorrectCredentialsException.class).
+ to("mock:authenticationException");
+ onException(LockedAccountException.class).
+ to("mock:authenticationException");
+ onException(AuthenticationException.class).
+ to("mock:authenticationException");
+
+ from("direct:secureEndpoint").
+ to("log:incoming payload").
+ policy(securityPolicy).
+ to("mock:success");
+ }
+ };
+ }
+-------------------------------------------------------------------------------------------
+
+[[ShiroSecurity-CreatingaShiroSecurityTokenandinjectingitintoaMessageExchange]]
+Creating a ShiroSecurityToken and injecting it into a Message Exchange
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A ShiroSecurityToken object may be created and injected into a Message
+Exchange using a Shiro Processor called ShiroSecurityTokenInjector. An
+example of injecting a ShiroSecurityToken using a
+ShiroSecurityTokenInjector in the client is shown below
+
+[source,java]
+-------------------------------------------------------------------------------------
+ ShiroSecurityToken shiroSecurityToken = new ShiroSecurityToken("ringo", "starr");
+ ShiroSecurityTokenInjector shiroSecurityTokenInjector =
+ new ShiroSecurityTokenInjector(shiroSecurityToken, passPhrase);
+
+ from("direct:client").
+ process(shiroSecurityTokenInjector).
+ to("direct:secureEndpoint");
+-------------------------------------------------------------------------------------
+
+[[ShiroSecurity-SendingMessagestoroutessecuredbyaShiroSecurityPolicy]]
+Sending Messages to routes secured by a ShiroSecurityPolicy
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Messages and Message Exchanges sent along the camel route where the
+security policy is applied need to be accompanied by a SecurityToken in
+the Exchange Header. The SecurityToken is an encrypted object that holds
+a Username and Password. The SecurityToken is encrypted using AES 128
+bit security by default and can be changed to any cipher of your choice.
+
+Given below is an example of how a request may be sent using a
+ProducerTemplate in Camel along with a SecurityToken
+
+[source,java]
+-------------------------------------------------------------------------------------------------
+
+ @Test
+ public void testSuccessfulShiroAuthenticationWithNoAuthorization() throws Exception {
+ //Incorrect password
+ ShiroSecurityToken shiroSecurityToken = new ShiroSecurityToken("ringo", "stirr");
+
+ // TestShiroSecurityTokenInjector extends ShiroSecurityTokenInjector
+ TestShiroSecurityTokenInjector shiroSecurityTokenInjector =
+ new TestShiroSecurityTokenInjector(shiroSecurityToken, passPhrase);
+
+ successEndpoint.expectedMessageCount(1);
+ failureEndpoint.expectedMessageCount(0);
+
+ template.send("direct:secureEndpoint", shiroSecurityTokenInjector);
+
+ successEndpoint.assertIsSatisfied();
+ failureEndpoint.assertIsSatisfied();
+ }
+-------------------------------------------------------------------------------------------------
+
+[[ShiroSecurity-SendingMessagestoroutessecuredbyaShiroSecurityPolicymucheasierfromCamel2.12onwards]]
+Sending Messages to routes secured by a ShiroSecurityPolicy (much easier from Camel 2.12 onwards)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+From *Camel 2.12* onwards its even easier as you can provide the subject
+in two different ways.
+
+[[ShiroSecurity-UsingShiroSecurityToken]]
+Using ShiroSecurityToken
+++++++++++++++++++++++++
+
+You can send a message to a Camel route with a header of key
+`ShiroSecurityConstants.SHIRO_SECURITY_TOKEN` of the type
+`org.apache.camel.component.shiro.security.ShiroSecurityToken` that
+contains the username and password. For example:
+
+[source,java]
+---------------------------------------------------------------------------------------------------------------------------------------------
+ ShiroSecurityToken shiroSecurityToken = new ShiroSecurityToken("ringo", "starr");
+
+ template.sendBodyAndHeader("direct:secureEndpoint", "Beatle Mania", ShiroSecurityConstants.SHIRO_SECURITY_TOKEN, shiroSecurityToken);
+---------------------------------------------------------------------------------------------------------------------------------------------
+
+You can also provide the username and password in two different headers
+as shown below:
+
+[source,java]
+--------------------------------------------------------------------------------------
+ Map<String, Object> headers = new HashMap<String, Object>();
+ headers.put(ShiroSecurityConstants.SHIRO_SECURITY_USERNAME, "ringo");
+ headers.put(ShiroSecurityConstants.SHIRO_SECURITY_PASSWORD, "starr");
+ template.sendBodyAndHeaders("direct:secureEndpoint", "Beatle Mania", headers);
+--------------------------------------------------------------------------------------
+
+When you use the username and password headers, then the
+ShiroSecurityPolicy in the Camel route will automatic transform those
+into a single header with key
+ShiroSecurityConstants.SHIRO_SECURITY_TOKEN with the token. Then token
+is either a `ShiroSecurityToken` instance, or a base64 representation as
+a String (the latter is when you have set base64=true).
http://git-wip-us.apache.org/repos/asf/camel/blob/94fa14a1/components/camel-spring-javaconfig/src/main/docs/spring-java-config.adoc
----------------------------------------------------------------------
diff --git a/components/camel-spring-javaconfig/src/main/docs/spring-java-config.adoc b/components/camel-spring-javaconfig/src/main/docs/spring-java-config.adoc
deleted file mode 100644
index 42127db..0000000
--- a/components/camel-spring-javaconfig/src/main/docs/spring-java-config.adoc
+++ /dev/null
@@ -1,98 +0,0 @@
-[[SpringJavaConfig-SpringJavaConfig]]
-Spring Java Config
-~~~~~~~~~~~~~~~~~~
-
-link:spring.html[Spring] started life using XML Config to wire beans
-together. However some folks don't like using XML and would rather use
-Java code which led to the creation of Guice along with the Spring
-JavaConfig project.
-
-You can use either the XML or Java config approaches with Camel; its
-your choice really on which you prefer.
-
-[[SpringJavaConfig-UsingSpringJavaConfig]]
-Using Spring Java Config
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-To use Spring Java Config in your Camel project the easiest thing to do
-is add the following to your pom.xml
-
-[source,xml]
---------------------------------------------------
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-spring-javaconfig</artifactId>
- <version>${camel-version}</version>
-</dependency>
---------------------------------------------------
-
-This will then add the dependencies on the Spring JavaConfig library
-along with some helper classes for configuring Camel inside Spring.
-
-Note that this library is totally optional; you could just wire Camel
-together yourself with Java Config.
-
-[[SpringJavaConfig-Configuration]]
-Configuration
-^^^^^^^^^^^^^
-
-The most common case of using JavaConfig with Camel would be to create
-configuration with defined list of routes to be used by router.
-
-[source,java]
---------------------------------------------------------------------
-@Configuration
-public class MyRouteConfiguration extends CamelConfiguration {
-
- @Autowire
- private MyRouteBuilder myRouteBuilder;
-
- @Autowire
- private MyAnotherRouteBuilder myAnotherRouteBuilder;
-
- @Override
- public List<RouteBuilder> routes() {
- return Arrays.asList(myRouteBuilder, myAnotherRouteBuilder);
- }
-
-}
---------------------------------------------------------------------
-
-Starting from Camel 2.13.0 you can skip the *routes()* definition, and
-fall back to the *RouteBuilder* instances located in the Spring context.
-
-[source,java]
---------------------------------------------------------------
-@Configuration
-@ComponentScan("com.example.routes")
-public class MyRouteConfiguration extends CamelConfiguration {
-}
---------------------------------------------------------------
-
-[[SpringJavaConfig-Testing]]
-Testing
-^^^^^^^
-
-Since *Camel 2.11.0* you can use the `CamelSpringJUnit4ClassRunner` with
-`CamelSpringDelegatingTestContextLoader`. This is the recommended way to
-test Java Config and Camel integration.
-
-If you wish to create a collection of *RouteBuilder* instances then
-derive from the *CamelConfiguration* helper class and implement the
-*routes()* method. Keep in mind that (starting from the Camel 2.13.0) if
-you don't override *routes()* method, then *CamelConfiguration* will use
-all *RouteBuilder* instances available in the Spring context.
-
-The following
-http://svn.apache.org/repos/asf/camel/trunk/components/camel-spring-javaconfig/src/test/java/org/apache/camel/spring/javaconfig/patterns/FilterTest.java[example
-using Java Config] demonstrates how to test Java Config integration with
-Camel 2.10 and lower. Keep in mind that `JavaConfigContextLoader` is
-deprecated and could be removed in the future versions of Camel on the
-behalf of the `CamelSpringDelegatingTestContextLoader`.
-
-The *@ContextConfiguration* annotation tells the
-link:spring-testing.html[Spring Testing] framework to load the
-*ContextConfig* class as the configuration to use. This class derives
-from *SingleRouteCamelConfiguration* which is a helper Spring Java
-Config class which will configure the CamelContext for us and then
-register the RouteBuilder we create.
http://git-wip-us.apache.org/repos/asf/camel/blob/94fa14a1/components/camel-spring-javaconfig/src/main/docs/spring-javaconfig.adoc
----------------------------------------------------------------------
diff --git a/components/camel-spring-javaconfig/src/main/docs/spring-javaconfig.adoc b/components/camel-spring-javaconfig/src/main/docs/spring-javaconfig.adoc
new file mode 100644
index 0000000..42127db
--- /dev/null
+++ b/components/camel-spring-javaconfig/src/main/docs/spring-javaconfig.adoc
@@ -0,0 +1,98 @@
+[[SpringJavaConfig-SpringJavaConfig]]
+Spring Java Config
+~~~~~~~~~~~~~~~~~~
+
+link:spring.html[Spring] started life using XML Config to wire beans
+together. However some folks don't like using XML and would rather use
+Java code which led to the creation of Guice along with the Spring
+JavaConfig project.
+
+You can use either the XML or Java config approaches with Camel; its
+your choice really on which you prefer.
+
+[[SpringJavaConfig-UsingSpringJavaConfig]]
+Using Spring Java Config
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+To use Spring Java Config in your Camel project the easiest thing to do
+is add the following to your pom.xml
+
+[source,xml]
+--------------------------------------------------
+<dependency>
+ <groupId>org.apache.camel</groupId>
+ <artifactId>camel-spring-javaconfig</artifactId>
+ <version>${camel-version}</version>
+</dependency>
+--------------------------------------------------
+
+This will then add the dependencies on the Spring JavaConfig library
+along with some helper classes for configuring Camel inside Spring.
+
+Note that this library is totally optional; you could just wire Camel
+together yourself with Java Config.
+
+[[SpringJavaConfig-Configuration]]
+Configuration
+^^^^^^^^^^^^^
+
+The most common case of using JavaConfig with Camel would be to create
+configuration with defined list of routes to be used by router.
+
+[source,java]
+--------------------------------------------------------------------
+@Configuration
+public class MyRouteConfiguration extends CamelConfiguration {
+
+ @Autowire
+ private MyRouteBuilder myRouteBuilder;
+
+ @Autowire
+ private MyAnotherRouteBuilder myAnotherRouteBuilder;
+
+ @Override
+ public List<RouteBuilder> routes() {
+ return Arrays.asList(myRouteBuilder, myAnotherRouteBuilder);
+ }
+
+}
+--------------------------------------------------------------------
+
+Starting from Camel 2.13.0 you can skip the *routes()* definition, and
+fall back to the *RouteBuilder* instances located in the Spring context.
+
+[source,java]
+--------------------------------------------------------------
+@Configuration
+@ComponentScan("com.example.routes")
+public class MyRouteConfiguration extends CamelConfiguration {
+}
+--------------------------------------------------------------
+
+[[SpringJavaConfig-Testing]]
+Testing
+^^^^^^^
+
+Since *Camel 2.11.0* you can use the `CamelSpringJUnit4ClassRunner` with
+`CamelSpringDelegatingTestContextLoader`. This is the recommended way to
+test Java Config and Camel integration.
+
+If you wish to create a collection of *RouteBuilder* instances then
+derive from the *CamelConfiguration* helper class and implement the
+*routes()* method. Keep in mind that (starting from the Camel 2.13.0) if
+you don't override *routes()* method, then *CamelConfiguration* will use
+all *RouteBuilder* instances available in the Spring context.
+
+The following
+http://svn.apache.org/repos/asf/camel/trunk/components/camel-spring-javaconfig/src/test/java/org/apache/camel/spring/javaconfig/patterns/FilterTest.java[example
+using Java Config] demonstrates how to test Java Config integration with
+Camel 2.10 and lower. Keep in mind that `JavaConfigContextLoader` is
+deprecated and could be removed in the future versions of Camel on the
+behalf of the `CamelSpringDelegatingTestContextLoader`.
+
+The *@ContextConfiguration* annotation tells the
+link:spring-testing.html[Spring Testing] framework to load the
+*ContextConfig* class as the configuration to use. This class derives
+from *SingleRouteCamelConfiguration* which is a helper Spring Java
+Config class which will configure the CamelContext for us and then
+register the RouteBuilder we create.
http://git-wip-us.apache.org/repos/asf/camel/blob/94fa14a1/components/camel-test-cdi/src/main/docs/cdi-testing.adoc
----------------------------------------------------------------------
diff --git a/components/camel-test-cdi/src/main/docs/cdi-testing.adoc b/components/camel-test-cdi/src/main/docs/cdi-testing.adoc
deleted file mode 100644
index 2b614be..0000000
--- a/components/camel-test-cdi/src/main/docs/cdi-testing.adoc
+++ /dev/null
@@ -1,749 +0,0 @@
-[[CDITesting-CDITesting]]
-CDI Testing
-~~~~~~~~~~~
-
-http://camel.apache.org/testing.html[Testing] is a crucial part of any
-development or integration work. In case you're using the Camel CDI
-integration for your applications, you have a number of options to ease
-testing.
-
-You can use CDI for IoC and the Camel testing endpoints like
-`DataSet`, `Mock`, `Test` and testing API like `AdviceWith`
-and `NotifyBuilder` to create sophisticated integration/unit tests that
-are easy to run and debug inside your IDE.
-
-There are a number of supported approaches for testing with CDI in
-Camel:
-
-[width="100%",cols="1,1,4",options="header",]
-|=======================================================================
-|Name |Testing Frameworks Supported |Description
-|<<CDITesting-CamelCDITest,Camel CDI Test>> a|
-* JUnit 4
-
- a|
-*Available as of Camel 2.17*
-
-The Camel CDI test module (`camel-test-cdi`) provides a JUnit runner
-that bootstraps a test environment using CDI so that you don't have to
-be familiar with any CDI testing frameworks and can concentrate on the
-testing logic of your Camel CDI applications.
-
-|<<CDITesting-Arquillian,Arquillian>> a|
-* JUnit 4
-* TestNG 5
-
- |http://arquillian.org/[Arquillian] is a testing platform that handles
-all the plumbing of in-container testing with support for a wide range
-of http://arquillian.org/modules/[target containers]. Arquillian can be
-configured to run your test classes in _embedded_ (in JVM CDI),
-_managed_ (a real Web server or Java EE application server instance
-started in a separate process) or _remote_ (the lifecycle of the
-container isn't managed by Arquillian) modes. You have to create the
-System Under Test (SUT) in your test classes using
-http://arquillian.org/guides/shrinkwrap_introduction/[ShrinkWrap
-descriptors]. The benefit is that you have a very fine-grained control
-over the application configuration that you want to test. The downside
-is more code and more complex _classpath_ / class loading structure.
-
-|<<CDITesting-PAXExam,PAX Exam>> a|
-* JUnit 4
-* TestNG 6
-
- |https://ops4j1.jira.com/wiki/display/PAXEXAM4[PAX Exam] lets you test
-your Camel applications in OSGi, Java EE or standalone CDI containers
-with the ability to finely configure your System Under Test (SUT),
-similarly to Arquillian. You can use it to test your Camel CDI
-applications that target OSGi environments like Karaf with
-https://ops4j1.jira.com/wiki/display/PAXCDI/Pax+CDI[PAX CDI], but you
-can use it as well to test your Camel CDI applications in standalone
-https://ops4j1.jira.com/wiki/display/PAXEXAM4/CDI+Containers[CDI
-containers],
-https://ops4j1.jira.com/wiki/display/PAXEXAM4/Web+Containers[Web
-containers] and
-https://ops4j1.jira.com/wiki/display/PAXEXAM4/Java+EE+Containers[Java EE
-containers].
-|=======================================================================
-
-[[CDITesting-CamelCDITest]]
-Camel CDI Test
-^^^^^^^^^^^^^^
-
-With this approach, your test classes use the JUnit runner provided in
-Camel CDI test. This runner manages the lifecycle of a standalone CDI
-container and automatically assemble and deploy the System Under Test
-(SUT) based on the _classpath_ into the container.
-
-It deploys the test class as a CDI bean so that dependency injection and
-any CDI features is available within the test class.
-
-Maven users will need to add the following dependency to
-their `pom.xml` for this component:
-
-[source,xml]
-----
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-test-cdi</artifactId>
- <scope>test</scope>
- <version>x.x.x</version>
- <!-- use the same version as your Camel core version -->
-</dependency>
-----
-
-Here is a simple unit test using the `CamelCdiRunner`:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- @Inject
- CamelContext context;
-
- @Test
- public void test() {
- assertThat("Camel context status is incorrect!",
- context.getStatus(),
- is(equalTo(ServiceStatus.Started)));
- }
-}
-----
-
-CDI injection is also available for test method parameters, e.g.:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- @Test
- public void test(@Uri("direct:foo") ProducerTemplate producer) {
- producer.sendBody("bar");
- }
-}
-----
-
-Camel CDI test provides the `@Order` annotation that you can use to
-execute the test methods in a particular sequence, e.g.:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- @Test
- @Order(1)
- public void firstTestMethod() {
- }
-
- @Test
- @Order(2)
- public void secondTestMethod() {
- }
-}
-----
-
-One CDI container is bootstrapped for the entire execution of the test
-class.
-
-Besides, the test class is deployed as a CDI bean, so that you can
-control how the runner instantiate the test class, either one test class
-instance for each test method (the default, depending on the _built-in_
-default `@Dependent` CDI scope), or one test class instance for the
-entire test class execution using the `@ApplicationScoped` scope, e.g.:
-
-[source,java]
-----
-@ApplicationScoped
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- int counter;
-
- @Test
- @Order(1)
- public void firstTestMethod() {
- counter++;
- }
-
- @Test
- @Order(2)
- public void secondTestMethod() {
- assertEquals(counter, 1);
- }
-}
-----
-
-In case you need to add additional test beans, you can use the `@Beans`
-annotation provided by Camel CDI test. For example, if you need to add
-a route to your Camel context, instead of declaring a `RouteBuilder` bean
-with a nested class, you can declare a managed bean, e.g.:
-
-[source,java]
-----
-class TestRoute extends RouteBuilder {
-
- @Override
- public void configure() {
- from("direct:foo").to("mock:bar");
- }
-}
-----
-
-And add it with the `@Beans` annotation, e.g.:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-@Beans(classes = TestRoute.class)
-public class CamelCdiTest {
-
-}
-----
-
-[[CDITesting-Arquillian]]
-Arquillian
-^^^^^^^^^^
-
-With this approach, you use the JUnit runner or TestNG support provided
-by Arquillian to delegate the bootstrap of the CDI container. You need
-to declare a `@Deployment` method to create your application
-configuration to be deployed in the container using
-http://arquillian.org/guides/shrinkwrap_introduction/[ShrinkWrap
-descriptors], e.g.:
-
-[source,java]
-----
-@RunWith(Arquillian.class)
-public class CamelCdiJavaSeTest {
-
- @Deployment
- public static Archive deployment() {
- return ShrinkWrap.create(JavaArchive.class)
- // Camel CDI
- .addPackage(CdiCamelExtension.class.getPackage())
- // Test classes
- .addPackage(Application.class.getPackage())
- // Bean archive deployment descriptor
- .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
- }
-
- @Inject
- CamelContext context;
-
- @Test
- public void test() {
- assertThat("Camel context status is incorrect!",
- context.getStatus(),
- is(equalTo(ServiceStatus.Started)));
- }
-}
-----
-
-In that example, you can use any Java SE Arquillian embedded container
-adapter, like the
-http://arquillian.org/modules/arquillian-weld-se-embedded-1.1-container-adapter/[Weld
-embedded container adapter] e.g. with Maven you need that complete set
-of dependencies:
-
-[source,xml]
-----
-<dependencies>
-
- <dependency>
- <groupId>org.jboss.arquillian.junit</groupId>
- <artifactId>arquillian-junit-container</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.shrinkwrap.descriptors</groupId>
- <artifactId>shrinkwrap-descriptors-depchain</artifactId>
- <type>pom</type>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.arquillian.container</groupId>
- <artifactId>arquillian-weld-se-embedded-1.1</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.weld</groupId>
- <artifactId>weld-core</artifactId>
- <scope>test</scope>
- </dependency>
-
-</dependencies>
-----
-
-Using ShrinkWarp Descriptors, you have a complete control over the
-configuration and kind of Camel CDI applications you want to test. For
-example, to test a Camel CDI application that uses the Camel
-link:rest-dsl.html[REST DSL] configured with the
-link:servlet.html[Servlet component], you need to create a Web archive,
-e.g.:
-
-[source,java]
-----
-@RunWith(Arquillian.class)
-public class CamelCdiWebTest {
-
- @Deployment
- public static Archive<?> createTestArchive() {
- return ShrinkWrap.create(WebArchive.class)
- .addClass(Application.class)
- .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"))
- .setWebXML(Paths.get("src/main/webapp/WEB-INF/web.xml").toFile());
- }
-
- @Test
- @RunAsClient
- public void test(@ArquillianResource URL url) throws Exception {
- assertThat(IOHelper.loadText(new URL(url, "camel/rest/hello").openStream()),
- is(equalTo("Hello World!\n")));
- }
-}
-----
-
-In the example above, you can use any Arquillian Web container adapter,
-like
-the http://arquillian.org/modules/arquillian-jetty-embedded-9-container-adapter/[Jetty
-embedded container adapter] e.g. with Maven you need the
-complete following set of dependencies:
-
-[source,xml]
-----
-</dependencies>
-
- <dependency>
- <groupId>org.jboss.arquillian.junit</groupId>
- <artifactId>arquillian-junit-container</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.arquillian.testenricher</groupId>
- <artifactId>arquillian-testenricher-resource</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.shrinkwrap.descriptors</groupId>
- <artifactId>shrinkwrap-descriptors-depchain</artifactId>
- <type>pom</type>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.weld.servlet</groupId>
- <artifactId>weld-servlet</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.eclipse.jetty</groupId>
- <artifactId>jetty-webapp</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.eclipse.jetty</groupId>
- <artifactId>jetty-annotations</artifactId>
- <scope>test</scope>
- </dependency>
-
- <dependency>
- <groupId>org.jboss.arquillian.container</groupId>
- <artifactId>arquillian-jetty-embedded-9</artifactId>
- <scope>test</scope>
- </dependency>
-
-</dependencies>
-----
-
-You can see the tests in the `camel-example-cdi-rest-servlet` example
-for a complete working example of testing a Camel CDI application using
-the REST DSL and deployed as a WAR in Jetty.
-
-[[CDITesting-PAXExam]]
-PAX Exam
-^^^^^^^^
-
-If you target OSGi as runtime environment for your Camel CDI
-applications, you can use PAX Exam to automate the deployment of your
-tests into an OSGi container, for example into Karaf, e.g.:
-
-[source,java]
-----
-@RunWith(PaxExam.class)
-@ExamReactorStrategy(PerClass.class)
-public class PaxCdiOsgiTest {
-
- @Configuration
- public Option[] config() throws IOException {
- return options(
- // Karaf configuration
- karafDistributionConfiguration()
- .frameworkUrl(
- maven()
- .groupId("org.apache.karaf")
- .artifactId("apache-karaf")
- .versionAsInProject()
- .type("zip"))
- .name("Apache Karaf")
- .unpackDirectory(new File("target/paxexam/unpack/")),
- // PAX CDI Weld
- features(
- maven()
- .groupId("org.ops4j.pax.cdi")
- .artifactId("pax-cdi-features")
- .type("xml")
- .classifier("features")
- .versionAsInProject(),
- "pax-cdi-weld"),
- // Karaf Camel commands
- mavenBundle()
- .groupId("your.application.groupId")
- .artifactId("your.application.artifactId")
- .versionAsInProject()
- );
- }
-
- @Inject
- private CamelContext context;
-
- @Test
- public void testContextStatus() {
- assertThat("Camel context status is incorrect!",
- context.getStatus(), equalTo(ServiceStatus.Started));
- }
-}
-----
-
-You can see the tests in the `camel-example-cdi-osgi` example for a
-complete working example of testing a Camel CDI application deployed in
-an OSGi container using PAX Exam.
-
-[[CDITesting-TestingPatterns]]
-Testing Patterns
-^^^^^^^^^^^^^^^^
-
-You can see the tests in the `camel-example-cdi-test` example for a
-thorough overview of the following testing patterns for Camel CDI
-applications.
-
-NOTE: While the patterns above are illustrated using the Camel CDI test
-module, they should equally work with Arquillian and PAX Exam unless
-otherwise stated or illustrated with a specific example.
-
-[[CDITesting-Testroutes]]
-Test routes
-+++++++++++
-
-You may want to add some Camel routes to your Camel CDI applications for
-testing purpose. For example to route some exchanges to a `MockEndpoint`
-instance. You can do that by declaring a `RouteBuilder` bean within the
-test class as you would normally do in your application code, e.g.:
-
-[source,java]
-----
-@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 {
-
- @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;
-}
-----
-
-You can find more information in <<cdi.adoc#CDI-Auto-detectingCamelroutes,auto-detecting Camel
-routes>>.
-
-In case you prefer declaring the `RouteBuilder` bean in a separate class,
-for example to share it more easily across multiple test classes, you can use
-the `@Beans` annotation to instruct Camel CDI test to deploy that class as a
-CDI bean, e.g.:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-@Beans(classes = TestRoute.class)
-public class CamelCdiTest {
-
- // ...
-}
-----
-
-[[CDITesting-Beanalternatives]]
-Bean alternatives
-+++++++++++++++++
-
-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
-behavior of the application bean.
-
-Imagine you have the following route in your application:
-
-[source,java]
-----
-public class Application {
-
- @ContextName("camel-test-cdi")
- static class Hello extends RouteBuilder {
-
- @Override
- public void configure() {
- from("direct:in").bean("bean").to("direct:out");
- }
- }
-}
-----
-
-And the corresponding bean:
-
-[source,java]
-----
-@Named("bean")
-public class Bean {
-
- public String process(@Body String body) {
- return body;
- }
-}
-----
-
-Then you can replace the bean above in your tests by declaring an
-_alternative_ bean, annotated with `@Alternative`, e.g.:
-
-[source,java]
-----
-@Alternative
-@Named("bean")
-public class AlternativeBean {
-
- public String process(@Body String body) {
- return body + " with alternative bean!";
- }
-}
-----
-
-And you need to activate (a.k.a. _select_ in CDI terminology) this
-alternative bean in your tests. If your using the `CamelCdiRunner` JUnit
-runner, you can do that with the `@Beans` annotation provided by the
-Camel CDI test module, e.g.:
-
-[source,java]
-----
-@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");
- }
- }
-}
-----
-
-If you're using Arquillian as testing framework, you need to activate the
-alternative in your deployment method, e.g.:
-
-[source,java]
-----
-@RunWith(Arquillian.class)
-public class CamelCdiTest {
-
- @Deployment
- public static Archive deployment() {
- return ShrinkWrap.create(JavaArchive.class)
- // Camel CDI
- .addPackage(CdiCamelExtension.class.getPackage())
- // Test classes
- .addPackage(Application.class.getPackage())
- // Bean archive deployment descriptor
- .addAsManifestResource(
- new StringAsset(
- Descriptors.create(BeansDescriptor.class)
- .getOrCreateAlternatives()
- .stereotype(MockAlternative.class.getName()).up()
- .exportAsString()),
- "beans.xml");
- }
-
- //...
-}
-----
-
-[[CDITesting-Camelcontextcustomization]]
-Camel context customization
-+++++++++++++++++++++++++++
-
-You may need to customize 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.:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- @Default
- @ContextName("camel-test-cdi")
- @ApplicationScoped
- static class CustomCamelContext extends DefaultCamelContext {
-
- @PostConstruct
- void customize() {
- disableJMX();
- }
- }
-}
-----
-
-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 link:cdi.html[Camel CDI component].
-
-[[CDITesting-RoutesadvisingwithadviceWith]]
-Routes advising with `adviceWith`
-+++++++++++++++++++++++++++++++++
-
-`AdviceWith` is used for testing Camel routes where you
-can _advice_ an existing route before its being tested. It allows to
-add http://camel.apache.org/intercept.html[Intercept] or _weave_ routes
-for testing purpose, for example using
-the link:mock.html[Mock] component.
-
-It is recommended to only advice routes which are not started already.
-To meet that requirement, you can use the `CamelContextStartingEvent`
-event by declaring an observer method in which you use `adviceWith` to
-add a `mock` endpoint at the end of your Camel route, e.g.:
-
-[source,java]
-----
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- 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");
- }
- });
- }
-}
-----
-
-[[CDITesting-JUnitrules]]
-JUnit rules
-+++++++++++
-
-Camel CDI test starts the CDI container after all the JUnit class rules
-have executed.
-
-That way, you can use JUnit class rules to initialize (resp. clean-up)
-resources that your test classes would require during their execution
-before the container initializes (resp. after the container has
-shutdown). For example, you could use an embedded JMS broker
-like https://activemq.apache.org/artemis/[ActiveMQ Artemis] to test your
-Camel JMS application, e.g.:
-
-[source,java]
-----
-import org.apache.activemq.artemis.jms.server.embedded.EmbeddedJMS;
-
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- @ClassRule
- public static final ExternalResource resources = new ExternalResource() {
-
- private final EmbeddedJMS jms = new EmbeddedJMS();
-
- @Override
- protected void before() throws Exception {
- jms.start();
- }
-
- @Override
- protected void after() throws Exception {
- jms.stop();
- }
- };
-
- @Inject
- @Uri("jms:destination")
- private ProducerTemplate producer;
-
- @Test
- public void sendMessage() {
- producer.sendBody("message");
- }
-}
-----
-
-Another use case is to assert the behavior of your application after it
-has shutdown. In that case, you can use the `Verifier` rule, e.g.:
-
-[source,java]
-----
-import org.junit.rules.Verifier;
-
-@RunWith(CamelCdiRunner.class)
-public class CamelCdiTest {
-
- @ClassRule
- public static Verifier verifier = new Verifier() {
-
- @Override
- protected void verify() {
- // Executes after the CDI container has shutdown
- }
- };
-}
-----
-
-[[CDITesting-SeeAlso]]
-See Also
-^^^^^^^^
-
-* link:cdi.html[CDI component]
-* http://arquillian.org[Arquillian Web site]
-* http://arquillian.org/modules/descriptors-shrinkwrap/[ShrinkWrap
-Descriptors]
-* http://arquillian.org/guides/shrinkwrap_introduction/[Creating
-Deployable Archives with ShrinkWrap]
-* https://ops4j1.jira.com/wiki/display/PAXEXAM4[PAX Exam]
http://git-wip-us.apache.org/repos/asf/camel/blob/94fa14a1/components/camel-test-cdi/src/main/docs/test-cdi.adoc
----------------------------------------------------------------------
diff --git a/components/camel-test-cdi/src/main/docs/test-cdi.adoc b/components/camel-test-cdi/src/main/docs/test-cdi.adoc
new file mode 100644
index 0000000..2b614be
--- /dev/null
+++ b/components/camel-test-cdi/src/main/docs/test-cdi.adoc
@@ -0,0 +1,749 @@
+[[CDITesting-CDITesting]]
+CDI Testing
+~~~~~~~~~~~
+
+http://camel.apache.org/testing.html[Testing] is a crucial part of any
+development or integration work. In case you're using the Camel CDI
+integration for your applications, you have a number of options to ease
+testing.
+
+You can use CDI for IoC and the Camel testing endpoints like
+`DataSet`, `Mock`, `Test` and testing API like `AdviceWith`
+and `NotifyBuilder` to create sophisticated integration/unit tests that
+are easy to run and debug inside your IDE.
+
+There are a number of supported approaches for testing with CDI in
+Camel:
+
+[width="100%",cols="1,1,4",options="header",]
+|=======================================================================
+|Name |Testing Frameworks Supported |Description
+|<<CDITesting-CamelCDITest,Camel CDI Test>> a|
+* JUnit 4
+
+ a|
+*Available as of Camel 2.17*
+
+The Camel CDI test module (`camel-test-cdi`) provides a JUnit runner
+that bootstraps a test environment using CDI so that you don't have to
+be familiar with any CDI testing frameworks and can concentrate on the
+testing logic of your Camel CDI applications.
+
+|<<CDITesting-Arquillian,Arquillian>> a|
+* JUnit 4
+* TestNG 5
+
+ |http://arquillian.org/[Arquillian] is a testing platform that handles
+all the plumbing of in-container testing with support for a wide range
+of http://arquillian.org/modules/[target containers]. Arquillian can be
+configured to run your test classes in _embedded_ (in JVM CDI),
+_managed_ (a real Web server or Java EE application server instance
+started in a separate process) or _remote_ (the lifecycle of the
+container isn't managed by Arquillian) modes. You have to create the
+System Under Test (SUT) in your test classes using
+http://arquillian.org/guides/shrinkwrap_introduction/[ShrinkWrap
+descriptors]. The benefit is that you have a very fine-grained control
+over the application configuration that you want to test. The downside
+is more code and more complex _classpath_ / class loading structure.
+
+|<<CDITesting-PAXExam,PAX Exam>> a|
+* JUnit 4
+* TestNG 6
+
+ |https://ops4j1.jira.com/wiki/display/PAXEXAM4[PAX Exam] lets you test
+your Camel applications in OSGi, Java EE or standalone CDI containers
+with the ability to finely configure your System Under Test (SUT),
+similarly to Arquillian. You can use it to test your Camel CDI
+applications that target OSGi environments like Karaf with
+https://ops4j1.jira.com/wiki/display/PAXCDI/Pax+CDI[PAX CDI], but you
+can use it as well to test your Camel CDI applications in standalone
+https://ops4j1.jira.com/wiki/display/PAXEXAM4/CDI+Containers[CDI
+containers],
+https://ops4j1.jira.com/wiki/display/PAXEXAM4/Web+Containers[Web
+containers] and
+https://ops4j1.jira.com/wiki/display/PAXEXAM4/Java+EE+Containers[Java EE
+containers].
+|=======================================================================
+
+[[CDITesting-CamelCDITest]]
+Camel CDI Test
+^^^^^^^^^^^^^^
+
+With this approach, your test classes use the JUnit runner provided in
+Camel CDI test. This runner manages the lifecycle of a standalone CDI
+container and automatically assemble and deploy the System Under Test
+(SUT) based on the _classpath_ into the container.
+
+It deploys the test class as a CDI bean so that dependency injection and
+any CDI features is available within the test class.
+
+Maven users will need to add the following dependency to
+their `pom.xml` for this component:
+
+[source,xml]
+----
+<dependency>
+ <groupId>org.apache.camel</groupId>
+ <artifactId>camel-test-cdi</artifactId>
+ <scope>test</scope>
+ <version>x.x.x</version>
+ <!-- use the same version as your Camel core version -->
+</dependency>
+----
+
+Here is a simple unit test using the `CamelCdiRunner`:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ @Inject
+ CamelContext context;
+
+ @Test
+ public void test() {
+ assertThat("Camel context status is incorrect!",
+ context.getStatus(),
+ is(equalTo(ServiceStatus.Started)));
+ }
+}
+----
+
+CDI injection is also available for test method parameters, e.g.:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ @Test
+ public void test(@Uri("direct:foo") ProducerTemplate producer) {
+ producer.sendBody("bar");
+ }
+}
+----
+
+Camel CDI test provides the `@Order` annotation that you can use to
+execute the test methods in a particular sequence, e.g.:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ @Test
+ @Order(1)
+ public void firstTestMethod() {
+ }
+
+ @Test
+ @Order(2)
+ public void secondTestMethod() {
+ }
+}
+----
+
+One CDI container is bootstrapped for the entire execution of the test
+class.
+
+Besides, the test class is deployed as a CDI bean, so that you can
+control how the runner instantiate the test class, either one test class
+instance for each test method (the default, depending on the _built-in_
+default `@Dependent` CDI scope), or one test class instance for the
+entire test class execution using the `@ApplicationScoped` scope, e.g.:
+
+[source,java]
+----
+@ApplicationScoped
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ int counter;
+
+ @Test
+ @Order(1)
+ public void firstTestMethod() {
+ counter++;
+ }
+
+ @Test
+ @Order(2)
+ public void secondTestMethod() {
+ assertEquals(counter, 1);
+ }
+}
+----
+
+In case you need to add additional test beans, you can use the `@Beans`
+annotation provided by Camel CDI test. For example, if you need to add
+a route to your Camel context, instead of declaring a `RouteBuilder` bean
+with a nested class, you can declare a managed bean, e.g.:
+
+[source,java]
+----
+class TestRoute extends RouteBuilder {
+
+ @Override
+ public void configure() {
+ from("direct:foo").to("mock:bar");
+ }
+}
+----
+
+And add it with the `@Beans` annotation, e.g.:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+@Beans(classes = TestRoute.class)
+public class CamelCdiTest {
+
+}
+----
+
+[[CDITesting-Arquillian]]
+Arquillian
+^^^^^^^^^^
+
+With this approach, you use the JUnit runner or TestNG support provided
+by Arquillian to delegate the bootstrap of the CDI container. You need
+to declare a `@Deployment` method to create your application
+configuration to be deployed in the container using
+http://arquillian.org/guides/shrinkwrap_introduction/[ShrinkWrap
+descriptors], e.g.:
+
+[source,java]
+----
+@RunWith(Arquillian.class)
+public class CamelCdiJavaSeTest {
+
+ @Deployment
+ public static Archive deployment() {
+ return ShrinkWrap.create(JavaArchive.class)
+ // Camel CDI
+ .addPackage(CdiCamelExtension.class.getPackage())
+ // Test classes
+ .addPackage(Application.class.getPackage())
+ // Bean archive deployment descriptor
+ .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
+ }
+
+ @Inject
+ CamelContext context;
+
+ @Test
+ public void test() {
+ assertThat("Camel context status is incorrect!",
+ context.getStatus(),
+ is(equalTo(ServiceStatus.Started)));
+ }
+}
+----
+
+In that example, you can use any Java SE Arquillian embedded container
+adapter, like the
+http://arquillian.org/modules/arquillian-weld-se-embedded-1.1-container-adapter/[Weld
+embedded container adapter] e.g. with Maven you need that complete set
+of dependencies:
+
+[source,xml]
+----
+<dependencies>
+
+ <dependency>
+ <groupId>org.jboss.arquillian.junit</groupId>
+ <artifactId>arquillian-junit-container</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.shrinkwrap.descriptors</groupId>
+ <artifactId>shrinkwrap-descriptors-depchain</artifactId>
+ <type>pom</type>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.arquillian.container</groupId>
+ <artifactId>arquillian-weld-se-embedded-1.1</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.weld</groupId>
+ <artifactId>weld-core</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+</dependencies>
+----
+
+Using ShrinkWarp Descriptors, you have a complete control over the
+configuration and kind of Camel CDI applications you want to test. For
+example, to test a Camel CDI application that uses the Camel
+link:rest-dsl.html[REST DSL] configured with the
+link:servlet.html[Servlet component], you need to create a Web archive,
+e.g.:
+
+[source,java]
+----
+@RunWith(Arquillian.class)
+public class CamelCdiWebTest {
+
+ @Deployment
+ public static Archive<?> createTestArchive() {
+ return ShrinkWrap.create(WebArchive.class)
+ .addClass(Application.class)
+ .addAsWebInfResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"))
+ .setWebXML(Paths.get("src/main/webapp/WEB-INF/web.xml").toFile());
+ }
+
+ @Test
+ @RunAsClient
+ public void test(@ArquillianResource URL url) throws Exception {
+ assertThat(IOHelper.loadText(new URL(url, "camel/rest/hello").openStream()),
+ is(equalTo("Hello World!\n")));
+ }
+}
+----
+
+In the example above, you can use any Arquillian Web container adapter,
+like
+the http://arquillian.org/modules/arquillian-jetty-embedded-9-container-adapter/[Jetty
+embedded container adapter] e.g. with Maven you need the
+complete following set of dependencies:
+
+[source,xml]
+----
+</dependencies>
+
+ <dependency>
+ <groupId>org.jboss.arquillian.junit</groupId>
+ <artifactId>arquillian-junit-container</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.arquillian.testenricher</groupId>
+ <artifactId>arquillian-testenricher-resource</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.shrinkwrap.descriptors</groupId>
+ <artifactId>shrinkwrap-descriptors-depchain</artifactId>
+ <type>pom</type>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.weld.servlet</groupId>
+ <artifactId>weld-servlet</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.eclipse.jetty</groupId>
+ <artifactId>jetty-webapp</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.eclipse.jetty</groupId>
+ <artifactId>jetty-annotations</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+ <dependency>
+ <groupId>org.jboss.arquillian.container</groupId>
+ <artifactId>arquillian-jetty-embedded-9</artifactId>
+ <scope>test</scope>
+ </dependency>
+
+</dependencies>
+----
+
+You can see the tests in the `camel-example-cdi-rest-servlet` example
+for a complete working example of testing a Camel CDI application using
+the REST DSL and deployed as a WAR in Jetty.
+
+[[CDITesting-PAXExam]]
+PAX Exam
+^^^^^^^^
+
+If you target OSGi as runtime environment for your Camel CDI
+applications, you can use PAX Exam to automate the deployment of your
+tests into an OSGi container, for example into Karaf, e.g.:
+
+[source,java]
+----
+@RunWith(PaxExam.class)
+@ExamReactorStrategy(PerClass.class)
+public class PaxCdiOsgiTest {
+
+ @Configuration
+ public Option[] config() throws IOException {
+ return options(
+ // Karaf configuration
+ karafDistributionConfiguration()
+ .frameworkUrl(
+ maven()
+ .groupId("org.apache.karaf")
+ .artifactId("apache-karaf")
+ .versionAsInProject()
+ .type("zip"))
+ .name("Apache Karaf")
+ .unpackDirectory(new File("target/paxexam/unpack/")),
+ // PAX CDI Weld
+ features(
+ maven()
+ .groupId("org.ops4j.pax.cdi")
+ .artifactId("pax-cdi-features")
+ .type("xml")
+ .classifier("features")
+ .versionAsInProject(),
+ "pax-cdi-weld"),
+ // Karaf Camel commands
+ mavenBundle()
+ .groupId("your.application.groupId")
+ .artifactId("your.application.artifactId")
+ .versionAsInProject()
+ );
+ }
+
+ @Inject
+ private CamelContext context;
+
+ @Test
+ public void testContextStatus() {
+ assertThat("Camel context status is incorrect!",
+ context.getStatus(), equalTo(ServiceStatus.Started));
+ }
+}
+----
+
+You can see the tests in the `camel-example-cdi-osgi` example for a
+complete working example of testing a Camel CDI application deployed in
+an OSGi container using PAX Exam.
+
+[[CDITesting-TestingPatterns]]
+Testing Patterns
+^^^^^^^^^^^^^^^^
+
+You can see the tests in the `camel-example-cdi-test` example for a
+thorough overview of the following testing patterns for Camel CDI
+applications.
+
+NOTE: While the patterns above are illustrated using the Camel CDI test
+module, they should equally work with Arquillian and PAX Exam unless
+otherwise stated or illustrated with a specific example.
+
+[[CDITesting-Testroutes]]
+Test routes
++++++++++++
+
+You may want to add some Camel routes to your Camel CDI applications for
+testing purpose. For example to route some exchanges to a `MockEndpoint`
+instance. You can do that by declaring a `RouteBuilder` bean within the
+test class as you would normally do in your application code, e.g.:
+
+[source,java]
+----
+@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 {
+
+ @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;
+}
+----
+
+You can find more information in <<cdi.adoc#CDI-Auto-detectingCamelroutes,auto-detecting Camel
+routes>>.
+
+In case you prefer declaring the `RouteBuilder` bean in a separate class,
+for example to share it more easily across multiple test classes, you can use
+the `@Beans` annotation to instruct Camel CDI test to deploy that class as a
+CDI bean, e.g.:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+@Beans(classes = TestRoute.class)
+public class CamelCdiTest {
+
+ // ...
+}
+----
+
+[[CDITesting-Beanalternatives]]
+Bean alternatives
++++++++++++++++++
+
+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
+behavior of the application bean.
+
+Imagine you have the following route in your application:
+
+[source,java]
+----
+public class Application {
+
+ @ContextName("camel-test-cdi")
+ static class Hello extends RouteBuilder {
+
+ @Override
+ public void configure() {
+ from("direct:in").bean("bean").to("direct:out");
+ }
+ }
+}
+----
+
+And the corresponding bean:
+
+[source,java]
+----
+@Named("bean")
+public class Bean {
+
+ public String process(@Body String body) {
+ return body;
+ }
+}
+----
+
+Then you can replace the bean above in your tests by declaring an
+_alternative_ bean, annotated with `@Alternative`, e.g.:
+
+[source,java]
+----
+@Alternative
+@Named("bean")
+public class AlternativeBean {
+
+ public String process(@Body String body) {
+ return body + " with alternative bean!";
+ }
+}
+----
+
+And you need to activate (a.k.a. _select_ in CDI terminology) this
+alternative bean in your tests. If your using the `CamelCdiRunner` JUnit
+runner, you can do that with the `@Beans` annotation provided by the
+Camel CDI test module, e.g.:
+
+[source,java]
+----
+@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");
+ }
+ }
+}
+----
+
+If you're using Arquillian as testing framework, you need to activate the
+alternative in your deployment method, e.g.:
+
+[source,java]
+----
+@RunWith(Arquillian.class)
+public class CamelCdiTest {
+
+ @Deployment
+ public static Archive deployment() {
+ return ShrinkWrap.create(JavaArchive.class)
+ // Camel CDI
+ .addPackage(CdiCamelExtension.class.getPackage())
+ // Test classes
+ .addPackage(Application.class.getPackage())
+ // Bean archive deployment descriptor
+ .addAsManifestResource(
+ new StringAsset(
+ Descriptors.create(BeansDescriptor.class)
+ .getOrCreateAlternatives()
+ .stereotype(MockAlternative.class.getName()).up()
+ .exportAsString()),
+ "beans.xml");
+ }
+
+ //...
+}
+----
+
+[[CDITesting-Camelcontextcustomization]]
+Camel context customization
++++++++++++++++++++++++++++
+
+You may need to customize 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.:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ @Default
+ @ContextName("camel-test-cdi")
+ @ApplicationScoped
+ static class CustomCamelContext extends DefaultCamelContext {
+
+ @PostConstruct
+ void customize() {
+ disableJMX();
+ }
+ }
+}
+----
+
+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 link:cdi.html[Camel CDI component].
+
+[[CDITesting-RoutesadvisingwithadviceWith]]
+Routes advising with `adviceWith`
++++++++++++++++++++++++++++++++++
+
+`AdviceWith` is used for testing Camel routes where you
+can _advice_ an existing route before its being tested. It allows to
+add http://camel.apache.org/intercept.html[Intercept] or _weave_ routes
+for testing purpose, for example using
+the link:mock.html[Mock] component.
+
+It is recommended to only advice routes which are not started already.
+To meet that requirement, you can use the `CamelContextStartingEvent`
+event by declaring an observer method in which you use `adviceWith` to
+add a `mock` endpoint at the end of your Camel route, e.g.:
+
+[source,java]
+----
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ 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");
+ }
+ });
+ }
+}
+----
+
+[[CDITesting-JUnitrules]]
+JUnit rules
++++++++++++
+
+Camel CDI test starts the CDI container after all the JUnit class rules
+have executed.
+
+That way, you can use JUnit class rules to initialize (resp. clean-up)
+resources that your test classes would require during their execution
+before the container initializes (resp. after the container has
+shutdown). For example, you could use an embedded JMS broker
+like https://activemq.apache.org/artemis/[ActiveMQ Artemis] to test your
+Camel JMS application, e.g.:
+
+[source,java]
+----
+import org.apache.activemq.artemis.jms.server.embedded.EmbeddedJMS;
+
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ @ClassRule
+ public static final ExternalResource resources = new ExternalResource() {
+
+ private final EmbeddedJMS jms = new EmbeddedJMS();
+
+ @Override
+ protected void before() throws Exception {
+ jms.start();
+ }
+
+ @Override
+ protected void after() throws Exception {
+ jms.stop();
+ }
+ };
+
+ @Inject
+ @Uri("jms:destination")
+ private ProducerTemplate producer;
+
+ @Test
+ public void sendMessage() {
+ producer.sendBody("message");
+ }
+}
+----
+
+Another use case is to assert the behavior of your application after it
+has shutdown. In that case, you can use the `Verifier` rule, e.g.:
+
+[source,java]
+----
+import org.junit.rules.Verifier;
+
+@RunWith(CamelCdiRunner.class)
+public class CamelCdiTest {
+
+ @ClassRule
+ public static Verifier verifier = new Verifier() {
+
+ @Override
+ protected void verify() {
+ // Executes after the CDI container has shutdown
+ }
+ };
+}
+----
+
+[[CDITesting-SeeAlso]]
+See Also
+^^^^^^^^
+
+* link:cdi.html[CDI component]
+* http://arquillian.org[Arquillian Web site]
+* http://arquillian.org/modules/descriptors-shrinkwrap/[ShrinkWrap
+Descriptors]
+* http://arquillian.org/guides/shrinkwrap_introduction/[Creating
+Deployable Archives with ShrinkWrap]
+* https://ops4j1.jira.com/wiki/display/PAXEXAM4[PAX Exam]
[2/2] camel git commit: CAMEL-10843 - very initial,
checking it in considering better than nothing
Posted by ac...@apache.org.
CAMEL-10843 - very initial, checking it in considering better than nothing
Project: http://git-wip-us.apache.org/repos/asf/camel/repo
Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/7042d7ae
Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/7042d7ae
Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/7042d7ae
Branch: refs/heads/master
Commit: 7042d7ae8a77e0fcd19405f4e99c125e58a5f1a3
Parents: 94fa14a
Author: onders86 <on...@gmail.com>
Authored: Wed Apr 12 22:21:59 2017 +0300
Committer: Andrea Cosentino <an...@gmail.com>
Committed: Thu Apr 13 08:39:29 2017 +0200
----------------------------------------------------------------------
.../src/main/docs/ribbon-component.adoc | 47 ++++++++++++++++++++
1 file changed, 47 insertions(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/camel/blob/7042d7ae/components/camel-ribbon/src/main/docs/ribbon-component.adoc
----------------------------------------------------------------------
diff --git a/components/camel-ribbon/src/main/docs/ribbon-component.adoc b/components/camel-ribbon/src/main/docs/ribbon-component.adoc
new file mode 100644
index 0000000..9a189f4
--- /dev/null
+++ b/components/camel-ribbon/src/main/docs/ribbon-component.adoc
@@ -0,0 +1,47 @@
+## Ribbon Component
+
+*Available as of Camel version 2.18*
+
+The ribbon component provides use of Netflix Ribbon for client side load balancing.
+
+Maven users will need to add the following dependency to their `pom.xml`
+for this component:
+
+[source,xml]
+------------------------------------------------------------
+<dependency>
+ <groupId>org.apache.camel</groupId>
+ <artifactId>camel-ribbon</artifactId>
+ <version>x.x.x</version>
+ <!-- use the same version as your Camel core version -->
+</dependency>
+------------------------------------------------------------
+
+This component helps applying load balancing feature at the client side
+when using ServiceCall EIP.
+
+As you can see [ServiceCall EIP](http://camel.apache.org/servicecall-eip.html), ribbon
+makes use of http component for calling the remote service. The details of different protocols
+are outlined in the EIP page.
+
+[source,java]
+---------------------------------------
+StaticServiceDiscovery servers = new StaticServiceDiscovery();
+servers.addServer("localhost", 9090);
+servers.addServer("localhost", 9091);
+
+RibbonConfiguration configuration = new RibbonConfiguration();
+RibbonLoadBalancer loadBalancer = new RibbonLoadBalancer(configuration);
+
+from("direct:start")
+ .serviceCall()
+ .name("myService")
+ .loadBalancer(loadBalancer)
+ .serviceDiscovery(servers)
+ .end()
+ .to("mock:result");
+---------------------------------------
+
+### See Also
+
+* link:http://camel.apache.org/servicecall-eip.html[ServiceCall EIP]
\ No newline at end of file