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/