We’ve been running routes based on camel-scr in production for a few months now (Fuse 6.2 patch 1), and it’s been working pretty well. We use the SCR routes as templates, and then create instances with configuration files (cfg files in Karaf, properties files in Fabric8).
The biggest issues we have in production are: - The Karaf camel:* command don’t work - We can’t run multiple versions of our SCR templates at the same time - makes staging releases difficult. This isn’t really an issue with camel-scr - it’s because of the way we implemented it. The PIDs are the same for each version of a given template, so if we deploy two versions of the SCR template, we never know for sure which one will pickup the PID. We may wind up changing our build such that the PID has the version number embedded in it, but that will be a real pain because for a normal maintenance update, we’d have to change the names of 300+ configuration files. I’m going to try another method to address this, but I haven’t gotten around to it yet. The other big runtime difference between the two is the way the two implementations deal with “disappearing” OSGi services - The camel-scr component shuts-down the context when the required services go away while blueprint uses it’s service proxies to wait for the services to come back. However, you can hook into this and get pretty much what camel-scr does using blueprint. They both work - it really depends on your requirements as to which is preferable. As far as developing components using camel-scr, it depends on your use case IMO. If you’re trying to build configurable routes with very straightforward service dependencies, it’s pretty easy to deal with - the biggest problem is there isn’t a “camel-test-scr” module, so you wind up with a bunch of boilerplate code in your tests. Also, if you base your tests on what comes from the archetype, you don’t have all the nice tools/support that Camel***TestSupport provides. For more complex service dependencies and templates/factories, I think the Blueprint method works better (at least for us). We can stage our update rollouts and we don’t have to rename PID files all the time. There are also some issues with Blueprint that can make this a little challenging, but I still prefer it for our environment. In summary - I think it depends on your use case. > On Jan 28, 2016, at 5:02 PM, Ranx <brad.john...@mediadriver.com> wrote: > > Having worked with blueprint and CamelBlueprintTestSupport for a couple of > years now at different clients I'm trying to find a better alternative. I > go into clients who usually have a lot of Java developers so staying in the > familiar Java world is something they appreciate. > > As of 2.16 the SCR is core and it can be used with earlier versions. I'm > wondering how many folks are using it in development and production and what > sort of experiences they've been having with it. > > Essentially, do folks feel it is ready for primetime? > > One concern I have is the registry mechanics. In the example generated by > the archetype it uses the simple registry and not an OSGi registry. Perhaps > that's not a problem but with blueprint crossing registry boundaries can > lead to quirky behavior. > > Any thoughts, guidance, clues, guesses, gesticulations, hare brained > schemes, cogent remarks or deep technical insights are all appreciated. > > Brad > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-SCR-tp5776954.html > Sent from the Camel - Users mailing list archive at Nabble.com.
