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:ccann...@stubhub.com]
Sent: Friday, October 9, 2015 10:48 PM
To: Michael Putters <michael.putt...@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:sberyoz...@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/

Reply via email to