Antonin, Thanks, I may do that. I'm waiting for the version Fuse 6.3 to release. It is past due but getting close to where a milestone release should come out. Today they are at 900 issues closed and 22 remaining. So close. If it were farther off I'd be a bit more willing to experiment manually.
This all works great in the IDE with 2.17 and the Camel CDI runner. Once I started working with some my reaction was, "well, of course, that's the way this should all work. Why haven't we done this before?" One of those things that is obvious with 20/20 hindsight. I remember about 10 years ago when Spring introduced their annotations for autowiring and I had mixed thoughts about it. But with Camel and the simple unit testing available it makes it all so much better to work with I've little doubt about adopting it. On Tue, Aug 9, 2016 at 3:22 AM, Antonin Stefanutti <[email protected]> wrote: > Hi Brad, > > If you’re interested in OSGi and CDI, you may want to check PAX CDI > https://github.com/ops4j/org.ops4j.pax.cdi. > > There is an example available on how to use it with Camel here: > https://github.com/apache/camel/tree/master/examples/ > camel-example-cdi-osgi > > Antonin > > > On 08 Aug 2016, at 15:23, Brad Johnson <[email protected]> > wrote: > > > > Excellent. That's pretty much what I'm looking for since I recognize it > is > > a matter of evolving toward that and not needing to jump into it whole > hog. > > > > I can probably live with CamelTestSupport with out the CDI runner for the > > time being as well. Part of the problem is the underlying mechanisms > > aren't obvious to me since I've been using Spring and then Blueprint for > so > > long and I've pretty much always gone with hand wiring of internals. > > > > I'm not sure where the future is going with Blueprint, DS, SCR, CDI, > Spring > > Boot, Delta Spike, etc. but the Camel RouteBuilder will be germane in all > > situations and for now I'm using Blueprint for very basic bootstrap. > > > > While I commonly use OSGi services and export and reference them from my > > bundles, to be honest I could live without them if necessary. I mean the > > great benefit for me in using OSGi with Camel is the classloader > > segregation and ability to hide internal classes in a bundle. But I can > > always run routes between bundles to accomplish much the same thing that > > service provide and, in a way, it is more portable. > > > > But the ease of wiring that CDI provides is compelling and I'm very > excited > > about that future. > > > > On Mon, Aug 8, 2016 at 4:21 AM, Antonin Stefanutti < > [email protected]> > > wrote: > > > >> Hi Brad, > >> > >> The examples (camel-example-cdi.*) that are available in > >> https://github.com/apache/camel/tree/master/examples should work to > some > >> great extent in Camel versions prior to 2.17.0. > >> > >> As these examples concentrate on the non-advanced features and the new > >> version of Camel CDI introduced in 2.17.0 managed to be largely backward > >> compatible, these should work in prior versions with some little > adaptation. > >> > >> You can find some more details about these non backward compatible > changes > >> in https://issues.apache.org/jira/browse/CAMEL-9201 and > >> http://camel.apache.org/camel-2170-release.html. > >> > >> For testing, Camel CDI test won't be available, though you can use plain > >> Arquillian testing support. You can find more info in > >> http://camel.apache.org/cdi-testing.html. > >> > >> If that’s not enough for you to wait until Camel 2.17 / Fuse 6.3, let me > >> know and we’ll try to help you further. > >> > >> Antonin > >> > >>> On 06 Aug 2016, at 00:30, Brad Johnson <[email protected]> > >> wrote: > >>> > >>> Are there any good examples of how to use CDI with Camel before 2.17? > >>> Obviously that's a better option to go with and when the Fuse 6.3 > release > >>> hits it's first milestone that's what I'll go to but until then I can > use > >>> Camel 2.17 CDI test but have to use the older features with Fuse 6.2.1. > >>> > >>> Unless there's a patch or upgrade that does this already? > >>> > >>> Brad > >> > >> > >
