Hi Raul, More or less the same time you published the first email about camel-hystrix component, I also created camel-hystrix component [1] (it is not finished yet!). But I took the typical (boring ;-)) approach where the hystix support can be used as a regular component through URI configuration. Since you announced first and started the effort more visibly on jira/git/list I decided not to duplicate effort and wait for your progress.
Now looking at your implementation, I see it is quite advance and offers many intersting features, great work. But my concernds are primarily around using the fluent API rather than Camel URIs. In my opinion Camel URI is a nice abstraction and using it should be default option for any component. It makes easy for existing Camel users to strat using a component. Also not sure how the fluent API can be used from XML based DSL, may be I'm missing something. IMHO, your implementation is more advanced, but also more complicated to use. Using a builder, then setting some Histryx specific objects (I think it was the HystrixObservableCommand.Setter), starting services manually, seems too much work to me. I believe all that can be expressed through a regular component. Not sure way would be the better approach going forward. May be we can merge both approaches and offer the regular URI based component usage and also the additional fluent API. WDYT? [1] https://github.com/bibryam/camel-hystrix Bilgin On 25 August 2015 at 02:13, Raul Kripalani <r...@evosent.com> wrote: > Hi team, > > Hystrix [1] is a powerful toolbox framework based on RxJava for building > JVM-based fault-tolerant distributed systems, made OSS by Netflix. > > Due to the nature of Camel, our users inherently deal with distributed > systems and therefore I thought integrating this framework into Camel would > be useful. > > I wanted to go beyond the typical (boring ;-)) URI-based component. Hystrix > has lots of features, some of which can take predicates (which in our world > translate to Processors and Expressions), so a fluent DSL is especially > appealing here. > > I'm doing this work in the feature/camel-hystrix branch at the ASF Git [2]. > I created a ticket with my functionality roadmap [3], and ticked out what > has already been implemented. > > I foresee some difficulty with integrating Archaius (Netflix' config > framework) with our Camel property placeholders and OSGi Config Admin. I'd > also like to achieve Turbine integration to enable the awesome Hystrix > dashboard across clusters [4]. > > If you have ideas, feel free to post them. If you have spare cycles, feel > free to contact me if you'd like to participate in the development so we > can coordinate. > > [1] https://github.com/Netflix/Hystrix > [2] https://github.com/apache/camel/tree/feature/camel-hystrix > [3] https://issues.apache.org/jira/browse/CAMEL-9098 > [4] https://github.com/Netflix/Hystrix/tree/master/hystrix-dashboard > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk -- Bilgin Ibryam Camel Committer at ASF & Integration Architect at Red Hat Blog: http://ofbizian.com | Twitter: @bibryam Camel Design Patterns https://leanpub.com/camel-design-patterns Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
