Its kinda trivial but I've just submitted a little patch on the
bookstore sample to add a test case that a CSS file can be returned
properly (which currently fails)
https://jersey.dev.java.net/issues/show_bug.cgi?id=199
but when we have some kinda filter thingy I can send an updated patch
to the web.xml so that the test passes.
2009/1/28 James Strachan <james.strachan_at_gmail.com>:
> 2009/1/28 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>
>> On Jan 27, 2009, at 9:29 PM, Marc Hadley wrote:
>>
>>> On Jan 27, 2009, at 10:28 AM, Paul Sandoz wrote:
>>>
>>>>
>>>> On Jan 27, 2009, at 4:21 PM, Marc Hadley wrote:
>>>>
>>>>> On Jan 27, 2009, at 6:07 AM, Paul Sandoz wrote:
>>>>>>>
>>>>>>> Ah cool - so we could maybe specify a list of URI patterns for Jersey
>>>>>>> to ignore then right - and use Jersey via a filter rather than a
>>>>>>> Servlet mapping?
>>>>>>
>>>>> IIRC, the rails plug-in for glassfish is a filter and works in a similar
>>>>> way. Again IIRC it looks to see if there is a static resource that matches
>>>>> the request URI and if not it hands the request to rails.
>>>>
>>>> Got a pointer to the code?
>>>>
>>> Here you go:
>>>
>>>
>>> http://github.com/nicksieger/jruby-rack/blob/ff16e62b1348258c20a0b85d29bbecc1c1ad1c42/src/main/java/org/jruby/rack/RackFilter.java
>>>
>>
>> Thanks.
>>
>>
>>> I haven't studied it in detail but it looks like the filter tries to
>>> dispatch the request and if it results in an error (i.e. nothing else
>>> handled it) then it resets the response and re-dispatches to the ruby
>>> engine. Same approach should work for Jersey I'd think.
>>>
>>
>> Yes, if the response from the filter returns a status >= 400 then the
>> request is dispatched to the ruby ServletDispatcher.
>>
>> In this case any URLs referencing static files or JSP in the web pages would
>> take precedence over any URLs for resource classes. My guess is this could
>> be useful but it would still be useful to restrict when the filter chain is
>> invoked. For example, if there are implicit views as JSP pages then you
>> don't really want those JSP pages to be accessible directly, they are only
>> accessed by Jersey forwarding to them (i am assuming the filter would not be
>> re-invoked in such cases).
>
> For well-defined web apps, the JAX-RS URI paths and the static content
> & JSP paths are going to be mutually exclusive. e.g. you might bind /
> /bookstore /items/* to your resource beans and have /images/* /css/*
> /js/* help.jsp as your static/JSP resources with no possibility of
> overlap. You could consider overlap as being a URI bug.
>
> So how about this as a possible solution;
>
> * you don't map the Jersey servlet to the default / * or /* URIs at
> all, leaving the containers static & JSP handlers intact (if the
> servlet must be mapped at all it could be at /app or /jersey or
> something)
>
> * the Jersey filter then looks at the URI and tries to find a possible
> JAX-RS match to the URI, if it does, it invokes the Jersey servlet
> (these 2 steps could be optimised a little maybe to avoid 2 lookups
> etc)
>
> * if no jersey match is found its then just dispatched as normal into
> the servlet container for the default file / JSP handlers (or other
> custom servlets bound to a URI)
>
> I confess to not having much sleep thanks to my 10 week old daughter
> and I could use more coffee :) but this seems like it could work
> around many of these servlet issues and avoid Paul's concern of
> exposing unwanted resources?
>
> In effect this would be using the JAX-RS URI matching as the
> servlet-matching mechanism (which is nice and DRY) and totally
> bypassing the very limited servlet spec's URI matching mechanism -
> which until the servlet spec improves I think is a very good thing :)
>
> Thoughts?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/