Hi Sergey,
+1, Java 8 trunk is the priority, definitely agree (please count in me to
help with addressing any issues we may have).
Thanks!
PS: From runtime prospective, CXF 2.7.x / 3.x runs very well on JVM 8, it
is my second project where we run CXF in prod
on Java 8 for quite some time and it has no issues so far.
Best Regards,
Andriy Redko
On Tue, Feb 24, 2015 at 8:34 AM, Sergey Beryozkin <[email protected]>
wrote:
> Hi Andriy
>
> I'd not really worry right now about it, it would only be a Jersey
> specific integration and we just have to wait get a Java 8 trunk first
> anyway - I do expect that JAX-RS 2.1 Reactive extensions will have no any
> direct relationship to Netflix, perhaps you'd choose to use ot internally,
> I'm not sure right now
>
> Cheers, Sergey
> On 24/02/15 13:31, Andrey Redko wrote:
>
>> Hi Sergey,
>>
>> Thanks, absolutely, he is not proposing the reactive client. It is my
>> own comment with respect to Netflix projects making its way into
>> Jersey/JAX-RS implementation(s).
>> It is more about do we want spend time / efforts on that? Hystrix
>> integration could be interesting feature however at this point I do no
>> see clearly how it fits into CXF, only some rough sketches.
>> Thanks!
>>
>> On Tue, Feb 24, 2015 at 8:00 AM, Sergey Beryozkin <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Andriy,
>>
>> David Karlsen is def not proposing to start supporting reactive
>> client API, it is more about about some advanced fault-tolerance
>> support - we should actually reply to him I guess.
>>
>> Thanks for sharing a link though. We will have to implement it as
>> part of JAX-RS 2.1 work, and we'd need to have a Java 8 trunk opened
>> for it.
>>
>> It does appear Jersey is already full steam into a Java 8 based 2.1
>> development (note: no spec api proposals have been made - but I
>> expect them coming soon enough once they have finished
>> experimenting). Dan,
>>
>> IMHO it would be right to have a Java 8 trunk opened in the last
>> quarter of the year to give CXF a better chance of catching up
>> sooner than later with Jersey. I'm not trying to extend the dev
>> discussion here though - more or less what I said there :-)
>>
>> Cheers, Sergey
>>
>>
>> On 24/02/15 12:30, Andrey Redko wrote:
>>
>> Hi Sergey,
>>
>> What do you think about looking into this feature? I do have some
>> knowledge about Hystrix and it
>> has gained some traction in the community. I am not sure though
>> what
>> exactly this guy has
>> in mind BUT if you don't mind, I can work with him to outline
>> his design
>> / intentions and make sure
>> it would make sense for the CXF project (I can reply to him and
>> work
>> with him directly).
>>
>> What do you think?
>>
>> PS: FYI, Jersey has started to integrate Netflix projects
>> (http://blog.dejavu.sk/2015/__01/07/reactive-jersey-client-_
>> _part-1-motivation/
>> <http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-
>> part-1-motivation/>),
>> into their JAX-RS implementation, I think Hystrix will come soon
>> as well.
>>
>> Best Regards,
>> Andriy Redko
>>
>> ---------- Forwarded message ----------
>> From: *David Karlsen* <[email protected]
>> <mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]
>> >__>>
>> Date: Mon, Feb 23, 2015 at 4:03 AM
>> Subject: Hystrix feature?
>> To: [email protected] <mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>
>>
>>
>> Hi.
>>
>> I'm wondering about creating an Interceptor for outgoing requests
>> (isRequestor()==true) to wrap these (synchronously) in a Hystrix
>> [1]
>> executable [2].
>>
>> Instead of having this as an inhouse custom component, I wonder
>> about
>> creating a branch of cxf and adding a features/hystrix component
>> (like for
>> the clustering support). Is this a component you would accept and
>> be
>> willing to merge into master? I'm asking upfront so I don't end
>> in a
>> dead-end with it and have to port it back to an inhouse-component.
>> I thought I'd use the serviceQname as commandGroup (namespace)
>> and key
>> (localname). I also thought I'd add a protected method
>> resolveTenant
>> (returning null for default) so that multitenant solutions are
>> well
>> supported (e.g. the same service may be ok for one tenant and
>> failing for
>> another, so be able to differenciate config).
>>
>> [1] https://github.com/Netflix/__Hystrix
>> <https://github.com/Netflix/Hystrix>
>> [2]
>> https://netflix.github.io/__Hystrix/javadoc/com/netflix/__
>> hystrix/HystrixCommand.html
>> <https://netflix.github.io/Hystrix/javadoc/com/netflix/
>> hystrix/HystrixCommand.html>
>>
>>
>> WDYT?
>>
>> --
>> --
>> David J. M. Karlsen - http://www.linkedin.com/in/__davidkarlsen
>> <http://www.linkedin.com/in/davidkarlsen>
>>
>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
