On Aug 29, 2012, at 3:05 PM, Bill Burke <bburke_at_redhat.com> wrote:
> On 8/29/2012 8:55 AM, Marek Potociar wrote:
>
>>> I applaud your effort to reduce and refactor. Its a good discussion, but I'm not sure it can work.
>>
>> :) ok. very diplomatically put. (I applaud) :)
>>
>
> As you've probably noticed, being diplomatic is very difficult for me :) Apologies...
>
No problem. :)
>>>>> BTW, the way the cache is triggered by Response cache-control headers set by the application.
>>>>
>>>> I see. So you monitor all application responses and kick in based on presence of the cache-control header. Does it mean that you don't have a response filter that could be set and configured for each resource method and would take care of adding this cache-control header to the returned response?
>>>>
>>>
>>> A filter does not add a cache-control header, the application does. The response filter decides to cache based on whether the app set the cache-control header. Like I said, there's no reason i couldn't write a DynamicFeature that just forced the request filter to be name-bound, but it just seems wrong.
>>
>> Ok. Let's keep the @PreMatch then. I wish we would receive more feedback from EG on these topics (sigh).
>>
>
> BTW, there are other possible name-bound security models beyond @RolesAllowed, I think Drools and Spring have some complex security protocols that are applicable to JAX-RS, but I haven't looked into them deeply. Just sucks that both pre-match and security make this so complex.
Do you have in mind any concrete suggestion how to address that?
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com