cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Vert.x support
Date Thu, 19 May 2016 15:56:40 GMT
Sorry, *Now* that we on Java 8 trunk...

On 19/05/16 16:53, Sergey Beryozkin wrote:
> Hi Michael
>
> Not that we on Java 8 trunk, should we continue the conversation ?
>
> Cheers, Sergey
>
> On 09/10/15 22:20, Sergey Beryozkin wrote:
>> Sounds good :-), thanks again - as I said we can either try and align
>> JAX-RS 2.1 features with Vert.x features or even have a dedicated Vert.x
>> transport if that can help (to all of CXF users), hope something
>> interesting will be done around it in CXF.
>>
>> Cheers, Sergey
>>
>>
>> On 09/10/15 22:00, Michael Putters wrote:
>>> 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:sberyozkin@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:ccanning@stubhub.com]
>>>> Sent: Friday, October 9, 2015 10:48 PM
>>>> To: Michael Putters <michael.putters@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:sberyozkin@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/
>>>
>>
>>
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Mime
View raw message