>From my experience with SCR it is the weaker side of the equation. The CDI seems to work just fine. I'd sort of looked at SCR initially as a way to manage external services, references and properties while using CDI as the internal bean and route building mechanism. But that seems a misfit right now. If Guillaume has the OSGiService annotations in then I'll have little need for SCR.
And I certainly can live without services in the short terms and use Camel routes with direct-vm calls to take care of the problem. You've answered my main concern about CDI spilling outside the classloader and allowing me to keep my implementation internal and protected especially for versioning purposes. Come to think of it I fired up a copy of 6.3.0xxx-157 from a couple of weeks ago and ran a features install of camel-cdi and this was part of the package list. So I should have known the pax-cdi was part of it. [ 294] [Active ] [ ] [ ] [ 80] CDI APIs (1.2.0) [ 295] [Active ] [ ] [ ] [ 80] OPS4J Pax Swissbox :: Tracker (1.8.2) [ 296] [Active ] [ ] [ ] [ 80] OPS4J Pax Swissbox :: Lifecycle (1.8.2) [ 297] [Active ] [ ] [ ] [ 80] OPS4J Pax CDI Extender for Bean Bundles (1.0.0.RC1) [ 298] [Active ] [ ] [ ] [ 80] OPS4J Pax CDI Bean Bundle API (1.0.0.RC1) [ 299] [Active ] [ ] [ ] [ 80] OPS4J Pax CDI Service Provider Interface (1.0.0.RC1) [ 300] [Active ] [ ] [ ] [ 80] OPS4J Pax CDI Portable Extension for OSGi (1.0.0.RC1) [ 301] [Active ] [ ] [ ] [ 50] camel-core-osgi (2.17.0.redhat-630157) [ 302] [Active ] [ ] [ ] [ 50] camel-cdi (2.17.0.redhat-630157) On Mon, Aug 22, 2016 at 10:33 AM, Antonin Stefanutti <anto...@stefanutti.fr> wrote: > Hi Brad, > > Camel CDI only works at the level of CDI beans, that is it won’t manage > RouteBuilder instances that are declared as SCR component. > > Then you can imagine having Camel CDI and SCR components collaborating > through the OSGi registry, using PAX CDI in the mix. > > That being said, Camel CDI / SCR integration is an area that still needs > some work. > > Antonin > > > On 21 Aug 2016, at 02:38, Brad Johnson <brad.john...@mediadriver.com> > wrote: > > > > I've been working a bit with both the Camel SCR and CDI lately. The CDI > is > > quite impressive and works very well. SCR I'm not so certain about yet. > > > > What I'm really unsure about is if they are compatible and can be used > > together. I don't suppose there is anything that technically keeps them > > from working together but the examples of Camel SCR use the AbstractCamel > > runner which requires a list of route builders. > > > > The Camel CDI automatically runs RouteBuilders it finds that are marked > as > > such so it might end up with two of them making two starts. > > > > Are they not supposed to be used together? > > > > Part of what makes this a real question for me know is the Kura library > as > > well. It has an OSGi way of exposing it to the world. > > > > <scr:component name="org.eclipse.kura.example.camel.MyKuraRouter" > > activate="activate" deactivate="deactivate" enabled="true" > immediate="true"> > > <implementation class="org.eclipse.kura.example.camel.MyKuraRouter"/> > > </scr:component> > > > > So it's difficult to imagine how all three of those technologies might be > > used together or if they should be used together. > > > > Any insights or thoughts or guesses are appreciated. > > Brad > >