users@jersey.java.net

Re: [Jersey] Static references from JSP

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 27 Jan 2009 11:53:49 +0100

Hi,

I have forwarded this email to the relevant people.

James, Craig, as of Servlet 2.5 is it possible to utilize a filter
from which we decide to forward to static files or JSP pages or
forward to Jersey?

For example,

    void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) {
        if (request is for Jersey) {
            forward request to Jersey
        } else {
            // Handle static files and JSPs
            chain.doFilter(req, res);
        }
    }

Paul.

On Jan 27, 2009, at 11:00 AM, James Strachan wrote:

> 2009/1/26 Craig McClanahan <Craig.McClanahan_at_sun.com>:
>> Julio Faerman wrote:
>>
>> Perhaps the servlet (or future filter) could receive a "ignore"
>> pattern as a init-param, that when matched would delegate the
>> request.
>>
>>
>>
>> With the servlet api as it is today (<= 2.5), this won't actually
>> work :-(.
>>
>> What "delegate the request" means, in terms of servlet, is to use a
>> RequestDispatcher to let the servlet container choose the correct
>> servlet to
>> handle the request. And, because of the servlet mappings, it is
>> going to
>> give the request right back to the Jersey servlet again ...
>>
>> Surprisingly, it doesn't appear that this issue has yet been
>> addressed in
>> the ongoing Servlet 3.0 work (public draft recently got
>> published[1]). The
>> current text on allowed url patterns appears not to have changed
>> (although
>> the proposal is that you can use web.xml, annotations, or
>> programmatic calls
>> on ServletContext to configure the mappings).
>>
>> Craig
>>
>> [1] http://jcp.org/aboutJava/communityprocess/pr/jsr315/index.html
>
> Maybe we should raise an issue on the servlet 3 spec as its a pretty
> major flaw IMHO. I'm sure it would be possible to add a minor change
> to servlet 3.0 to solve this issue.
>
> One idea could be just to be able to define the servlet containers
> handlers as a name to be used in the servlet mapping - so you can
> explicitly map URIs to the default container servlets (whether its the
> containers FileServlet or JSP processing servlet or whatever it is) to
> basically cookie cut holes in the URI space and let them be handled by
> the servlet container rather than your web apps servlets. e.g.
>
> <webapp containerHandler="Default" ...>
> ...
>
> <servlet-mapping>
> <servlet-name>Default</servlet-name>
> <url-pattern>/css/*</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Default</servlet-name>
> <url-pattern>/js/*</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Default</servlet-name>
> <url-pattern>/images/*</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Default</servlet-name>
> <url-pattern>*.jsp</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Jersey Web Application</servlet-name>
> <url-pattern>/</url-pattern>
> </servlet-mapping>
>
> So we explicitly map stuff we *don't* want to manage in the web app to
> the Default container's servlets, then catch all the rest in our
> Jersey servlet.
>
> Another option is to allow real regex to be used to map servlets to
> URIs; though I'm not sure if its possible to say don't match
> (.*\.jsp|//images//.*|//js//.*|//css//.*) in a regex :)
>
> --
> 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
>