[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Claus Ibsen edited the page: Advanced configuration of CamelContext using Spring ... Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. RoutePolicyFactory 0..n Camel 2.14: To use a 3rd party route policy factory to create a route policy for every route. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. ... View Online Like View Changes Stop watching space Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Grzegorz Grzybek edited the page: Advanced configuration of CamelContext using Spring Comment: Info about looking up org.slf4j.Logger in Registry for log component and eip ... Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Stream caching Logging Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. ... Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling.
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Claus Ibsen edited the page: Advanced configuration of CamelContext using Spring ... Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Stream Cachingcaching Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. ... Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring
Page edited by Claus Ibsen
Changes (1)
...
| UuidGenerator | 0..1 | *Camel 2.5:* To use a 3rd part [UuidGenerator]. | | StreamCachingStrategy | 0..1 | *Camel 2.12:* To use a 3rd part [Stream Caching] strategy. |
| UnitOfWorkFactory | 0..1 | *Camel 2.13:* To use 3rd part {{UnitOfWork}} implementations created by the factory. |
And the following options have support for any number of beans defined.
...
Full Content
Advanced configuration of CamelContext using Spring
When using Spring the CamelContext can be pre configured based on defined beans in spring XML.
This wiki page documentes these features. Most of these features requires Camel 2.0.
What can be configured
The following functions can be configured:
Class resolvers
Lifecycle factories
Registry for lookup
Debugger, Tracer, Delay and UuidGenerator
Intercept
Graceful Shutdown
Stream caching
Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type
When Camel finds and uses any of these it logs at INFO level.
The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it.
Type
Number of beans
Description
PackageScanClassResolver
0..1
To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers.
ClassResolver
0..1
To use a 3rd party class resolver. More details at Pluggable Class Resolvers.
FactoryFinderResolver
0..1
To use a 3rd party factory finder.
Registry
0..1
To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry.
Debugger
0..1
To use a Debugger usually for tooling.
Tracer
0..1
To use a 3rd party Tracer.
TraceFormatter
0..1
To use a bean that has the tracing options configured.
HandleFault
0..1
To use a 3rd part fault handler to handle FAULT messages.
Delayer
0..1
To use a 3rd part Delayer.
ManagementStrategy
0..1
Camel 2.1: To use a 3rd part strategy for management, for example JMX management.
ManagementNamingStrategy
0..1
Camel 2.6: To use a 3rd part strategy for naming MBeans for management.
NodeIdFactory
0..1
Camel 2.10: To use a 3rd part node id factory.
EventFactory
0..1
Camel 2.1: To use a 3rd part event factory.
EventNotifier
0..1
Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table.
InflightRepository
0..1
Camel 2.1: To use a 3rd part inflight repository.
ShutdownStrategy
0..1
Camel 2.2: To use a 3rd part shutdown strategy.
ExecutorServiceStrategy
0..1
Camel 2.3 - 2.8.x: To use a 3rd part executor service strategy. More details at Threading Model.
ExecutorServiceManager
0..1
Camel 2.9: To use a 3rd part executor service manager. More details at Threading Model.
ThreadPoolFactory
0..1
Camel 2.9: To use a 3rd part thread pool factory. More details at Threading Model.
ProcessorFactory
0..1
Camel 2.4: To use a 3rd part processor factory.
UuidGenerator
0..1
Camel 2.5: To use a 3rd part UuidGenerator.
StreamCachingStrategy
0..1
Camel 2.12: To use a 3rd part Stream caching strategy.
UnitOfWorkFactory
0..1
Camel 2.13: To use 3rd part UnitOfWork implementations created by the factory.
And the following options have support for any number of beans defined.
Type
Number of beans
Description
InterceptStrategy
0..n
To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor.
LifecycleStrategy
0..n
Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation.
EventNotifier
0..n
Camel 2.2: To use 3rd part event notifiers.
Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name.
Using container wide interceptors
Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test.
Spring DSL
Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates:
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring Page edited by Claus Ibsen Changes (1) ... | ProcessorFactory | 0..1 | *Camel 2.4:* To use a 3rd part processor factory. | | UuidGenerator | 0..1 | *Camel 2.5:* To use a 3rd part [UuidGenerator]. | | StreamCachingStrategy | 0..1 | *Camel 2.12:* To use a 3rd part [Stream Caching] strategy. | And the following options have support for any number of beans defined. ... Full Content Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML. This wiki page documentes these features. Most of these features requires Camel 2.0. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. ManagementStrategy 0..1 Camel 2.1: To use a 3rd part strategy for management, for example JMX management. ManagementNamingStrategy 0..1 Camel 2.6: To use a 3rd part strategy for naming MBeans for management. NodeIdFactory 0..1 Camel 2.10: To use a 3rd part node id factory. EventFactory 0..1 Camel 2.1: To use a 3rd part event factory. EventNotifier 0..1 Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table. InflightRepository 0..1 Camel 2.1: To use a 3rd part inflight repository. ShutdownStrategy 0..1 Camel 2.2: To use a 3rd part shutdown strategy. ExecutorServiceStrategy 0..1 Camel 2.3 - 2.8.x: To use a 3rd part executor service strategy. More details at Threading Model. ExecutorServiceManager 0..1 Camel 2.9: To use a 3rd part executor service manager. More details at Threading Model. ThreadPoolFactory 0..1 Camel 2.9: To use a 3rd part thread pool factory. More details at Threading Model. ProcessorFactory 0..1 Camel 2.4: To use a 3rd part processor factory. UuidGenerator 0..1 Camel 2.5: To use a 3rd part UuidGenerator. StreamCachingStrategy 0..1 Camel 2.12: To use a 3rd part Stream caching strategy. And the following options have support for any number of beans defined. Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. Using container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. Spring DSL Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates: InterceptorStrategy When Camel boots up it logs at INFO level the container wide interceptors it have found: INFO CamelContextFactoryBean- Using
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring Page edited by Claus Ibsen Changes (1) ... | ManagementStrategy | 0..1 | *Camel 2.1:* To use a 3rd part strategy for [management|Camel JMX], for example JMX management. | | ManagementNamingStrategy | 0..1 | *Camel 2.6:* To use a 3rd part strategy for naming MBeans for [management|Camel JMX]. | | NodeIdFactory | 0..1 | *Camel 2.10:* To use a 3rd part node id factory. | | EventFactory | 0..1 | *Camel 2.1:* To use a 3rd part event factory. | | EventNotifier | 0..1 | *Camel 2.1:* To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table.| ... Full Content Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML. This wiki page documentes these features. Most of these features requires Camel 2.0. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. ManagementStrategy 0..1 Camel 2.1: To use a 3rd part strategy for management, for example JMX management. ManagementNamingStrategy 0..1 Camel 2.6: To use a 3rd part strategy for naming MBeans for management. NodeIdFactory 0..1 Camel 2.10: To use a 3rd part node id factory. EventFactory 0..1 Camel 2.1: To use a 3rd part event factory. EventNotifier 0..1 Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table. InflightRepository 0..1 Camel 2.1: To use a 3rd part inflight repository. ShutdownStrategy 0..1 Camel 2.2: To use a 3rd part shutdown strategy. ExecutorServiceStrategy 0..1 Camel 2.3 - 2.8.x: To use a 3rd part executor service strategy. More details at Threading Model. ExecutorServiceManager 0..1 Camel 2.9: To use a 3rd part executor service manager. More details at Threading Model. ThreadPoolFactory 0..1 Camel 2.9: To use a 3rd part thread pool factory. More details at Threading Model. ProcessorFactory 0..1 Camel 2.4: To use a 3rd part processor factory. UuidGenerator 0..1 Camel 2.5: To use a 3rd part UuidGenerator. And the following options have support for any number of beans defined. Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. Using container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. Spring DSL !-- here we define a spring bean that is our container wide interceptor its important to notice that the class ContainerWideInterceptor implements org.apache.camel.spi.InterceptStrategy that allows us to plugin our
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring Page edited by Claus Ibsen Changes (1) ... | ShutdownStrategy | 0..1 | *Camel 2.2:* To use a 3rd part shutdown strategy. | | ExecutorServiceStrategy | 0..1 | *Camel 2.3:* To use a 3rd part executor service strategy. More details at [Threading Model]. | | ExecutorServiceManager | 0..1 | *Camel 2.9:* To use a 3rd part executor service manager. More details at [Threading Model]. | | ThreadPoolFactory | 0..1 | *Camel 2.9:* To use a 3rd part thread pool factory. More details at [Threading Model]. | | ProcessorFactory | 0..1 | *Camel 2.4:* To use a 3rd part processor factory. | | UuidGenerator | 0..1 | *Camel 2.5:* To use a 3rd part [UuidGenerator]. | ... Full Content Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML. This wiki page documentes these features. Most of these features requires Camel 2.0. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. ManagementStrategy 0..1 Camel 2.1: To use a 3rd part strategy for management, for example JMX management. ManagementNamingStrategy 0..1 Camel 2.6: To use a 3rd part strategy for naming MBeans for management. EventFactory 0..1 Camel 2.1: To use a 3rd part event factory. EventNotifier 0..1 Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table. InflightRepository 0..1 Camel 2.1: To use a 3rd part inflight repository. ShutdownStrategy 0..1 Camel 2.2: To use a 3rd part shutdown strategy. ExecutorServiceStrategy 0..1 Camel 2.3: To use a 3rd part executor service strategy. More details at Threading Model. ExecutorServiceManager 0..1 Camel 2.9: To use a 3rd part executor service manager. More details at Threading Model. ThreadPoolFactory 0..1 Camel 2.9: To use a 3rd part thread pool factory. More details at Threading Model. ProcessorFactory 0..1 Camel 2.4: To use a 3rd part processor factory. UuidGenerator 0..1 Camel 2.5: To use a 3rd part UuidGenerator. And the following options have support for any number of beans defined. Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. Using container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. Spring DSL !-- here we define a spring bean that is our container wide interceptor its important to notice that the class ContainerWideInterceptor implements org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring Page edited by Claus Ibsen Changes (1) ... | InflightRepository | 0..1 | *Camel 2.1:* To use a 3rd part inflight repository. | | ShutdownStrategy | 0..1 | *Camel 2.2:* To use a 3rd part shutdown strategy. | | ExecutorServiceStrategy | 0..1 | *Camel 2.3 - 2.8.x:* To use a 3rd part executor service strategy. More details at [Threading Model]. | | ExecutorServiceManager | 0..1 | *Camel 2.9:* To use a 3rd part executor service manager. More details at [Threading Model]. | | ThreadPoolFactory | 0..1 | *Camel 2.9:* To use a 3rd part thread pool factory. More details at [Threading Model]. | ... Full Content Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML. This wiki page documentes these features. Most of these features requires Camel 2.0. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. ManagementStrategy 0..1 Camel 2.1: To use a 3rd part strategy for management, for example JMX management. ManagementNamingStrategy 0..1 Camel 2.6: To use a 3rd part strategy for naming MBeans for management. EventFactory 0..1 Camel 2.1: To use a 3rd part event factory. EventNotifier 0..1 Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table. InflightRepository 0..1 Camel 2.1: To use a 3rd part inflight repository. ShutdownStrategy 0..1 Camel 2.2: To use a 3rd part shutdown strategy. ExecutorServiceStrategy 0..1 Camel 2.3 - 2.8.x: To use a 3rd part executor service strategy. More details at Threading Model. ExecutorServiceManager 0..1 Camel 2.9: To use a 3rd part executor service manager. More details at Threading Model. ThreadPoolFactory 0..1 Camel 2.9: To use a 3rd part thread pool factory. More details at Threading Model. ProcessorFactory 0..1 Camel 2.4: To use a 3rd part processor factory. UuidGenerator 0..1 Camel 2.5: To use a 3rd part UuidGenerator. And the following options have support for any number of beans defined. Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. Using container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. Spring DSL !-- here we define a spring bean that is our container wide interceptor its important to notice that the class ContainerWideInterceptor implements org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors Camel will at startup automatic look for any beans in
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring Page edited by Claus Ibsen Changes (1) ... | InflightRepository | 0..1 | *Camel 2.1:* To use a 3rd part inflight repository. | | ShutdownStrategy | 0..1 | *Camel 2.2:* To use a 3rd part shutdown strategy. | | ExecutorServiceStrategy | 0..1 | *Camel 2.3:* To use a 3rd part executor service strategy. More details at [Threading Model]. | | ProcessorFactory | 0..1 | *Camel 2.4:* To use a 3rd part processor factory. | | UuidGenerator | 0..1 | *Camel 2.5:* To use a 3rd part [UuidGenerator]. | ... Full Content Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML. This wiki page documentes these features. Most of these features requires Camel 2.0. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. ManagementStrategy 0..1 Camel 2.1: To use a 3rd part strategy for management, for example JMX management. EventFactory 0..1 Camel 2.1: To use a 3rd part event factory. EventNotifier 0..1 Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table. InflightRepository 0..1 Camel 2.1: To use a 3rd part inflight repository. ShutdownStrategy 0..1 Camel 2.2: To use a 3rd part shutdown strategy. ExecutorServiceStrategy 0..1 Camel 2.3: To use a 3rd part executor service strategy. More details at Threading Model. ProcessorFactory 0..1 Camel 2.4: To use a 3rd part processor factory. UuidGenerator 0..1 Camel 2.5: To use a 3rd part UuidGenerator. And the following options have support for any number of beans defined. Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. Using container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. Spring DSL !-- here we define a spring bean that is our container wide interceptor its important to notice that the class ContainerWideInterceptor implements org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors Camel will at startup automatic look for any beans in spring registry that is an instance of org.apache.camel.spi.InterceptStrategy and add it as interceptor to all its routes. Using this we are capable of defining container wide interceptors that gets used in all camel contests we define with spring -- bean id="myInterceptor" class="org.apache.camel.spring.interceptor.ContainerWideInterceptor"/ !-- here we have the 1st CamelContext -- camelContext id="camel1" xmlns="http://camel.apache.org/schema/spring"
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring Page edited by Christian Mueller Comment: added description for the UuidGenerator Changes (2) ... - Lifecycle factories - Registry for lookup - [Debugger], [Tracer] and [Tracer], [Delay|Delay Interceptor] and [UuidGenerator] - [Intercept] - [Graceful Shutdown] ... | ShutdownStrategy | 0..1 | *Camel 2.2:* To use a 3rd part shutdown strategy. | | ProcessorFactory | 0..1 | *Camel 2.4:* To use a 3rd part processor factory. | | UuidGenerator | 0..1 | *Camel 2.5:* To use a 3rd part [UuidGenerator]. | And the following options have support for any number of beans defined. ... Full Content Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML. This wiki page documentes these features. Most of these features requires Camel 2.0. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer, Delay and UuidGenerator Intercept Graceful Shutdown Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers. ClassResolver 0..1 To use a 3rd party class resolver. More details at Pluggable Class Resolvers. FactoryFinderResolver 0..1 To use a 3rd party factory finder. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. ManagementStrategy 0..1 Camel 2.1: To use a 3rd part strategy for management, for example JMX management. EventFactory 0..1 Camel 2.1: To use a 3rd part event factory. EventNotifier 0..1 Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table. InflightRepository 0..1 Camel 2.1: To use a 3rd part inflight repository. ShutdownStrategy 0..1 Camel 2.2: To use a 3rd part shutdown strategy. ProcessorFactory 0..1 Camel 2.4: To use a 3rd part processor factory. UuidGenerator 0..1 Camel 2.5: To use a 3rd part UuidGenerator. And the following options have support for any number of beans defined. Type Number of beans Description InterceptStrategy 0..n To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. LifecycleStrategy 0..n Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation. EventNotifier 0..n Camel 2.2: To use 3rd part event notifiers. Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name. Using container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. Spring DSL !-- here we define a spring bean that is our container wide interceptor its important to notice that the class ContainerWideInterceptor implements org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors Camel will at startup automatic look for any beans in spring registry that is an instance of org.apache.camel.spi.InterceptStrategy and add it as interceptor to all its routes. Using this we are capable of defining container wide interceptors that gets used in all camel contests we define with spring -- bean id="myInterceptor" class="org.apache.camel.spring.interceptor.ContainerWideInterceptor"/ !-- here we have the 1st CamelContext -- camelContext id="camel1"
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring
Page edited by Claus Ibsen
Advanced configuration of CamelContext using Spring
When using Spring the CamelContext can be pre configured based on defined beans in spring XML.
This wiki page documentes these features. Most of these features requires Camel 2.0.
What can be configured
The following functions can be configured:
Class resolvers
Lifecycle factories
Registry for lookup
Debugger, Tracer and Delay
Intercept
Graceful Shutdown
Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type
When Camel finds and uses any of these it logs at INFO level.
The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it.
Type
Number of beans
Description
PackageScanClassResolver
0..1
To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers.
ClassResolver
0..1
To use a 3rd party class resolver. More details at Pluggable Class Resolvers.
FactoryFinderResolver
0..1
To use a 3rd party factory finder.
Registry
0..1
To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry.
Debugger
0..1
To use a Debugger usually for tooling.
Tracer
0..1
To use a 3rd party Tracer.
TraceFormatter
0..1
To use a bean that has the tracing options configured.
HandleFault
0..1
To use a 3rd part fault handler to handle FAULT messages.
Delayer
0..1
To use a 3rd part Delayer.
ManagementStrategy
0..1
Camel 2.1: To use a 3rd part strategy for management, for example JMX management.
EventFactory
0..1
Camel 2.1: To use a 3rd part event factory.
EventNotifier
0..1
Camel 2.1: To use a 3rd part event notifier. In Camel 2.2 onwards you can have multiple notifiers, see next table.
InflightRepository
0..1
Camel 2.1: To use a 3rd part inflight repository.
ShutdownStrategy
0..1
Camel 2.2: To use a 3rd part shutdown strategy.
And the following options have support for any number of beans defined.
Type
Number of beans
Description
InterceptStrategy
0..n
To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor.
LifecycleStrategy
0..n
Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation.
EventNotifier
0..n
Camel 2.2: To use 3rd part event notifiers.
Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name.
Using container wide interceptors
Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test.
Spring DSL
!-- here we define a spring bean that is our container wide interceptor
its important to notice that the class ContainerWideInterceptor implements
org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors
Camel will at startup automatic look for any beans in spring registry that is an
instance of org.apache.camel.spi.InterceptStrategy and add it as interceptor
to all its routes. Using this we are capable of defining container wide interceptors
that gets used in all camel contests we define with spring --
bean id="myInterceptor" class="org.apache.camel.spring.interceptor.ContainerWideInterceptor"/
!-- here we have the 1st CamelContext --
camelContext id="camel1" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:one"/
to uri="mock:result"/
/route
/camelContext
!-- and there we have the 2nd CamelContext --
camelContext id="camel2" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:two"/
to uri="log:two"/
to uri="mock:result"/
/route
/camelContext
Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates:
InterceptorStrategy
public class ContainerWideInterceptor implements InterceptStrategy {
private static final transient Log LOG = LogFactory.getLog(ContainerWideInterceptor.class);
private static int count;
public Processor wrapProcessorInInterceptors(final CamelContext context, final ProcessorDefinition definition,
final Processor target, final Processor nextTarget)
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring
Page edited by Claus Ibsen
Advanced configuration of CamelContext using Spring
When using Spring the CamelContext can be pre configured based on defined beans in spring XML.
This wiki page documentes these features. Most of these features requires Camel 2.0.
What can be configured
The following functions can be configured:
Class resolvers
Lifecycle factories
Registry for lookup
Debugger, Tracer and Delay
Intercept
Graceful Shutdown
Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type
When Camel finds and uses any of these it logs at INFO level.
The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it.
Type
Number of beans
Description
PackageScanClassResolver
0..1
To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers.
ClassResolver
0..1
To use a 3rd party class resolver. More details at Pluggable Class Resolvers.
FactoryFinderResolver
0..1
To use a 3rd party factory finder.
Registry
0..1
To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry.
Debugger
0..1
To use a Debugger usually for tooling.
Tracer
0..1
To use a 3rd party Tracer.
TraceFormatter
0..1
To use a bean that has the tracing options configured.
HandleFault
0..1
To use a 3rd part fault handler to handle FAULT messages.
Delayer
0..1
To use a 3rd part Delayer.
ManagementStrategy
0..1
Camel 2.1: To use a 3rd part strategy for management, for example JMX management.
EventFactory
0..1
Camel 2.1: To use a 3rd part event factory.
EventNotifier
0..1
Camel 2.1: To use a 3rd part event notifier.
InflightRepository
0..1
Camel 2.1: To use a 3rd part inflight repository.
ShutdownStrategy
0..1
Camel 2.2: To use a 3rd part shutdown strategy.
And the following options have support for any number of beans defined.
Type
Number of beans
Description
InterceptStrategy
0..n
To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor.
LifecycleStrategy
0..n
Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation.
Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name.
Using container wide interceptors
Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test.
Spring DSL
!-- here we define a spring bean that is our container wide interceptor
its important to notice that the class ContainerWideInterceptor implements
org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors
Camel will at startup automatic look for any beans in spring registry that is an
instance of org.apache.camel.spi.InterceptStrategy and add it as interceptor
to all its routes. Using this we are capable of defining container wide interceptors
that gets used in all camel contests we define with spring --
bean id="myInterceptor" class="org.apache.camel.spring.interceptor.ContainerWideInterceptor"/
!-- here we have the 1st CamelContext --
camelContext id="camel1" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:one"/
to uri="mock:result"/
/route
/camelContext
!-- and there we have the 2nd CamelContext --
camelContext id="camel2" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:two"/
to uri="log:two"/
to uri="mock:result"/
/route
/camelContext
Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates:
InterceptorStrategy
public class ContainerWideInterceptor implements InterceptStrategy {
private static final transient Log LOG = LogFactory.getLog(ContainerWideInterceptor.class);
private static int count;
public Processor wrapProcessorInInterceptors(final CamelContext context, final ProcessorDefinition definition,
final Processor target, final Processor nextTarget) throws Exception {
// as this is based on an unit test we are a bit lazy and just create an inlined processor
// where we
[CONF] Apache Camel Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring
Page edited by Claus Ibsen
Advanced configuration of CamelContext using Spring
When using Spring the CamelContext can be pre configured based on defined beans in spring XML.
This wiki page documentes these features. Most of these features requires Camel 2.0.
What can be configured
The following functions can be configured:
Class resolvers
Lifecycle factories
Registry for lookup
Debugger, Tracer and Delay
Intercept
Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type
When Camel finds and uses any of these it logs at INFO level.
The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it.
Type
Number of beans
Description
PackageScanClassResolver
0..1
To use a 3rd party package scan resolver. More details at Pluggable Class Resolvers.
ClassResolver
0..1
To use a 3rd party class resolver. More details at Pluggable Class Resolvers.
FactoryFinderResolver
0..1
To use a 3rd party factory finder.
Registry
0..1
To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry.
Debugger
0..1
To use a Debugger usually for tooling.
Tracer
0..1
To use a 3rd party Tracer.
TraceFormatter
0..1
To use a bean that has the tracing options configured.
HandleFault
0..1
To use a 3rd part fault handler to handle FAULT messages.
Delayer
0..1
To use a 3rd part Delayer.
ManagementStrategy
0..1
Camel 2.1: To use a 3rd part strategy for management, for example JMX management.
EventFactory
0..1
Camel 2.1: To use a 3rd part event factory.
EventNotifier
0..1
Camel 2.1: To use a 3rd part event notifier.
InflightRepository
0..1
Camel 2.1: To use a 3rd part inflight repository.
And the following options have support for any number of beans defined.
Type
Number of beans
Description
InterceptStrategy
0..n
To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor.
LifecycleStrategy
0..n
Camel 2.1: To use 3rd party lifecycle strategies. By default Camel uses a JMX aware that does JMX instrumentation.
Camel will log at INFO level if it pickup and uses a custom bean using org.apache.camel.spring.CamelContextFactoryBean as name.
Using container wide interceptors
Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test.
Spring DSL
!-- here we define a spring bean that is our container wide interceptor
its important to notice that the class ContainerWideInterceptor implements
org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors
Camel will at startup automatic look for any beans in spring registry that is an
instance of org.apache.camel.spi.InterceptStrategy and add it as interceptor
to all its routes. Using this we are capable of defining container wide interceptors
that gets used in all camel contests we define with spring --
bean id="myInterceptor" class="org.apache.camel.spring.interceptor.ContainerWideInterceptor"/
!-- here we have the 1st CamelContext --
camelContext id="camel1" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:one"/
to uri="mock:result"/
/route
/camelContext
!-- and there we have the 2nd CamelContext --
camelContext id="camel2" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:two"/
to uri="log:two"/
to uri="mock:result"/
/route
/camelContext
Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates:
InterceptorStrategy
public class ContainerWideInterceptor implements InterceptStrategy {
private static final transient Log LOG = LogFactory.getLog(ContainerWideInterceptor.class);
private static int count;
public Processor wrapProcessorInInterceptors(final CamelContext context, final ProcessorDefinition definition,
final Processor target, final Processor nextTarget) throws Exception {
// as this is based on an unit test we are a bit lazy and just create an inlined processor
// where we implement our interception logic.
return new Processor() {
public void
[CONF] Apache Camel: Advanced configuration of CamelContext using Spring (page edited)
Page Edited : CAMEL : Advanced configuration of CamelContext using Spring Advanced configuration of CamelContext using Spring has been edited by Claus Ibsen (Jun 12, 2009). (View changes) Content: Advanced configuration of CamelContext using Spring When using Spring the CamelContext can be pre configured based on defined beans in spring XML and/or system properties. This wiki page documentes these features. What can be configured The following functions can be configured: Class resolvers Lifecycle factories Registry for lookup Debugger, Tracer and Delay Intercept Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type When Camel finds and uses any of these it logs at INFO level. The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it. Type Number of beans Description PackageScanClassResolver 0..1 To use a 3rd party package scan resolver. More details at . ClassResolver 0..1 To use a 3rd party class resolver. More details at . FactoryFinderResolver 0..1 To use a 3rd party factory finder. LifecycleStrategy 0..1 To use a 3rd party lifecycle strategy. By default Camel uses a JMX aware that does JMX instrumentation. Registry 0..1 To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry. Debugger 0..1 To use a Debugger usually for tooling. Tracer 0..1 To use a 3rd party Tracer. TraceFormatter 0..1 To use a bean that has the tracing options configured. HandleFault 0..1 To use a 3rd part fault handler to handle FAULT messages. Delayer 0..1 To use a 3rd part Delayer. And the following options have support for any number of beans defined. InterceptStrategy 0..n To use your own Interceptor that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor. Adding container wide interceptors Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test. TODO: snippet XML e1 Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates: TODO: snippet java e1 See Also Using Spring Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[CONF] Apache Camel: Advanced configuration of CamelContext using Spring (page edited)
Page Edited :
CAMEL :
Advanced configuration of CamelContext using Spring
Advanced configuration of CamelContext using Spring
has been edited by Claus Ibsen
(Jun 12, 2009).
(View changes)
Content:
Advanced configuration of CamelContext using Spring
When using Spring the CamelContext can be pre configured based on defined beans in spring XML and/or system properties.
This wiki page documentes these features.
What can be configured
The following functions can be configured:
Class resolvers
Lifecycle factories
Registry for lookup
Debugger, Tracer and Delay
Intercept
Camel will configure these functions by doing a lookup in the Spring bean registry to find beans of the given type
When Camel finds and uses any of these it logs at INFO level.
The following list all requires at most 1 beans defined. If there are more than 1 bean of this type, then Camel will not use it.
Type
Number of beans
Description
PackageScanClassResolver
0..1
To use a 3rd party package scan resolver. More details at Pluggable Class Resolver.
ClassResolver
0..1
To use a 3rd party class resolver. More details at Pluggable Class Resolvers.
FactoryFinderResolver
0..1
To use a 3rd party factory finder.
LifecycleStrategy
0..1
To use a 3rd party lifecycle strategy. By default Camel uses a JMX aware that does JMX instrumentation.
Registry
0..1
To use a 3rd party bean registry. By default Camel will use Spring ApplicationContext as registry.
Debugger
0..1
To use a Debugger usually for tooling.
Tracer
0..1
To use a 3rd party Tracer.
TraceFormatter
0..1
To use a bean that has the tracing options configured.
HandleFault
0..1
To use a 3rd part fault handler to handle FAULT messages.
Delayer
0..1
To use a 3rd part Delayer.
And the following options have support for any number of beans defined.
Type
Number of beans
Description
InterceptStrategy
0..n
To use your own Intercept that intercepts every processing steps in all routes in the CamelContext. For instance you can use this to do an AOP like performance timer interceptor.
Using container wide interceptors
Imagine that you have multiple CamelContext and you want to configure that they all use the same container wide interceptor. How do we do that? Well we can leverage the fact that Camel can auto detect and use custom interceptors. So what we simply do is to define our interceptor in the spring xml file. The sample below does this and also define 2 camel contexts. The sample is based on unit test.
!-- here we define a spring bean that is our container wide interceptor
its important to notice that the class ContainerWideInterceptor implements
org.apache.camel.spi.InterceptStrategy that allows us to plugin our interceptors
Camel will at startup automatic look for any beans in spring registry that is an
instance of org.apache.camel.spi.InterceptStrategy and add it as interceptor
to all its routes. Using this we are capable of defining container wide interceptors
that gets used in all camel contests we define with spring --
bean id="myInterceptor" class="org.apache.camel.spring.interceptor.ContainerWideInterceptor"/
!-- here we have the 1st CamelContext --
camelContext id="camel1" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:one"/
to uri="mock:result"/
/route
/camelContext
!-- and there we have the 2nd CamelContext --
camelContext id="camel2" xmlns="http://camel.apache.org/schema/spring"
route
from uri="direct:two"/
to uri="log:two"/
to uri="mock:result"/
/route
/camelContext
Okay lets build our interceptor to simply count the number of interceptions. This is quite easy as we can just implement this logic in our implementation directly as the code below illustrates:
public class ContainerWideInterceptor implements InterceptStrategy {
private static final transient Log LOG = LogFactory.getLog(ContainerWideInterceptor.class);
private static int count;
public Processor wrapProcessorInInterceptors(final ProcessorDefinition processorDefinition,
final Processor target, final Processor nextTarget) throws Exception {
// as this is based on an unit test we are a bit lazy and just create an inlined processor
// where we implement our interception logic.
return new Processor() {
public void process(Exchange exchange) throws Exception {
// we just count number of interceptions
count++;
LOG.info("I am the container wide interceptor. Intercepted total count: " + count);
// its important that we delegate to the real target so we let target process the exchange
