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:sberyoz...@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: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/
