Re: Remove obsolete RxJava code and keep RxJava2 only one

[John D. Ament]

I was just about to remove the optional marking on reactive streams, and
noticed that rxjava was still around.  I guess it was decided to keep it?
I'll point out, this now makes the dependency chain even harder to follow
(since rxjava2 uses reactive streams, but rxjava does not).

John

On Wed, Nov 15, 2017 at 6:53 PM 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 <
> sberyoz...@gmail.com>
> 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
>
>
>

[GitHub] johnament closed pull request #377: 2.6.x fixes

[GitBox]

johnament closed pull request #377: 2.6.x fixes
URL: https://github.com/apache/cxf/pull/377
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Reactive Streams dependency in Project Reactor module

[Sergey Beryozkin]

Hi John

I think I indeed sent some confusing messages yesterday :-)

OK, what I meant was that the module had the original code to do with 
supporting the client only Rx invocations (such a client code can be 
server scoped as in your example), and the server only invocations (Json 
subcriber).


When I moved some of the server specific code into a shared base module 
I thought, after the 1st iteration, where only the JSON subscriber was 
shared, that it was OK to make that module optional - as it was of no 
use in the client-only scope and was not strictly needed for the server 
too, but during the 2nd/3rd iteration, when I pushed some more common 
code there affecting the JAXRSInvoker extensions, I should've removed 
the optional dep...


Perhaps making that dependency required is the simplest way forward

Sergey

On 04/02/18 19:22, John D. Ament wrote:

Well, now that I understand that it was meant specifically for client only
(its kind of odd, because JsonStreamingAsyncSubscriber is really for
subscribers, which is more on the server produced response).

What if we just had distinct modules for reactive-client and
reactive-server?

But either way, I'm not sure I follow your thoughts yet, since my use case
is just taking an existing Flux/Mono and piping it to a AsyncResponse
(nothing to do with client).

Granted, by doing that, I'm relying on internal CXF code, but it works.

John

On Sun, Feb 4, 2018 at 2:04 PM Sergey Beryozkin 
wrote:


The same though applies to the client code - it makes no sense on the
server side, so may be it is just simpler to make that dep non-optional
for the consistency purpose, up to you guys...

Sergey
On 04/02/18 18:57, Sergey Beryozkin wrote:

You've already concluded it is a bug...

I recall now, I made it optional because that code makes no sense on the
client side only, while the reactive streams api is also pulled from the
reactor dep...

Cheers, Sergey
On 04/02/18 18:12, Andriy Redko wrote:

Same conclusion, it shouldn't be optional/provided.
Thanks for spotting it.

Best Regards,
  Andriy Redko

JDA> That's what I'm asking basically.  If you look at
JDA>


https://github.com/apache/cxf/blob/master/rt/rs/extensions/reactor/pom.xml#L47-L49


JDA> I
JDA> don't believe it should be provided/optional.

JDA> On Sun, Feb 4, 2018 at 12:49 PM Sergey Beryozkin

JDA> wrote:


Why should be optional ?



Sergey
On 04/02/18 14:00, John D. Ament wrote:

Hi,

As far as I can tell, the dependency on reactive streams isn't
optional

in

the project reactor module.  I'm wondering, was this just a typo,
or am I
missing something?

John

Re: How to use rx() with proxy clients?

[Romain Manni-Bucau]

The two lasts options sounds the most natural to me and the first one
can be emulated with the second one propably.

AFAIK the async is only supported by having an InvocationCallback
which means you put in the request context an instance from an
interceptor currently in the proxy API - don't think it is wired
somewhere else

and in any case it is not the rx() call.



Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-04 23:46 GMT+01:00 John D. Ament :

> Yes, treating it like a MBR would work.  However, there needs to be a way
> as you mention to make it go async.  I'm more trying to see if this is
> already supported somehow.
>
> There's a few ways I could see executor working:
>
> - when building the proxy, include an executor() method (I think this is
> already inherited from JAX-RS 2.1)
> - use a property() call (already supported it seems in the core client)
> - one of the method arguments on the proxy
>
> John
>
> On Sun, Feb 4, 2018 at 3:12 PM Romain Manni-Bucau 
> wrote:
>
> > Why not using the response type? It is not hard to detect it is a
> > CompletionStage and therefore call rx().
> >
> > Side note: if there is an Executor param it should be
> forwarded/configured
> > IMHO.
> >
> > Le 4 févr. 2018 20:49, "John D. Ament"  a écrit
> :
> >
> > > So far, it looks like proxy clients don't support rx() invocations.  I
> do
> > > see rx() methods within WebClient that would allow its use, but I don't
> > see
> > > a straight forward way that those methods could be invoked within a
> > proxy.
> > > It could be that a custom annotation is used, indicating the response
> > > should be from an rx() invocation.
> > >
> > > John
> > >
> >
>

Re: [VOTE] CXF 3.2.2

[Alessio Soldano]

+1

Thanks
Alessio

On Fri, Feb 2, 2018 at 8:57 PM, Daniel Kulp  wrote:

> This is a vote to release CXF 3.2.2.   We’ve fixed over 60 JIRA issues,
> definitely time to release it.   This also includes releases of build-utils
> (3.4.0) and xjc-utils (3.2.1) to allow it to build on Java 9 and with the
> latest checkstyle plugins.
>
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1112/
>
>
> Tags:
> https://gitbox.apache.org/repos/asf?p=cxf-build-utils.git;a=commit;h=
> f362ab215acb17e744a8df4001b60e91dafb3a46
> https://gitbox.apache.org/repos/asf?p=cxf-xjc-utils.git;a=commit;h=
> 932ad93e601c19dab833b96a3649502334e90821
> https://gitbox.apache.org/repos/asf?p=cxf.git;a=commit;h=
> d579d7949d119dcf3d312059085bc200bcb3bbea
>
>
> Here is my +1.
>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>