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.
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.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com