users@jersey.java.net

Re: Security Interceptors

From: Martin Grotzke <martin.grotzke_at_javakaffee.de>
Date: Tue, 25 Mar 2008 13:26:04 +0100

On Tue, 2008-03-25 at 11:51 +0100, Lars Tackmann wrote:
> On Sun, Mar 23, 2008 at 5:55 PM, Martin Grotzke
> <martin.grotzke_at_javakaffee.de> wrote:
> > Hi Lars,
> >
> > one thing I could think of is to implement your own component provider,
> > that checks if the class to instantiate has your @Interceptors
> > annotation or any method has e.g. your @Audit annotation. For these
> > classes you could return a proxied instance (e.g. using cglib), so that
> > you can intercept method invocations.
>
> Just out of curiosity if I do somthing such as:
>
> --
> @Path("{id}"/)
> public NestedResource getNestedResource(@PathParam("id") Long id) {
> NestedResource res = injector.getInstance(NestedResource.class);
> res.setId(id);
> res.setUriInfo(uriInfo); // similar with HTTPHeaders...
> return res;
> }
> --
>
> then the guice interceptors will come into play and let me intercept
> methods annotated with @Audit.
So this injector is an injected GuiceComponentProvider (a
ComponentProvider that integrates guice with jersey)?

> Now if Guice then could actually create
> the resources that Jersey handles today then I suppose I have a
> solution.
If the injector is your GuiceComponentProvider then the NestedResource
actually would be created by guice, if guice "knows about" the
NestedResource.
I'd say this should work...

Though, I personally would prefer s.th. like this:

@Path("{id}"/)
public NestedResource getNestedResource(@PathParam("id") Long id,
        @Inject NestedResource res) {
    res.setId(id);
    res.setUriInfo(uriInfo); // similar with HTTPHeaders...
    return res;
}

Cheers,
Martin

> I can of cause mix this with the provider hack but that
> seams to be a ugly mix.
>
> any thoughts ?
>