On Tue, 2008-10-21 at 10:10 +0200, Paul Sandoz wrote:
> Hi Kevin,
>
>
> IIRC some people are using Spring AOP.
This should be no problem at all, just use spring AOP as you're used to
it.
The only requirement is - obviously - that subresources are not
instantiated directly (as then even spring cannot do any proxying) but
are fetched from the (injected) ResourceContext, via
MySubresource subresource = rc.getResource( MySubresource.class );
Required runtime-information then can be set on the subresource.
Cheers,
Martin
> Some are using the ComponentProvider iface to provide Java proxies.
>
>
> I want to support @RolesAllowed on methods. This area will improve for
> EE 6 integration. I want to avoid re-inventing a solution specific to
> Jersey if we can leverage EE 6 technologies like WebBeans and EJBs.
>
>
> Another solution is to demarcate your Jersey apps using Servlet and
> then use a servlet filter or web-based auth support.
>
>
> Paul.
>
>
>
> On Oct 21, 2008, at 1:31 AM, Kevin Duffey wrote:
>
> > Yes, a servlet filter could... I was thinking more along the lines
> > of some sort of annotation that you can pass the Authorization
> > header to and the method being invoked along with the authorization
> > header could be passed in, allowing a single method to control
> > whether or not the user is authorized to make a request to the
> > requested method. Not sure where to draw the line tho... when does
> > this start becoming annotation hell and no longer convenient.
> >
> >
> >
> >
> > ____________________________________________________________________
> > From: Craig McClanahan <Craig.McClanahan_at_Sun.COM>
> > To: users_at_jersey.dev.java.net
> > Sent: Monday, October 20, 2008 1:49:18 PM
> > Subject: Re: [Jersey] Filter configuration feature
> >
> > Kevin Duffey wrote:
> > > Hey all,
> > >
> > > I am curious if this discussion would include the ability to
> > provide
> > > some sort of cross-cutting "aop" like ability to check the
> > > Authorization header. I haven't looked at all the latest threads,
> > but
> > > one issue I am trying to figure out is how to avoid doing a
> > method
> > > lookup for authorization based on the auth header, in every one of
> > my
> > > API methods. Maybe Jersey supports some sort of web.xml
> > configuration
> > > that allows me to specify a method to call with the Authorization
> > > info... so that I can remove the same lookup code I have in every
> > one
> > > of my methods... or does this basically fit into the filter
> > > configuration discussion and thus is presently not possible?
> > >
> > Couldn't a servlet filter do this for you, since you're using a
> > servlet
> > based webapp?
> >
> > On the other hand, I can see how abstracting authentication could
> > be
> > useful ... but an authorization check might still need a per-method
> > call
> > anyway so that you know what operation you're trying to authorize.
> >
> > Craig
> >
> > >
> > > > Paul Sandoz wrote:
> > > >>
> > > >> On Oct 16, 2008, at 6:50 PM, Craig Iverson wrote:
> > > >>
> > > >>> First let me thank you for all the good work you guys are
> > doing
> > > >>> with jersey and jsr-311. It's been a pleasure to develop
> > against.
> > > >>
> > > >> Thanks!
> > > >>
> > > >>
> > > >>>
> > > >>> I have a feature request that I can add to the issue tracker
> > if
> > > >>> you agree.
> > > >>
> > > >> Please. No need to ask permission to log issues :-)
> > > >>
> > > >>
> > > >>> I think it would be great to be able to configure a filter
> > per
> > > >>> resource(s). In my case its even more than that, it would
> > be
> > > >>> more beneficial to also support an exclude list. I have a
> > case
> > > >>> where I only want certain filters applied to certain
> > resources. I
> > > >>> really want a couple of filters to always be applied except
> > for on
> > > >>> a couple of resources. The reason for the exclude list would
> > > >>> allow other team members to add resources without worrying
> > about
> > > >>> configuring the filter for the new resource. Your thoughts?
> > > >>
> > > >> Currently request and response filters are called before
> > resource
> > > >> matching is performed. Having filters apply to specific root
> > > >> resource classes could also make sense, but i wonder if the
> > exclude
> > > >> list complicates matters, especially if there is more then one
> > > >> filter present in the filter chain, rather than being explicit
> > and
> > > >> describing the list of resources with the list of filters e.g.
> > > >>
> > > >> Map<List<Class<??>, List<ContainerRequestFilter>>
> > > >>
> > > >> I am wondering if it is appropriate to have filters associated
> > with
> > > >> resources and resource methods configured from the resources
> > > >> themselves. How about allowing the following:
> > > >>
> > > >> @RequestFilters({A.class, B.class})
> > > >> @Path("resource")
> > > >> public class Resource {
> > > >>
> > > >> @RequestFilters({C.class, D.class})
> > > >> @GET
> > > >> public String get() { ... }
> > > >>
> > > >> @RequestFilters({E.class, F.class})
> > > >> @Path("sub-resource")
> > > >> public Object getSubResource() { ... }
> > > >> }
> > > >>
> > > > Just as a comparison point, this is conceptually pretty similar
> > to
> > > > how you can define interceptors on EJB session beans in the
> > bean
> > > > classes themselves:
> > > >
> > > > @Stateless
> > > > // Class level interceptors around all method calls
> > > > @Interceptors({TracingInterceptor.class})
> > > > public class MySessionBean {
> > > >
> > > > // Method level interceptors around calls to this method
> > > > @Interceptors({SomeInterceptor.class,
> > AnotherInterceptor.class})
> > > > public String result(String arg1, String arg2) {
> > > > ... business logic goes here ...
> > > > }
> > > >
> > > > }
> > > >
> > > > There are also some additional ideas in EJB interceptors that
> > might
> > > > be worth emulating:
> > > >
> > > > * @ExcludeClassInterceptors and @ExcludeDefaultInterceptors
> > > > to turn off normal interceptors for a particular class or
> > method.
> > > >
> > > > * @AroundInvoke to let you specify the logic of a class
> > interceptor
> > > > inline in the same class, rather than requiring it to be
> > separate.
> > > >
> > > > Of course, once you get into a world of multiple layers of
> > > > interceptors, the invocation order needs to be clearly defined
> > as
> > > > well.
> > > >
> > > > Craig
> > > >
> > > >
> > > >> Paul.
> > > >>
> > > >>>
> > > >>> Craig
> > > >>>
> > > >>>
> > ---------------------------------------------------------------------
> > > >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > > >>> For additional commands,
> > e-mail: users-help_at_jersey.dev.java.net
> > > <mailto:users-help_at_jersey.dev.java.net>
> > > >>>
> > > >>
> > > >>
> > > >>
> > ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > > >> For additional commands,
> > e-mail: users-help_at_jersey.dev.java.net
> > > <mailto:users-help_at_jersey.dev.java.net>
> > > >>
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > > <mailto:users-help_at_jersey.dev.java.net>
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > <mailto:users-unsubscribe_at_jersey.dev.java.net>
> > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > > <mailto:users-help_at_jersey.dev.java.net>
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
--
Martin Grotzke
Dipl.-Inf.
freiheit.com technologies gmbh
Straßenbahnring 22 / 20251 Hamburg, Germany
fon +49 (0)40 / 890584-0
fax +49 (0)40 / 890584-20
HRB Hamburg 70814
eb0e 645c 9730 c8a3 ee2f 1b9a 5de5 21cb c259 fe34
Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof