cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Jetty Continuations in CXF
Date Mon, 03 Nov 2008 16:21:30 GMT

> No.   I actually expect this to be more important for the JMS folks than the
> HTTP folks which is why it needs to be transport independent.   Basically,
> MOST HTTP users expect a fairly synchronous invokation path.   That's pretty
> much how its "always been" so people using HTTP, unless they specifically
> know about the jetty continuations, wouldn't even think about it.    JMS
> folks on the other hand are much more in tuned to the ideas around
> asynchronous communication and events.

CXF-1835 reads :

"Use Jetty Continuations to implement asynchronous HTTP processing"

Thus I believe that a user who opened this JIRA is after using it with HTTP.

> We also promote the idea that the same "impl" can be used on multiple
> transports/bindings.   Thus, the continuation code needs to be abstracted out
> to hide the underlying transport.

I don't object to a transport independence - but I'd argue it's not something which we should
focus upon first, as far as this 
specific JIRA is concerned. Lets solve the actual problem the user raised rather than try
to come up wuth a universal solution.

OK, just would like to check - ate you thinking of us introducing our own ContinuationSupport
and Continuation interfaces ? I'm not 
sure it's the right approach - but i may be wrong

> Also, I've started looking into the MINA based HTTP stuff (mostly for Async on
> the client side, but also as a possible Jetty replacement).   Thus, this
> needs to be abstracted out so that if we do replace Jetty, existing code
> would still work.
>> I think we have two scenarious to look at. First one is when a CXF acts as
>> a request provider for some ServiceMix components (implicitly serving as
>> 'application code') - which is what CXF-1835 is mostly about.
> Right.  Which can be JMS or HTTP or CORBA or .....     The ServiceMix
> components pretty much do exactly what an Impl would do except they have
> direct access to the message instead of the WebServiceContext.   Thus, either
> way, we need to abstract it out a bit.

It can be but the user is after doing it with HTTP.

>> Another one is about CXF service application code doing Continuations
>> I think it does - but I'd just like to start with just HTTP in mind, just
>> to get going and consider a transport portability issue at the the next
>> stage.
> I'd have to say -1 to that.   Or at least it doesn't get merged up into any of
> the 2.1.x/2.0.x branches until it's completely abstracted.   Once it gets
> merged up and potentially released, we need to support it as is relatively
> indefinitely and I don't want to support a "half baked" solution that is tied
> directly to a particular http implementation.

No worries. Let me have the test working first. Furthermore, I don't share your concern about
us supporting something
indefinitely in this case. For this specific JIRA there's no urgent need to introduce any
new interface rather it's about some 
internal modifications - hence no need to support public interfaces.

This individual JIRA is not about user explictly interacting with continuations (scenario1
as I described). What you suggest 
(abstracting it all) is about a user interacting explictly with continuations (scenario2).
As I said - I don't object to it - but 
I'd be surprised if we bundled both requirements into a single JIRA.

Lets open another one (letting users do continuation support in a transport-portable way)
and look at it independently - IMHO it 
would be a faster and better way to tackle the whole continuations thing

Just my 2c

> -- 
> Daniel Kulp

View raw message