Hi Craig,
Apologies for the late reply... this got pushed to the bottom of my
email message stack then got lost for a bit.
On Oct 24, 2008, at 3:08 AM, Craig Iverson wrote:
> Paul,
> I opened the bug and I could live with it in the web.xml. But this
> does bring up a concern, The last few places I've worked we've
> avoid j2ee/jee. Simply did not need its features or complexities.
> We relied on Jetty or tomcat. Typically we just used jpa and
> sometimes spring. So when you talk about not doing features because
> of jee it concerns me a bit. So please try to remember us j2se
> people. I'd love to see it be able to stand on its own with all the
> desired features without jee.
Point taken. BTW are you aware EE 6 is proposing certain profiles that
reduce the scope of features?
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...
>
>
> 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
>