This is an argument that I hear a lot. I’m not a Camel expert, but it really sounds as though the DSL needs some work. The whole point of a DSL is that by being domain specific it is supposed to be natural and easy. Instead it sounds as though it is forcing people into using Blueprint despite that being a “less preferred” option for some people.
Given the level of Camel integration in Karaf/Blueprint there must be someone in the community with the relevant skills to overhaul the DSL and make it fit for purpose? Best Regards, Tim > On 17 Oct 2018, at 23:46, John F. Berry <[email protected]> wrote: > > Thank you.. I was thinking of abandoning the Java DSL and ultimately going > this way, given my lack of success of "dumping it" into an OSGi container of > some sort. The rest of my shop, though, are not blueprint DSL, Camel or > Apache product savvy, so the learning curve for my coworkers will be more > disconnected than tapping into their java knowledge. > I was attempting, originally, to introduce Camel as a solution via Java DSL > to encourage its adoption. > > On Wednesday, October 17, 2018, 3:50:58 PM EDT, Jean-Baptiste Onofré > <[email protected]> wrote: > > > You can also directly use the Camel Blueprint DSL directly, just putting > your route in OSGI-INF/blueprint/route.xml: > > <blueprint> > <camelContext xmlns="http://camel.apache.org/schema/blueprint > <http://camel.apache.org/schema/blueprint>"> > <route id="foo"> > <from uri="..."/> > ... > <to uri="..."/> > </route> > </camelContext> > </blueprint> > > Regards > JB > > On 17/10/2018 21:46, Ranx wrote: > > > > You'll want to use the bundle plugin and create a blueprint.xml to bootstrap > > your Camel Java DSL. I use the Camel Java DSL all the time in Blueprint for > > a variety of reasons (testing is easier as the RouteBuilders exist without > > the camel context). I’m not sure why your Camel blueprint archetype is > > blowing up but I’d start with that first but then you’ll have to modify the > > blueprint file to add your > > > > Here's a snippet: > > > > > > <bean class="foo.bar.MyFirstRouteBuilder" id="firstRouteBuilder"/> > > <bean class="foo.bar.MySecondRouteBuilder" id="secondRouteBuilder"/> > > > > > > <camelContext > > id="document-logic-service"xmlns="http://camel.apache.org/schema/blueprint > > <http://camel.apache.org/schema/blueprint>"> > > <routeBuilder ref="firstRouteBuilder"/> > > <routeBuilder ref="secondRouteBuilder"/> > > </camelContext> > > > > The RouteBuilders can be independently unit tested then with > > CamelTestSupport outside the Blueprint container. > > > > This also allows an injection and setup to take place for your route > > builders when they are instantiated and then when the Camel context is given > > their reference. Without that step Camel and Felix/Karaf are unaware of > > their existence. > > > > If you can’t get the archetype to run and create a Camel Blueprint project > > for you, I’d Google around for a sample project that has the POM correct. > > > > Generally I'll have a features file and configuration file associated with > > the project as well so that the features repository can be added and > > installed. There may be a better way to do this with profiles in Karaf 4 but > > I'm a bit behind the times in that regard. > > > > Ranx > > > > > > > > > > -- > > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > > <http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html> > >
