On 17.04.2012, at 13:36, 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;
+1 But: why @Context and not @Inject?
>
> Marek
>
>>
>> Bill
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>