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/
