cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andriy Redko <>
Subject Re: Remove obsolete RxJava code and keep RxJava2 only one
Date Thu, 16 Nov 2017 13:55:20 GMT
+1 to that, also Jersey has RxJava and RxJava2 modules (at least for
the client side).

Thursday, November 16, 2017, 8:51:25 AM, you wrote:

SB> Hi Andriy

SB> Yeah, that is true. The only indirect reference to the fact CXF + 
SB> RxJava1 might be combined somehow is that the initial RxJava1 code was 
SB> added after a JIRA request was opened.
SB> By the way I've browsed around and found out ReastEasy friends have 
SB> RxJava and RxJava2 modules :-).

SB> I guess the only prob with splitting it into tow modules in CXF is that 
SB> CXF 3.2.1 is known to ship RxJava2 code in the cxf-rt-rs-extension-rx, 
SB> so I guess it would have to be moved to cxf-rt-rs-extension-rx2, and I'd 
SB> not be surprised if it would actually be noticed by CXF 3.2.2 users, 
SB> given that users like trying newer things...

SB> So perhaps keeping things as is in 3.2.x is the best compromize

SB> Cheers. Sergey
SB> On 16/11/17 13:41, Andriy Redko wrote:
>> Let's do what is really the best for CXF in short term (long term is obviously
>> dropping RxJava 1.x). I saw and  still see RxJava 1.x in the field, BUT I haven't
>> seen the CXF + RxJava 1.x in use yet :) So my arguments are purely based on
>> assupmtions, not the real facts :-D

>> SB> It's obviously not only my decision what to do with this code, you are
>> SB> right it's only my opinion (which will stay non-binding) which is to
>> SB> keep where it is now just in case and drop it once the new master opens.

>> SB> To be honest, it does not matter much to me :-), so if few more PMCs say
>> SB> yes, def has to be a new module - then I'll give my +1 and move on, as I
>> SB> said purely from a tech point of view a dedicated module without
>> SB> optional deps is better.

>> SB> I'm simply hesitating, given how much effort went into dropping some old
>> SB> modules from 3.2.x, to start with another module with precisely 4 files
>> SB> (3 in .client subpackage, 1 in .server) with us (me definitely) unlikely
>> SB> contributing to it at this stage. I'd rather spend the limited amount of
>> SB> time I have now on growing the small (but with the prospect of growth)
>> SB> reactivestreams lib we've discussed with John which can be used by
>> SB> RxJava2 and Reactor code...

>> SB> Cheers, Sergey
>> SB> On 16/11/17 12:02, Andriy Redko wrote:
>>>> Fair enough, if we the new module is not a option (in your opinion),
>>>> I would vote to remove the RxJava 1.x integration and dependency.

>>>> SB> As I said, as far as CXF is concerned, there's no prospect of RxJava
>>>> SB> related code growing, and contributing to a CXF module noise to support
>>>> SB> a legacy library (I know I have to be careful now about the wording:-),
>>>> SB> I'm meaning here RxJava2 embracing org.ractivestreams) is not worth
it IMHO.

>>>> SB> If you check my earlier reply, I suggested to keep it where it is
>>>> SB> after all. So if we have some users somewhere deciding to stay with
>>>> SB> RxJava then they'd have the support they need.

>>>> SB> Cheers, SErgey
>>>> SB> On 16/11/17 11:45, Andriy Redko wrote:
>>>>>> Got it, so "legacy" part is questionable here. Check out the releases
>>>>>>, the 1.x is still being
>>>>>> actively
>>>>>> supported and maintained (and there are reasons for that, as I
>>>>>> mentioned). So
>>>>>> it is really up to us to decide, should we support it or not, but
>>>>>> the new
>>>>>> module we could get the stats and make the decision not based on
>>>>>> "legacy" but
>>>>>> if it is used or not. I don't have particular attachments to RxJava
1.x so
>>>>>> if you are confident no one is relying on this integration, I would
>>>>>> agree with
>>>>>> you and we should better remove this code.

>>>>>> *SB> The problem is not about a new module, but about RxJava is
a legacy
>>>>>> lib,
>>>>>> SB> and having a module with 2/3 files with no prospect of going
>>>>>> this
>>>>>> SB> number is not worth it IMHO

>>>>>> SB> Sergey

>>>>>> SB> On 16/11/17 11:15, Andrey Redko wrote:
>>>>>>>> Hey Sergey,

>>>>>>>> I think the "ideal" in this case depends on whom to ask.
For us - yet
>>>>>>>> another module to support, for users - out of the box integration.
With new
>>>>>>>> module we could collect a bit more insights if people use
it or not. No use
>>>>>>>> - drop in next releases. Thanks.

>>>>>>>> Best Regards,
>>>>>>>>        Andriy Redko

>>>>>>>> On Nov 16, 2017 4:42 AM, "Sergey Beryozkin" <*
<>*> wrote:

>>>>>>>>> Hi Andriy

>>>>>>>>> As I said, introducing a dedicated support for a legacy
library in the
>>>>>>>>> form of a new module would not be ideal IMHO

>>>>>>>>> Cheers, Sergey
>>>>>>>>> On 15/11/17 23:53, Andriy Redko wrote:

>>>>>>>>>> Hey Sergey,

>>>>>>>>>> That would be ideal I think (move RxJava into separate
module). RxJava2
>>>>>>>>>> and
>>>>>>>>>> RxJava are quite different frameworks, some people
just stuck with RxJava
>>>>>>>>>> so
>>>>>>>>>> we could support them there. Thanks.

>>>>>>>>>> Best Regards,
>>>>>>>>>>         Andriy Redko

>>>>>>>>>> JDA> What about just leaving the old RxJava code
in a module by itself
>>>>>>>>>> (when I
>>>>>>>>>> JDA> was looking recently, it didn't make much
sense to see both RxJava
>>>>>>>>>> and
>>>>>>>>>> JDA> RxJava2 in one module).

>>>>>>>>>> JDA> On Wed, Nov 15, 2017 at 10:56 AM Sergey Beryozkin
>>>>>> *>>>> <>*>
>>>>>>>>>> JDA> wrote:

>>>>>>>>>> Hi

>>>>>>>>>> cxf-rt-rs-extension-rx ships the code for both (old)
RxJava and RxJava2
>>>>>>>>>>>> code. It supports returning RxJava2 Flowable
and Observable on the
>>>>>>>>>>>> server and accepting it on the client, and
the same for the (old) RxJava
>>>>>>>>>>>> Observable...

>>>>>>>>>> While even the (old) RxJava code is very new for
CXF, the reality is
>>>>>>>>>>>> that RxJava has been around for a while now
and with RxJava2 embracing
>>>>>>>>>>>> org.reactivestreams, it's hard to see CXF
users preferring to start with
>>>>>>>>>>>> the (old) RxJava.

>>>>>>>>>> The other minor problem is that cxf-rt-rs-extension-rx
has optional
>>>>>>>>>>>> RxJava and RxJava2 deps to be able to ship
the relevant code in the same
>>>>>>>>>>>> module and splitting it into 2 modules will
be too much at this point.

>>>>>>>>>> I suggest that unless some users confirm (I CC to
the users) that they
>>>>>>>>>>>> need to use the (old) RxJava code, then we
just remove it and make
>>>>>>>>>>>> things much simpler...

>>>>>>>>>> Thanks, Sergey

>>>>>> *

View raw message