Just a fyi. I think archaius is gone in Hystrix 1.5 (configuration is an
interface with default imp with archaius). There is a RC out of Hystrix 1.5
28. jan. 2016 15:12 skrev "Raul Kripalani" <ra...@apache.org>:
> Hey Bilgin,
>
> I agree with you. My implementation started as a experiment, to be honest.
>
> My vision was deep and fluent integration between Camel and Hystrix, that's
> why I started experimenting with a fluent DSL. To me, Hystrix is not just
> an external thing to integrate in Camel, but it should play a larger role
> in changing how Camel fundamentally deals with exceptions in endpoints,
> processors and routing.
>
> However, I do agree that ultimately we would need to offer URI
> configuration (especially for Spring/Blueprint DSL users) before merging
> the component into master. But I wanted to get the enginery working first
> and the right level of fluency, to then add the URI logic because the
> latter is simpler. The "hardcore" part is actually supporting all of the
> magic that Hystrix offers.
>
> I agree that my implementation may be more complex to use in some
> scenarios. But I was focusing on not having to register objects in the
> Registry, because I particularly hate that amount of indirection ;-) Having
> to register endpoints and processors in the Registry just to be able to use
> them from the Hystrix endpoint seems a bit too much, and I wanted to
> achieve this level of fluency with JDK8:
>
> hystrix.wrapper()
> .forProcessor((exchange) -> throw new
> DummyException("Bang!")), setter)
> .withFallbackProcessor((exchange) ->
> exchange.getOut().setBody("Sorry, something happened"))
> .suppressFallbackForExceptions(DummyException.class)
> .build();
>
> Or to be able to specify endpoint URIs inline, rather than having to
> register them in the registry to then reference them via # pound notation:
>
> hystrix.wrapper()
> .forStaticEndpoint("http://google.com";, setter)
> .withFallbackProcessor((exchange) ->
> exchange.getOut().setBody("Could not reach Google. Is it the end of the
> world?"))
> .build();
>
> Setters should be optional, BTW. And we should offer convenience methods to
> set typical Setter parameters (command name, group key, etc.). And I think
> my starting of services in Processors in a test was actually redundant.
>
> If you are actively working on the Hystrix component, go ahead! I can then
> enhance your implementation with a DSL, and you can take stuff from my
> implementation so far. The point where I got stuck was bridging Archaius
> (Hystrix configuration library) with our Camel Property Placeholders,
> Spring and Blueprint. Ideally Hystrix commands would be able to configure
> themselves by introspecting our existing properties in the context... :-(
>
> WDYT?
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk>
>
> On Thu, Jan 28, 2016 at 1:43 PM, Bilgin Ibryam <bibr...@gmail.com> wrote:
>
> > 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
> >
>
