Hi
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
Sergey
--
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog
