On 9/9/10 10:57 AM, Daniel Kulp wrote:
On Wednesday 08 September 2010 9:08:36 pm Willem Jiang wrote:
.......
I'm afraid I had to introduce other status into interceptor chain like
SUSPEND, it will move the interceptor iterator to the preious one and
through the SuspendedInvocationException, and PAUSED will not do these
things.
I will give it a shoot :)
Cool. Hopefully it works a bit better.
This actually should be a bit cleaner across the board. If the
ServiceInvokerInterceptor and such needs to see if the chain is suspended, it
can just call message.getInterceptorChain().isSuspended() (or similar). For
example, since the Exception in not longer thrown, it may need (or at least
should) check that to see if it should setup the response message or not.
I just committed the patch into the check, please review it.
Current we just make the interceptor chain resume from where we pause
it. I don't know that you want.
I think the blow code is enough.
continuation.setObject(obj);
continuation.resume()
I think my point was that why have it resume where it left off at all.
Why could we not just do something like:
Foo doSomething(...) {
....
if (continuationProvider != null) {
final Coninuation cont = coninuationProvider.getContinuation();
cont.suspend();
executor.execute(new Runnable() {
public void run() {
cont.resume(doTheRealThing(....));
}
});
return null;
}
// no continuation support, must do syncronous
return doTheRealThing(...);
}
Foo doTheRealThing(...) {
return new Foo();
}
Understood, in this way the implemenation can support the continuation
and no continuation environment at the same time.
As we get the control of the interceptor chain, it can be done by
hacking the ServiceInvokerInterceptor and put the response back, but it
will break the old continuation semantic which can make the user method
be called again when the continuation resume is called.
Well, I was kind of assuming that if resume() is called (the old method), the
old behavior would remain. If resume(object) is called, the new behavior can
be used. Thus, it really wouldn't break the old semantic, but would allow
for a new, cleaner, semantic. What do you think?
Dan
Current CXF continuation is not just works for ServiceImpl, it also
helpful if the user uses it in the interceptor. If we introduce the
resume(object) method, this method can't be used in the other
interceptors and it let user misunderstand the continuation's meaning.
So I suggest we don't introduce this method into CXF continuation.
Willem
With a setup like that, there isn't a need for doSomething(...) to be
called again at all. The runtime would be able to handle it all. For
some transports, we could use the thread that called resume(obj) to
restart the chain and such and not bother with another transport
provided thread and do the tread context switches and such.
Dan
I actually would like to change everything to not bother with the
exception either. The endpoint would call "suspend" and if it returns
true (meaning the request was suspended), just return null. If false,
it knows it needs to do the work synchronously. It's much closer to
how the Servlet 3 things work. Unfortunately, that would completely
change the semantics of the API and would require some good docs for
the migration guide.
I don't think this is a good idea, if we can't support to the
continuation API from the transport level, we simple don't let the user
can get the ContinuationProvider from the message context.
It could be much easier for user to use :)
[1]https://issues.apache.org/jira/browse/CXF-2982
Willem
