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/
