users@jersey.java.net

Re: [Jersey] RE: Resource method interceptor

From: Samuel Le Berrigaud <samuel.lb_at_gmail.com>
Date: Fri, 13 Feb 2009 08:40:50 +1100

Hi Alex,

as I understand it those filter are not interceptor hence the problem
you mention. With "real" interceptor you could do whatever you want
regardless of exceptions being thrown etc. It would certainly be
useful in some use cases. However I don't need that for my case. All I
need is to introspect the resource that is being called juts before it
is being called to prevent its execution if its criteria don't match
my security concerns. Throwing and exception in the filter allows me
to do just that.

SaM

On Thu, Feb 12, 2009 at 11:15 AM, Roytman, Alex <Roytmana_at_peacetech.com> wrote:
> Hello Samuel,
>
> Have you checked how exceptions in Resource or one of prior ContainerResponseFilter (whether attached to a Resource method or global) will affect your filter. I have not tested ResourceFilterFactory provided filters but exception in a global filter or in resource itself definitely interrupt response chain thus your filter might not be executed.
>
> See my post "ContainerResponseFilter is not suitable for cleanup job"
>
> What's your experience?
>
> Thanks,
> Alex
>
>
> -----Original Message-----
> From: Samuel Le Berrigaud [mailto:samuel.lb_at_gmail.com]
> Sent: Tuesday, February 10, 2009 9:18 PM
> To: Jersey Users
> Subject: Resource method interceptor
>
> Hi all,
>
> I was trying to figure out if there was some sort of
> ResourceInterceptor API avialable for Jersey. I couldn't find anything
> apart from the container request and response filters and they don't
> quite match my requirements.
>
> Ideally what I'd like is an interface that I could implement and that
> would let me do things before, after and possibly even instead of the
> resource method being called. It would probably give me the method, it
> argument and the object on which it is being called as arguments.
>
> That would really help implement some "cross-cutting" concerns to our
> REST APIs in a simpler way than using AOP.
>
> Hope this make sense.
> Thanks,
>
> SaM
>