You can successfully use both the XML/BluePrint DSL or the Java DSL from Karaf. In my experience testing the XML DSL is hard - so I wouldn't use blueprint. I put together a very simple example of using the Java DSL, in an OSGi environment at https://github.com/paul-mcculloch/camel-karaf-noblueprint which shows how simple it can be - a simple POM & one class.
Having said that, I do question the need for Karaf in your specific situation. If you just need to run some Camel routes as a Windows service then using Karaf is something of a sledgehammer to crack quite a small nut. The Camel docs include an example of a long running application - http://camel.apache.org/running-camel-standalone-and-have-it-keep-running.html . Another alternative that could be a better fit is Spring - that's what I used before moving to Karaf. If you want to run that as a service then just use something like https://wrapper.tanukisoftware.com (which is what Karaf bundles I think) or http://yajsw.sourceforge.net/ (I've not tried this one). On Thu, 18 Oct 2018 at 18:43, Ranx <[email protected]> wrote: > 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 >
