On Jan 28, 2009, at 6:30 PM, James Strachan wrote:
> 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.
>
Thanks,
Paul.
>
> 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/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>