Blueprint TestingAvailable as of Camel 2.10 camel-test-blueprint does only support testing one CamelContext. So if you have two or more CamelContexts in your blueprint XML files, then only the CamelContext first found is used during testing. Testing is a crucial part of any development or integration work. Camel supports the definition of Blueprint routes, but given that Blueprint is an OSGi specific technology, writing unit tests is quite difficult. This library leverages PojoSR (now Felix Connect) which provides a service registry without using a fully compliant OSGi container. This allows defining real unit tests (as opposed to integration tests using Pax Exam. Please make sure all test jars in your classpath are OSGi bundles. getBlueprintDescriptor to specify the location of the OSGi Blueprint XML file.If you have multiple OSGi Blueprint XML files, then you can specify them with a comma-separated list in the getBlueprintDescriptor method.Here's the Blueprint XML file: Classpath scanningBy default PojoSR test container scans the test classpath for all the OSGi bundles available there. All the bundles with Blueprint descriptor files will be automatically started by the test container. If you would like to prevent particular bundles from being started by the test container, override the
Setting timeout when getting CamelContextAvailable as of Camel 2.13.0/2.12.1/2.11.2
Adding services on startupAvailable as of Camel 2.11.2/2.12.0 When using To make it easier to register services on startup, such as a standalone In the example below we register a service The asService is a builder method that makes it easy to register a service with a single property. If you need more properties you can use the This allows us to use the service by calling a method on it from a Camel Bean component in a route as shown: Notice the bean endpoint uses the service name And in the route we use the FQN name:
From Camel 2.16.0, an additional The |