Absolutely, do use the Camel Java DSL even when you bootstrap with Blueprint. Write unit tests using CamelTestSupport and only sparingly use the CamelBlueprintTestSupport. Avoid Processors/Exchanges and use plain pojo handlers instead. Camel uses reflection on any bean it finds in the path and will automatically invoke the correct method on your handler based on assignment of class type. This means you can use simple JUnit tests on your handlers. The Camel in Action book recommends that but they don’t get to it until over 100 pages in and then it’s in the form of a set of bullet points in the conclusion of the chapter. If you follow those practices it will make it very easy for Java developers to use OSGi and Blueprint as Blueprint will only be used for configuration and not for coding.
The issue you’re running into is almost certainly related to not using the Maven bundle plugin which generates the Manifest automatically. Essentially the plugin reads your code and your Blueprint file and figures out what dependencies it needs, what to import and what to export, and writes that Manifest for you. The OSGi container reads that Manifest to figure out how to bootstrap everything. The route builder references I show below will then boot it up correctly. Using the Java DSL means your code and your knowledgebase is domain neutral. In other words, your code, tests and skills are as applicable to standalone applications as to Karaf or Spring Boot or J2EE. Blueprint XML Camel routes are specific to Blueprint so just avoid them. Eventually you’ll want to look at features files for installing all your dependencies at start up including the configuration files. If you can get the Camel Blueprint archetype to run, then you should have everything you need and just use the route builder reference mechanism I showed below and it will work like a champ. This is one of those places where we really do need an “opinionated” SpringBoot style of coding practices. It’s usually pretty easy to justify these practices because they result in easily unit tested code that Java developers understand. Using Camel Blueprint DSL and XML and Processors/Exchanges always, in my experience, leads to code that has zero unit tests associated with it. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
