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...
>>
>>>>
>>>>
>>>> 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com