Hi Bill,
Its quite straight forward. Any limitations compared to the current suggestion?
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Sat, May 21, 2011 at 12:34 AM, Bill Burke <bburke_at_redhat.com> wrote:
> I put together an alternative client API to:
>
> * Simplify things
> * Expand interceptor model
> * Have interceptor model work in an asynchronous environment
> * Start work on server-side interceptor model
> * rework asynchronous callback model
>
> https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals
>
> Examples:
>
> https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals/tree/master/src/jax-rs-api/src/main/java/javax/ws/rs/client/examples
>
> The examples contain basic, async, and a gzip encoding/decoding example, and
> a client cache example.
>
>
> There's 4 different types of interceptors in the proposal:
> * RequestHander - executed before a request is dispatched to HTTP engine
> * ResponseHandler - Executed after HTTP engine returns, but before entity
> unmarshall
> * ReaderInterceptor - wraps around MessageBodyReader
> * WriterInterceptor - wraps around MessageBodyWriter
>
> Execution order looks like this:
>
> 1. RequestHandler's executed. If a ClientResponse is returned by any of
> these, use that response, and don't go remote.
>
> 2. Execute HTTP remotely. If there are WriterInterceptors, wrap them around
> call to MessageBodyWriter
>
> 3. ResponseHandler's executed.
>
> 4. ClientResponse.getEntity() invoked. If there are ReaderInterceptors wrap
> them around call to MessageBodyReader
>
>
>
> Steps 1, 2, 3, and 4 can all be executed in different threads if the runtime
> desires since I've split interception into request/response/readers/writers.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>