I've written a lot of Blueprint and Blueprint Camel DSL and Blueprint bootstrapping Camel Java DSL. But the CDI with annotations is a great way to get the benefits of DS with automated internal wiring. The problem with Camel for injection is that @BeanInject and @PropertyInject are Camel specific annotations. One either has to be coupled to the Camel framework with them or revert to more antiquated XML setter/getter mechanics for injection. That gets to be quite a drag when you have multiple levels of injection of properties and beans. It's also not uncommon to create OSGi services that are not Camel based so having an injection/annotation system like CDI that is not Camel based is important.
Also, there are a lot of J2EE developers out there who understand CDI but don't know OSGi. Providing an easy bridge over is a good move. Camel Blueprint Test Support is slow and does not use an OSGi container for testing. It's OK for testing basic wire up. If one uses the Camel Java DSL that can mitigate some of the problem by permitting tests of routes via Java and the Camel Test Support which are faster and easier. Part of the issue with the Camel implementation in Blueprint is that routes are always defined in the Camel context. So any moderately complex set of routes becomes testing nightmare. By moving them to Camel Java DSL and RouteBuilders it means sub-segments can be easily tested. But it isn't always about Camel and so a universal injection mechanism based on an industry standard that works with or without Camel would be great. DS only goes half way unfortunately. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
