On Aug 12, 2009, at 10:10 PM, Alex Sherwin wrote:
> When might we see this in a Jersey point release?
>
I think i can make API changes that effect the end user for 1.1.2-ea
that we will schedule for Aug 24th to align with a milestone release
of GlassFish. The listener interface is already done, the filter stuff
is next.
Then the next steps, after 1.1.2-ea, would be to wire things up to an
HTTP client that supports true async. This will require internal
changes and SPI additions but the end user should not be affected. If
an HTTP async impl is available the async support should just be more
efficient/scalable.
Between now the the 1.1.2-ea release I want to investigate some HTTP
client async implementations to ensure i have the correct abstractions.
Paul.
> Craig McClanahan wrote:
>> Paul C. Bryan wrote:
>>> Okay, then FWIW, +1 from me. That's the least disruptive break I can
>>> imagine for the switch to asynchronous... :)
>>>
>>>
>> +1 as well. I'm not concerned about binary compatibility, as I'm
>> always recompiling my apps anyway.
>>
>> Craig
>>> On Wed, 2009-08-12 at 19:08 +0200, Paul Sandoz wrote:
>>>
>>>> On Aug 12, 2009, at 7:04 PM, Paul C. Bryan wrote:
>>>>
>>>>
>>>>> Will there be a way for the client request filter to establish
>>>>> context
>>>>> that the client response filter can in turn consume?
>>>>>
>>>>>
>>>> Yes, properties can be added to the request in the request
>>>> filter which can then be retrieved in the response filter:
>>>>
>>>> https://jersey.dev.java.net/nonav/apidocs/1.1.1-ea/jersey/com/sun/jersey/api/client/ClientRequest.html
>>>> #getProperties%28%29
>>>>
>>>> Paul.
>>>>
>>>>
>>>>> On Wed, 2009-08-12 at 14:45 +0200, Paul Sandoz wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I mentioned before in a previous email about breaking changes
>>>>>> client
>>>>>> API to support efficient asynchronous requests/responses such
>>>>>> that a
>>>>>> response can be processed on a different thread to that of a
>>>>>> request.
>>>>>>
>>>>>> The current filter approach is stack-based using a general
>>>>>> handler
>>>>>> chain where the last handler is "inflection" point that sends
>>>>>> an HTTP
>>>>>> request and produces an HTTP response.
>>>>>>
>>>>>> We need to split the a filter into separate request and response
>>>>>> filters:
>>>>>>
>>>>>> public interface ClientRequestFilter {
>>>>>> ClientRequest filter(ClientRequest request);
>>>>>> }
>>>>>>
>>>>>> public interface ClientResponseFilter {
>>>>>> ClientResponse filter(ClientRequest request, ClientResponse
>>>>>> response);
>>>>>> }
>>>>>>
>>>>>> Then we can have an abstract class as follows:
>>>>>>
>>>>>> public abstract class ClientFilter implements
>>>>>> ClientRequestFilter,
>>>>>> ClientResponseFilter {
>>>>>> public ClientRequest filter(ClientRequest request) {
>>>>>> return request;
>>>>>> }
>>>>>>
>>>>>> public ClientResponse filter(ClientRequest request,
>>>>>> ClientResponse response) {
>>>>>> return response;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> and modify all existing filters supported by Jersey to extend
>>>>>> from the
>>>>>> new ClientFilter. That way we can ensure that existing source
>>>>>> that
>>>>>> uses the Jersey supplied filters to add instances to Client or
>>>>>> WebResource is still compatible (i strongly suspect binary
>>>>>> compatibility will be broken so a recompile would be required).
>>>>>>
>>>>>> The ClientHandler interface is still relevant for
>>>>>> implementations of
>>>>>> HTTP clients (HttpURLConnection, Apache HTTP clent, and in
>>>>>> memory-
>>>>>> client). But we will require an AsyncClientHandler to implement
>>>>>> if
>>>>>> async request/response processing is supported:
>>>>>>
>>>>>> public interface AsyncClientHandler {
>>>>>> void handler(ClientRequest r, ClientResponseListener l);
>>>>>> }
>>>>>>
>>>>>> public interface ClientResponseListener {
>>>>>> void onError(Throwable t);
>>>>>>
>>>>>> void onResponse(ClientResponse cr);
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> After I wrote the above I realized there is the possibility for
>>>>>> an
>>>>>> alternative solution that will limit breaking changes to the
>>>>>> async
>>>>>> parts of the API. Thus existing filters used with the non-async
>>>>>> parts
>>>>>> will not be affected.
>>>>>>
>>>>>> It should be possible to retain the stack-based approach for
>>>>>> non- async
>>>>>> support and modify the existing filters to support stack and
>>>>>> non- stack
>>>>>> approaches by filters extending from the following class:
>>>>>>
>>>>>> public abstract class ClientRequestResponseFilter extends
>>>>>> ClientFilter, ClientRequestFilter, ClientResponseFilter {
>>>>>> public ClientResponse handle(ClientRequest request)
>>>>>> throws ClientHandlerException {
>>>>>>
>>>>>> request = filter(request);
>>>>>>
>>>>>> response = getNext().handler(cr);
>>>>>>
>>>>>> return filter(response);
>>>>>> }
>>>>>>
>>>>>> // state associated with request filter which needs to be
>>>>>> accessed by response filter
>>>>>> // must be added as a property on the request, a thread local
>>>>>> cannot be used because
>>>>>> // the response filter may be processed on a different
>>>>>> thread to
>>>>>> the request filter.
>>>>>> public ClientRequest filter(ClientRequest request) {
>>>>>> return request;
>>>>>> }
>>>>>>
>>>>>> public ClientResponse filter(ClientRequest request,
>>>>>> ClientResponse response) {
>>>>>> return response;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> However there is an issue if instances of ClientFilter (that
>>>>>> are not
>>>>>> instances of ClientRequestResponseFilter) are added to the filter
>>>>>> chain of Client, which are then utilized by a AsyncWebResource.
>>>>>> This
>>>>>> will render inoperable efficient async operation. Under such
>>>>>> circumstances we could easily generate a warning.
>>>>>>
>>>>>> Paul.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>