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
