On 8/23/2012 12:38 PM, Marek Potociar wrote:
>
> On Aug 23, 2012, at 5:03 PM, Bill Burke <bburke_at_redhat.com
> <mailto:bburke_at_redhat.com>> wrote:
>
>>
>>
>> On 8/23/2012 8:06 AM, Marek Potociar wrote:
>>> Btw. seems to me that dynamically bound global filter that has all
>>> the necessary resource-specific initialization properties (e.g.
>>> ResourceInfo etc.) pre-computed at deploy time will be anyway more
>>> efficient than a global post-matching filter that will need to inject
>>> proxied resource information with every request.
>>>
>>
>> Ya, we precompute post match request filters and response filters and
>> reader/writer interceptors at deploy/redeploy time.
>
> I wonder what do you do for sub-resources? That's something that cannot
> be generally pre-computed, right?
>
Can't precompute at deploy time, no, but we cache mappings and other
metadata based on class on demand. Otherwise sub-resource invocations
would be really inefficient.
> What about the distinction between pre-post matching request filters? Do
> we need that at all? Can we just have all "unbound" filters pre-matching
> and all name-bound or dynamically-bound post-matching?
I don't think we can do that (remove @PreMach). For example, something
like @RolesAllowed is a name-bound filter and authorization should
really come before as many filters as possible, don't you think?
(Note that
> name-bound can be applied to the Application class which would make them
> global & post-matching by default.)
Can you explain more what you're talking about with Application class?
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com