On 4/17/12 7:36 AM, Marek Potociar wrote:
>
> On Apr 13, 2012, at 12:32 AM, Bill Burke wrote:
>
>>
>>
>> On 4/12/12 8:46 AM, Marek Potociar wrote:
>>>
>>> On Apr 11, 2012, at 7:32 PM, Bill Burke wrote:
>>>
>>>>
>>>>
>>>> On 4/11/12 8:04 AM, Marek Potociar wrote:
>>>>>>> My understanding is that properties are for communication between
>>>>>>> filters and handlers, i.e. properties are part of each single
>>>>>>> request context but not part of the request or response objects
>>>>>>> in the context. What is the use case for having the properties
>>>>>>> available in the response?
>>>>>>>
>>>>>>
>>>>>> Well, you may need to pass information to WriterInterceptors. for
>>>>>> example, if you want to sign or encrypt the entity, you might want
>>>>>> to pass through a cryptographic key.
>>>>>
>>>>> Interceptors can already access the properties via context.
>>>>>
>>>>
>>>> How would application code be able to pass the cryptographic key
>>>> into response processing without a properties map on Response? On
>>>> the client side, the Configuration is available to pass through
>>>> per-request objects. There's nothing available on the server side.
>>>
>>> I thought you would do the encryption via filters only. Why would the
>>> resource business logic deal with cryptographic keys directly?
>>> Perhaps I don't understand the exact use case you have in mind?
>>>
>>
>> Well, we have a content-signature header (DOSETA) that was support.
>> You may or may not want to sign the entity depending on the resource.
>> What key you use may require logic specific to the request/resource.
>> This is just one example though.
>
> Ok, got it.
>
>> But that's besides the point. I think a way to propagate per-request
>> config/metadata is essential. I don't understand why you are balking
>> at this so vehemently. Its a very simple addition.
>
> I am not against the addition per se. I am just not happy about the
> proposed solution. Adding a mutable method to an existing immutable API
> feels wrong. I am thinking that we could make this information
> injectable. (E.g. in Jersey we have FeaturesAndProperties injectable
> interface that we use exactly for this purpose.) Since I am seeing some
> common aspects with client.Configuration, perhaps we can extract a
> common super-interface from there and make it injectable? E.g.
>
> public interface Configuration {
> Map<String, Object> getProperties();
> Object getProperty(String name);
> Configuration setProperties(Map<String, ? extends Object> properties);
> Configuration setProperty(String name, Object value);
>
> /// perhaps we can make Feature part of the common API too?/
> Set<Feature> getFeatures();
> boolean isEnabled(Class<? extends Feature> feature);
> Configuration enable(Feature feature) throws IllegalStateException;
> Configuration disable(Class<? extends Feature> feature) throws
> IllegalStateException;
> }
>
> public interface ClientConfiguration extends Configuration { ... }
>
> Alternatively, we could also make the mutable properties map injectable
> itself. E.g.
>
> @Context Map<String, Object> properties;
>
> or with a qualifier (better aligned with JSR-330, JSR-299 injection style)
>
> @Context @Properties Map<String, Object> properties;
> @Context @Property("foo") Object fooValue;
>
> or using a custom injection annotation (better aligned with JAX-RS
> injection style)
>
> @Properties Map<String, Object> properties;
> @Property("foo") Object fooValue;
>
I'm fine with whatever. But, having Configuration on server-side, you'll
have to really specify the semantics. I never really liked the idea of
allowing the user to enable/disable features per-request. Being able to
do it in the middle of a request is even more sticky.
BTW, in the client side, adding properties disrupts the "flow", but this
is a separate discussion.
Invocation.Builder builder = target.request();
builder.getConfiguration().setProperty(...);
builder.....get();
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com