David, Thanks! I was unaware of the Apache Aries CDI as separate from the PAX CDI. It’s exactly that sort of dead end I’d like to avoid. I noted too that Liferay is doing a clean room implementation of their own version of OSGi CDI but it seems to focus on bridging a J2EE and OSGi world which is also an impedance mismatch in models and one I don’t need or want to get into.
I don’t have any great difficulties with OSGi services and Blueprint. However, the biggest use cases I see personally are Blueprint with Camel and when folks use the Blueprint Camel DSL now things go sideways. Part of the issue is with the Camel documentation which stresses using Processors/Exchanges (obviously not related to OSGi at all but represent huge challenges for unit testing and are unnecessary) and when you now put OSGi services into that mix as an orthogonal concern it makes the brain hurt. If it’s just Blueprint and services, that’s rather straightforward. Blueprint for configuration management and PID resolution to your .cfg files is relatively straightforward as well. So I always have to have an eye on what is going to work with Camel and the Camel Java DSL as well as with OSGi services. And for unit testing them. Now that I’ve figured out a good way to use Mockito for unit testing in Camel Java DSL with JUnit, CamelTestSupport and CamelBlueprintTestSupport, the use of OSGi services where they make sense becomes much easier to design. It’s also easy then to export services from bundles that in turn invoke Camel routes internal to the bundles. -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
