The probem with this approach is that you leave the burden to the user
to maintain two different piece of codes.
One that will support synchronous invocations and another one that
will support asynchronous invocations.

On Fri, Nov 14, 2008 at 11:57 AM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
> this may be an option but i'd rather prefer users sticking to this pattern
> as suggested by Dan earlier on for transports like Corba or non-Servlet
> 3/not Jetty-aware HTTP ones :
>
> WebServiceContext context;
> public String greetMe(String arg) {
>    ContinuationSupport contSupport = (ContinuationSupport)
>             context.get(ContinuationSupport.class.getName());
>    if (contSupport == null) {
>         //continuations not supported, must wait
>         return jmsGreeter.greetMe(arg);
>    }
>    ....
> }
>
>
> In other words if a transport is not 'natively' async or can not handle
> suspended requests like Jetty/servlet3 aware HTTP transport can, then we
> won't even provide any ContinuationSupport wrappers...
>
> Cheers, Sergey
>
>
>
>> We may want the continuation support to work in both case.  This is
>> the case in jetty, and we may want to mimic the same kind of behavior
>> in case some transports do not support continuations.
>> In such a case, the continuation simply blocks and waits for a call to
>> resume(), in which case, the thread is unlocked and the processing is
>> resumed.
>>
>> On Thu, Nov 13, 2008 at 12:06 PM, Sergey Beryozkin
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> I've added a simple HTTPS test and with HTTPS we have no luck at the
>>> moment,
>>>
>>> CxfJettySslSocketConnector extends Jetty SslSocketConnector and calling
>>> continuation.suspend(timeout) simply blocks the calling thread.
>>>
>>> I've checked the archives and I believe at a time
>>> SslSelectChannelConnector[1] was considered unstable so instead a
>>> blocking
>>> SslSocketConnector was picked up.
>>>
>>> Any thoughts on what would it take to upgrade CxfJettySslSocketConnector
>>> to
>>> use SslSelectChannelConnector ?
>>>
>>> Thanks, Segey
>>>
>>> [1]
>>>
>>> http://www.mortbay.org/jetty/jetty-6/apidocs/org/mortbay/jetty/security/SslSelectChannelConnector.html
>>>
>>>>>>
>>>>>> Question : how will SMX CXF Binding Component interact with (Jetty)
>>>>>> continuations when dealing with CXF-originated invocations ? The
>>>>>> Continuation wrappers will be available through an internal CXF input
>>>>>> Message and through JAXWS WebServiceContext (or JAXRS one later on) -
>>>>>> will
>>>>>> CXF BC be able to get hold of such wrappers  ? If yes then I guess we
>>>>>> have
>>>>>> no problems at all ?
>>>>>>
>>>>> Yes, I think so, get continuation from cxf message
>>>>> (org.apache.cxf.message.Message) is fine for CxfBcConsumer.
>>>>
>>>> super.
>>>>
>>>> I've just copied the relevant code only to sandbox as I didn't manage to
>>>> create a branch :
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations
>>>>
>>>> Some comments. You can see in :
>>>>
>>>> 1. The wrapper interfaces for ContinuationSupport and Continuation in
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/api/src/main/java/org/apache/cxf/continuations
>>>>
>>>> 2. How PhaseInterceptorChain deals with suspended exceptions in
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/api/src/main/java/org/apache/cxf/phase/PhaseInterceptorChain.java
>>>>
>>>> 3. How AbstractInvoker deals with suspended exceptions in
>>>>
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/core/src/main/java/org/apache/cxf/service/invoker/AbstractInvoker.java
>>>>
>>>> 4. How ChainInitiatorObserver deals with resuming an invocation chain in
>>>>
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/core/src/main/java/org/apache/cxf/transport/ChainInitiationObserver.java
>>>>
>>>> 5. Jetty-specific continuation wrappers in
>>>>
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/continuations
>>>>
>>>> 6. How JettyDestination deals with continuations :
>>>>
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
>>>>
>>>> 7. System tests :
>>>>
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations
>>>>
>>>> See the server code on how the test code interacts with continuations
>>>> through wrappers :
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations/HelloImplWithWrapppedContinuation.java
>>>>
>>>> and how it does so directly
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations/HelloImplWithContinuation.java
>>>>
>>>> check
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations/jetty-engine.xml
>>>>
>>>> on how a jetty engine on a specific port can be told to ignore
>>>> continuations which are supported by default if true is set or that
>>>> attribute is omitted (not used in the test though)
>>>>
>>>> Ok - you can now see it it so shoot :-) Comments are welcome
>>>>
>>>> Sergey
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to