On 13/04/12 17:09, Bill Burke wrote:
>
>
> 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);
Why not ? I see Marek may not like adding a method like this to the
immutable Response interface, I can see his point, but this method is
clearly not about updating the actual HTTP response (status, headers,
representation) and is simple to implement so may be...
Sergey
>
> 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
>