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).
Paul.
> Marc.
>
>>
>>>
>>>
>>>> Right, that is what i am hoping, need to verify if it works.
>>>> There is also another possible option: the jersey matching
>>>> algorithm returns false if nothing can be served for the request
>>>> (which then results in a 404) so a false could imply do
>>>> "chain.doFilter(req, res)". That, however, requires more work to
>>>> integrate.
>>>>
>>> That would also be less efficient since you'd have to run through
>>> the jersey matching algorithm before serving every static file...
>>>
>>
>> I agree.
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>