On 4/13/12 7:53 AM, Sergey Beryozkin wrote:
> Hi Bill
> On 12/04/12 23:32, 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.
>>
>> 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 wonder if that would introduce an inconsistency similar to the one we
> talked about earlier on, which you highlighted, where one would build
> Response with the builder but then be able to modify Response headers.
>
Well, I just want the simple ability to pass config/metadata back
through the response chain from application code. If you have a better
way, I'm all ears. It will be useful on the server side and the client
request side already has this ability.
Invocation.Builder.configuration.setProperty(name, value);
would be cool if you could do on server side:
return Response.ok(entity, "text/plain").property(name, value).build();
or
Response res = Response.ok(entity, "text/plain").build();
res.getProperties().put(name, value);
Another option would be to model after HttpServletRequest.getAttribute()
and add a properties map to Request
interface Request {
Map<String, Object> getProperties(); // mutable map of shared
filter/interceptor properties
}
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com