+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 now >>>> 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 >>>>>> page, >>>>>> https://github.com/ReactiveX/RxJava/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 with >>>>>> 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 beyond >>>>>> 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" <*[email protected] >>>>>>>> <mailto:[email protected]>*> 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 < >>>>>> *>>>> [email protected] <mailto:[email protected]>*> >>>>>>>>>> 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 >>>>>> *
