Hi James,
What if we could detect if a 404 would be returned, and if so proceed
to the next filter in the chain?
This may result in the execution of some user code e.g. execution of
sub-resource location methods could be a definite possibility. But is
that an issue? and for the case you present it should work really well.
Off the top of my head there are three types of 404 we could detect:
1) No match of a URI path;
2) A query or path param conversion failure; and
3) An application return an 404, by an exception or a direct response.
Maybe these cases could be configuration options?
Paul.
On Mar 11, 2010, at 11:41 AM, James Strachan wrote:
> Specifying the regex when using the JerseyFilter is great; so you can
> poke holes in your URI space and let Jersey leave it to the servlet
> container to render static resources or templates or other servlets
> etc.
>
> However in the case where you define your URIs nicely so that Jersey
> can know for sure whether a URI is in the JAXRS URI space or not;
> should it be necessary?
>
> The background to this is I've been hacking on a few Jersey web apps
> where the JAXRS resources are quite clean - e.g. mapping just "/" and
> "/foo/*" to JAXRS and the rest is all stuff like CSS, images, static
> HTML, general templates etc. Now and again I find myself adding, say,
> a new directory of CSS or images or whatever and finding things don't
> render - then realising I've gotta mess with the Jersey regex to get
> it to ignore certain URI patterns.
>
> So I just wondered; can Jersey easily know for sure that a URI is
> really outside the available JAXRS URI templates and just pass it
> straight to the servlet engine? Its not a major issue, it just avoids
> those head scratching moments when you forget all about having to hack
> the WebPageContentRegex property in your web.xml
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>