Historically, I started using pure blueprint camel routes, then moved to the Java DSL + blueprint to manage the beans, and now I'm working on migrating to using DS instead of blueprint for managing the beans/components/services as well. Since you'll be running on OSGi, you should know some caveats to using blueprint:
1. Blueprint hasn't had any updates to the standard in a while. While there are some blueprint extensions in Apache Aries, these are nonstandard. 2. In the future, Spring XML will be interpreted into a blueprint container (another Aries feature), so if you're choosing between the two, you might as well stick with blueprint. 3. Most active OSGi development on dependency injection is based on DS (declarative services, AKA the service component runtime). 4. If you made a mistake in your blueprint file, you'll get a pretty useless exception and stacktrace when your bundle attempts to activate. This isn't specific to blueprint, but it specific to the implementation of blueprint you're using. On 27 April 2016 at 12:39, Quinn Stevenson <qu...@pronoia-solutions.com> wrote: > In the implementations I’ve done, we use a mix of Java DSL and Blueprint. > We have some common RouteBuilders, and we use Blueprint to configure them > and wire them into a Camel Context. It’s worked very well for us. > > We’ve done some similar things using camel-scr, but the configuration got > a bit messy - we had to create 3 or 4 properties/cfg files to get a single > route going and it was a little more difficult to diagnose configuration > errors. > > > On Apr 27, 2016, at 11:13 AM, Matt Pavlovich <mattr...@gmail.com> wrote: > > > > I agree with Brad's points and if you asked 100 people you'd probably > get a fairly even mix of preferences. I would favor Blueprint over Spring. > > > > I've been helping organizations adopt Camel for 8+ years and have > generally found blueprint to be the best mix for long term support and > ramp-up of junior and mid-level resources. I tend to see the Java DSL > preference in Sr resources and folks doing really complex tasks. > > > > Additionally, I find a fully loaded route with configuration, error > handling, data sources, logging can be complicated for junior and mid-level > resources to grok when they are gearing up. Additionally, sharing data > sources and services via OSGi is super handy, and an efficient transition > for folks coming from Spring / JEE concepts. > > > > I do think that the biggest gain to be had is being standardized across > the organization vs figuring out which has some minor benefit or trade-off. > > > > My $0.02 > > > > On 4/27/16 11:55 AM, Brad Johnson wrote: > >> I use blueprint, never use the graphical editor, and use quite a few > Java > >> classes anyway. One benefit to using Java classes is you can unit test > >> them directly with JUnit. > >> > >> To me the biggest benefit in the XML and blueprint are (a) easy > >> configuration of endpoints, (b) management of OSGi services, (c) some > easy > >> ways to invoke EIPs on routes when the XML is easier to use. I never > use > >> the Java DSL but will commonly inject endpoints into my Java classes. > >> > >> Everyone is different. I think Claus pretty exclusively uses Java > DSL. It > >> isn't a right thing or a wrong thing. As a team you obviously have to > >> decide. If you are running in Fuse you'll most likely at least > bootstrap > >> your bundles from blueprint even if you do use the Java DSLs. > >> > >> > >> On Wed, Apr 27, 2016 at 10:27 AM, NikheelRanjan < > nikheel.ran...@gmail.com> > >> wrote: > >> > >>> The question is which one of the DSL implementation you want to use > when > >>> you > >>> are going to use camel+jboss fuse based implementation. My points are: > >>> 1.Blueprints(similar to spring DM) are best supported in osgi based > >>> environments. > >>> 2. XML s not only reduce the number of classes but also if working in > jboss > >>> dev studio gives you a chance to graphically design your routes through > >>> visual editor. > >>> 3.Configuration in XML never requires recompilation and can be easily > >>> understood by any person who understands the basics of xml. > >>> 4.At runtime its all on camel based components irrespective of java > DSL or > >>> spring DSL. > >>> > >>> My concerns: > >>> Does using xmls/spring DSLs really give you any maintenance problems? > Does > >>> choice of DSL really matter or it just depends upon the > >>> developers/technical > >>> team's capability to find the comfort-ability? Please give your points > as > >>> we > >>> have two groups in teams where one group is supporting java DSL other > is > >>> SPRING based one. > >>> > >>> > >>> > >>> -- > >>> View this message in context: > >>> > http://camel.465427.n5.nabble.com/Blueprint-Spring-DSL-vs-JAVA-DSL-tp5781807.html > >>> Sent from the Camel - Users mailing list archive at Nabble.com. > >>> > > > > -- Matt Sicker <boa...@gmail.com>
