I lean towards 1, because it's more future-proof and efficient. I'd
argue taking the hit now rather than dragging legacy for
who-knows-how-long. There's a clear case for the break, and I don't
think it will be unwieldy to modify existing filters to support the new
scheme.
On Wed, 2009-08-12 at 23:13 +0200, Paul Sandoz wrote:
>
> On Aug 12, 2009, at 7:59 PM, 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, Paul, which of the following options do you think is best ?
>
>
> 1) breaking changes to all filters, requiring that developers change
> their filter code; or
>
>
> 2)
> non-breaking changes, but any stack-based only filters utilized with an async request will result in non-optimal use
> of threads (if an HTTP client is capable of optimal async
> requests).
>
>
> I am leaning towards option 2.
>
>
> Paul.
>
>
>
>
> > 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
> > >
> > >
> >
> >
>