Hi David,
Thank you very much for bringing up this interesting feature. At this very
moment it is a bit early to say that the component is going to be accepted
and will make it way into Apache CXF codebase. However, it may indeed become
very useful. What do you think if we start with discussion on what problem(s)
and use case(s) you are going to solve with CXF/Hystrix, how integration is
going
to be designed (you already put some rought design notes), how it is going to
be used in existing/new applications build on top of Apache CXF.
Please let us know if it would make sense to you.
Thank you.
Best Regards,
Andriy Redko
DK> Hi.
DK> I'm wondering about creating an Interceptor for outgoing requests
DK> (isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
DK> executable [2].
DK> Instead of having this as an inhouse custom component, I wonder about
DK> creating a branch of cxf and adding a features/hystrix component (like for
DK> the clustering support). Is this a component you would accept and be
DK> willing to merge into master? I'm asking upfront so I don't end in a
DK> dead-end with it and have to port it back to an inhouse-component.
DK> I thought I'd use the serviceQname as commandGroup (namespace) and key
DK> (localname). I also thought I'd add a protected method resolveTenant
DK> (returning null for default) so that multitenant solutions are well
DK> supported (e.g. the same service may be ok for one tenant and failing for
DK> another, so be able to differenciate config).
DK> [1] https://github.com/Netflix/Hystrix
DK> [2]
DK>
https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html
DK> WDYT?
