On Thu, 2008-11-13 at 12:12 +0100, Paul Sandoz wrote:
> Hi Craig,
>
> We now have a mechanism in place such that it is possible to easily
> proxy classes. A special proxying implementation could support filters
> in a independent manner to the rest of the Jersey framework. However,
> i don't know the details on how to proxy a general class, i am sure it
> is possible though :-) just a matter of getting the time...
e.g. cglib [1] can be used for proxying of classes that do not implement
any interfaces (cglib is also used by spring, docs on spring's proxying
mechanisms can be found at [2]).
cheers,
martin
[1]
http://cglib.sourceforge.net/
[2]
http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-proxying
>
>
> >
> >
> > Maybe there is another way to accomplish what I'm trying to do and I
> > just don't know of the feature. Is there anyway to tie a pre and/or
> > post method to a particular rest resource call? I assumed that's
> > the point of the filter but I thought I should ask to just make sure
> > I'm not missing something.
> >
>
> The only current way would be to use method-level interceptors of an
> IoC framework like Spring, Guice or WenBeans, or use EJBs.
>
> Note that in any use of such filters there may be restrictions on the
> modification of the request state. For example if Jersey has decided
> that a sub-resource locator method has been matched then an associated
> filter that modifies the request URI will not have any effect on the
> invocation of the locator.
>
> Paul.
>
> > Thanks again
> > Craig Iverson
> >
> >
> >
> > Date: Wed, 22 Oct 2008 09:51:54 +0200
> > From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> > Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
> > Subject: [Jersey] Filter configuration feature
> >
> >
> > On Oct 21, 2008, at 8:12 PM, Craig Iverson wrote:
> >
> > > Paul,
> > >
> > > That would work for me I believe. I wonder how the filters that are
> > > annotated would work with the list described in the web.xml. Could
> > > the ones in the web.xml be the default and only used if no filters
> > > are annotated? Could you also support an empty list
> > > (@RequestFilters({})) which would not apply any filters, not even
> > > the ones in the web.xml. This would basically allow the exclude
> > > functionality I would like.
> > >
> > > I've seen lots of feedback on this issue so I'm not sure where your
> > > opinions lie at this point.
> >
> >
> > My opinion is that we should not be duplicating functionality if we
> > can reuse that which is in EE. So i am reluctant to implement an
> > annotation based solution as we can reuse EJB interceptors or the EJB
> > security model. The only downside of this is that we have to wait a
> > little to experiment with EJB 3.1. You can use EJB 3.0 today with
> > Jersey. Just register the remote or local interface and Jersey will
> > look up the instance using JNDI. But i think it is only when EJB 3.1
> > is ready (no interfaces, include in war) that is starts to become much
> > easier to use with JAX-RS in the Web tier to avail of the most
> > interesting attributes that EJB offers.
> >
> > However, i think filters targeted to specific root resource classes
> > and declared in the web.xml seems reasonable. I am still not sure
> > about exclusion, the reason being is a filter in a filter chain may be
> > declared in a specific and dependent order, where the removal of that
> > filter causes things to break. In any case could you log an issue
> > related this and we can discuss further?
> >
> > Thanks,
> > Paul.
> >
> >
> >
> > > If you want I can open up a bug/feature for this.
> > >
> > > Craig
> > >
> > > Date: Fri, 17 Oct 2008 09:44:42 +0200
> > > From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> > > Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
> > > Subject: [Jersey] Filter configuration feature
> > >
> > >
> > > 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() { ... }
> > > }
> > >
> > > Paul.
> > >
> > > >
> > > > Craig
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
--
Martin Grotzke
http://www.javakaffee.de/blog/