jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: properties, Invocation, Client, and Resource

From: Bill Burke <bburke_at_redhat.com>
Date: Wed, 08 Jun 2011 09:52:09 -0400

On 6/8/11 9:35 AM, Santiago Pericas-Geertsen wrote:
>
> On Jun 7, 2011, at 6:51 PM, Bill Burke wrote:
>
>> One thing I've found a need for is for interceptors to be able to access properties set on the Client and/or WebResource instance. For example a digital signature interceptor would want access to the private key to sign a request with. A private key might be set for each request, or might be set as a default property on the Client (or WebResource).
>>
>> The way I've done it within Resteasy is that each Invocation/ClientRequest's property map is a copy of the Client's property map. Then, the interceptor only has to access the Invocation's property map and will either get something specific to the request, or defaulted at the Client level.
>>
>> Get what I'm saying? Or is my explanation horrible?
>
> Is this something we can specify in the javadoc for Invocation.getProperties() and BaseContext.getProperties()?
>

Yes. But also I'd like to brainstorm a little bit more about this.


For example, maybe this is yet another way to bind an interceptor. An
interceptor could get a callback with a properties map and decide
whether or not to apply itself.

Or maybe we need a Feature interface that has a callback SPI so
interceptors and other providers could be added.

i.e.

public interface Feature<SPI>
{
   String getName();

   void bind(SPI spi);

   void bind(Class declared, java.lang.reflect.Method method, SPI spi);
}

the SPI interface would be an interface to register
providers/interceptors. The Feature instance, on the server side, could
check to see if an annotation is applied to a JAX-RS method and apply
one or more filters/interceptors. It could look at a Client's
properties list to determine how to configure a set of interceptors on
the client side. You following me? THen the app or framework developer
has a bit more control over things and a central place to manage a
feature. Over time the SPI can be expanded to give more flexibility to
the feature developer.



> -- Santiago
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com