On 12/04/12 13:46, 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.
As long as it is possible to get one filter passing the properties to
the next one then it should be OK, as far as various cases involving the
collaboration of filters are concerned, sorry - going to review the
latest code in the next few days
Cheers, Sergey
> Why would the resource business logic deal with cryptographic keys directly? Perhaps I don't understand the exact use case you have in mind?
>
>
> Marek
>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>