Hi Dan,
Daniel Kulp wrote:
On Thursday 02 September 2010 9:32:46 am Willem Jiang wrote:
Hi
I just did some work to let the camel-cxf leverage the CXF continuation
framework which you did. I just found current CXF continuation which
suspend is implemented by throw the runtime exception. This
implementation has a shortcoming which cannot call the other framework's
async API after continuation suspend is called as Jetty7 does.
This will introduce a situation that continuation resume will be called
before the continuation suspend is called if the famework's async API is
finally using the thread to do the job.
So I'm thinking of some enhancement could be possible to let CXF
continuation leverage Jetty 7 new continuation API.
Any idea?
I created a JIRA[1] and submit a patch for it. Please review it :)
While upgrading things to Jetty 7, this is something I was thinking about a
bit more as well. I actually wanted to add a method like:
public void resume(Object r);
method onto the continuation. The endpoint (or background thread or
whatever) could call that directly (the Object being the thing that would
normally be returned from the method). The runtime could immediately just
grab the associated chain and pick up where it left off and not do the restart
thing. The new Servlet 3 API's and the new things in Jetty 7 seem to allow
that. It could potentially make the continuations stuff a lot easier to work
with.
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 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
