cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Putters" <michael.putt...@binarygenetics.com>
Subject RE: Vert.x support
Date Fri, 09 Oct 2015 21:00:27 GMT
I guess I will wait a bit longer then ;-)

One last bit of info, I suppose the easiest way to describe my goal would
be: https://github.com/englishtown/vertx-jersey but for CXF

So, see you all in few weeks.

-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] 
Sent: Friday, October 9, 2015 10:57 PM
To: dev@cxf.apache.org
Subject: Re: Vert.x support

On 09/10/15 21:50, Michael Putters wrote:
> Well, by saying it's what would be used in this implementation, I mean 
> this is what I would use to get CXF working with Vert.x's asynchronous
model.
>  From what I understand this is what CXF uses at this point to handle 
> asynchronicity, but maybe I'm wrong.
Yes, CXF is not even Java 8 based yet.

As I said a NIO 2.1 proposal will be coming shortly - next a trunk would
have to be made minimally Java 8 based, finally we will need to decide how
to do it. I'm not sure at this stage if Vert.x will need to be used but it
is a bit early to make any conclusions.
Perhaps having a Vert.x specific transport makes sense, irrespectively of
what JAX-RS 2.1 will provide, but it is still early to make this decision,
2.1 analysis needs to be made first

Sergey

>
> -----Original Message-----
> From: Canning, Charles [mailto:ccanning@stubhub.com]
> Sent: Friday, October 9, 2015 10:48 PM
> To: Michael Putters <michael.putters@binarygenetics.com>; 
> dev@cxf.apache.org
> Subject: RE: Vert.x support
>
> Replace continuations with Observables in reactive, or actors in akka, 
> or CompletableFutures in Java 8 or ... Your options arent as limited.
>
> Chuck
>
> From: Michael Putters
> Sent: 10/9/15, 1:40 PM
> To: dev@cxf.apache.org
> Subject: RE: Vert.x support
> Yes, the Continuations API is what would be used in this Vert.x 
> implementation, but without the underlying mechanism provided by 
> Vert.x I'd still be limited by the thread model used by servlet
containers.
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Friday, October 9, 2015 10:25 PM
> To: dev@cxf.apache.org
> Subject: Re: Vert.x support
>
> Hi
> On 09/10/15 21:18, Canning, Charles wrote:
>> Micheal,
>>
>> I cant answer the CXF portion, but i wanted to clarify one of your
points.
>>
>> If you use CXF and a servlet container in async mode, then you can 
>> have an
> event io based solution. We actually have it working in a reactive way.
>>
>> Just a possible solution. Hope this is useful.
> Thanks - I was not exactly sure if it was related but this is what I 
> was hoping to clarify from Michael, if JAX-RS AsyncResponse was
relevant...
>
> Thanks, Sergey
>>
>> Chuck
>>
>> From: Michael Putters
>> Sent: 10/9/15, 11:09 AM
>> To: dev@cxf.apache.org
>> Subject: Vert.x support
>> Hello,
>>
>>
>>
>>
>>
>> I'd very interested in having JAX-RS annotations - and a CXF 
>> implementation for them - running within Vert.x, for two main reasons:
>>
>>
>>
>> 1.       the typical features you get from CXF (duh), with the
possibility
>> of doing operations asynchronously re-using the continuation 
>> mechanism already present
>>
>> 2.       to use Vert.x as a mostly-automated API gateway:
>>
>> a.       some of the back-end's micro services would be registered in the
>> gateway (using the JAR that holds the interface with the JAX-RS
>> annotations)
>>
>> b.      the implementation of those services would be a simple proxy that
>> forwards the request to the back-end through an asynchronous CXF 
>> client, once the typical validation/etc. are performed
>>
>> c.       interceptors would make it possible to add features such as the
>> ability to do throttling/etc. based on tokens, for example
>>
>>
>>
>> The main advantage over servlets being the event-based I/O rather 
>> than distributing requests over a pool of threads.
>>
>>
>>
>> Now, I'm fairly new to the CXF codebase, but I've used CXF quite a 
>> bit in the past (but also Camel, so the whole Message/Exchange part 
>> is not entirely foreign to me). Which leads to me think maybe I could 
>> try to get this working and submit a pull-request when it gets to a 
>> point where it's useable.
>>
>>
>>
>> However, just to make sure my pull-request doesn't get instantly 
>> refused, I have some question regarding what I plan to do (mostly: is 
>> it OK if I do it this way?). Here's the plan:
>>
>>
>>
>> -          turn the cxf-rt-transports-http project and its classes into
>> something more abstract, extracting the servlet-specific parts to a 
>> new cxf-rt-transports-http-servlet project; this is mostly the 
>> various parts/methods that use ServletConfig, ServletContext, 
>> HttpServletRequest, etc.
>>
>> -          this cxf-rt-transports-http-servlet project would depend on
>> cxf-rt-transports-http and implement servlet-specific versions of the 
>> generic abstract classes and methods present in 
>> cxf-rt-transports-http
>>
>> -          create a cxf-rt-transport-http-vertx project that does just
the
>> same, but using Vert.x classes and mechanisms rather than the servlet 
>> equivalent, eg: HttpServletRequest becomes HttpServerRequest
>>
>> -          update the cxf-rt-transports-http-* projects so that they
> depend
>> on cxf-rt-transports-http-servlet rather than cxf-rt-transports-http
>>
>>
>>
>> This would cover a first step that only includes a slice of the 
>> server-side elements and nothing regarding the CXF client.
>>
>>
>>
>> Can anyone confirm that this would be the right way to add Vert.x 
>> support to CXF?
>>
>>
>>
>> Thanks,
>>
>>
>>
>>
>>
>> Michael
>>
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
>


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/


Mime
View raw message