Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Subject: Re: Vert.x support
To: dev@cxf.apache.org
References: <052201d102bd$a6ef2520$f4cd6f60$@binarygenetics.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <561821BA.9060200@gmail.com>
Date: Fri, 9 Oct 2015 21:21:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <052201d102bd$a6ef2520$f4cd6f60$@binarygenetics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi

Thanks for your proposal.

Personally I do not have any experience with Vert.x. However we expect 
that JAX-RS 2.1 proposal on the reactive client API be available next 
week. Once we analyze it we can start reviewing which 
framework/mechanism can help us with implementing this reactive API 
proposal.

Checking Vert.x docs suggests that it can possibly help in this area.

Re your proposal below. Can JAX-RS 2.0 AsyncResponse be somehow relevant 
? I.e, can it help doing what you expect to be able to do if your 
proposal is accepted ?

Note we also expect a JAX-RS 2.1 proposal on non-blocking IO be 
available next week - I'm not sure yet how/if it will be related somehow 
to what Vert.x can do on the server side.

I guess Vert.x is Java 8 based ? We are very close now to opening a Java 
8 trunk now that the last quarter is nearly here, but we have still a 
Java 7 trunk...

Cheers, Sergey

On 09/10/15 19:09, Michael Putters wrote:
> 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
>
>