The whole camel blueprint as well as camel OSGi integration in general is kind of shoehorned on top of a non OSGi system. It works but it is a bit fragile.
Christian Am Di., 4. Dez. 2018 um 16:03 Uhr schrieb Ryan Moquin < [email protected]>: > I didn't see this thread until now, but just wanted to add that I use > blueprint with Camel all the time very successfully. There were a few > hiccups that were resolved around injecting configurations into the tests > for a specific PID, but in the testing stuff was put together nicely as > well. > > I'd be curious what specific problems you have with it since I was able to > figure it out pretty easily from the Camel documentation. > > I would however like to see some of these hurdles in general get > addressed. I'd like to see open source projects in general modularize > themselves. When I need to use one that just half-@ssed some osgi > support or no osgi support but split packages in their jars, it's quite > frustrating. I love writing code using osgi. The power you have is tough > to wield at first, but you can do some awesome stuff when you figure it out > (and workaround some of the current hurdles still be hashed out). > > Ryan > > Ryan > > On Wed, Nov 21, 2018, 1:34 PM Raymond Auge <[email protected] > wrote: > >> >> >> On Wed, Nov 21, 2018 at 11:23 AM Ranx <[email protected]> wrote: >> >>> Raymond, >>> >>> Thanks for the information. I was probably unaware of the RI because it >>> isn't listed on the Aries website >> >> >> Good point! So I did some updates to the main page [1]. I will try to >> make further updates to other pages as time permits. >> >> [1] http://aries.apache.org/ >> >> >>> and the only annotations I was aware of >>> from there were the Blueprint annotations. Also, PAX CDI has been >>> installed >>> in Fuse for some time now although in the 6.x version (Karaf 2.x) it was >>> only the RC so i refrained from using it for production code. Fuse 7 is >>> currently Karaf 4.2.x and has the 1.2 version of PAX CDI installed as a >>> default. >>> >>> I think I saw a presentation you gave at Eclipsecon Europe (on Youtube) >>> on >>> the work you were doing with CDI and OSGi/J2EE. There seemed to be a lot >>> of >>> work going on there for interoperability with J2EE and not just as OSGi. >> >> >> So there's nothing really specific to Java EE per say other than to >> ensure that OSGi CDI Integration could naturally accommodate other CDI >> Portable Extensions in a friendly, portable way. As such, integration of >> Java EE specs could be accomplished without any hacks. This model could be >> used just as easily to make your own features available to your CDI bundles. >> >> >>> For >>> me the J2EE part isn't as relevant but if the OSGi service dynamism and >>> injection and wire up work correctly that works for me. >>> >> >> Perfect, so there's nothing for you to worry about because this is the >> base model. >> >> >>> >>> Now to get Red Hat to embrace it and it'll be golden. >>> >> >> Sure, let's see what we can do! ;) >> >> - Ray >> >> >>> >>> >>> >>> -- >>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html >>> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >> > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
