[jax-rs-spec users] [jsr339-experts] Re: Properties in Response object WAS Re: Re: Re: Review of new Filter API

From: Bill Burke <>
Date: Fri, 13 Apr 2012 12:09:44 -0400

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();


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 Burke
JBoss, a division of Red Hat