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.
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.
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
>