users@jersey.java.net

Re: [Jersey] Static references from JSP

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 29 Jan 2009 14:01:33 +0100

On Jan 29, 2009, at 1:54 PM, James Strachan wrote:

> 2009/1/29 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>> On Jan 29, 2009, at 12:49 PM, James Strachan wrote:
>>
>>> 2009/1/29 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>>>
>>>> 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,
>>>
>>> BTW if you've any experimental Jersey Filter implementation code sat
>>> on your hard drive or somewhere on the interwebs, I'd be happy to
>>> tlnker with it to see if I can get it to work & submit it back as a
>>> patch
>>>
>>
>> OK. The only location it is in at the moment is a dark gestating
>> corner of
>> my brain :-)
>
> :) sorry - I thought I read you or Paul had some filter code you were
> tinkering with - no worries.
>
>
>> I am going to write some experimental filter soon. The initial
>> approach i
>> will take is a list of regexes to static content. It is much easier
>> to
>> implement and verify that way.
>
> That would be great :)
>
>
>> Note that deferring to Jersey first may
>> involve execution of application code for sub-resource locators and
>> i am not
>> sure that is a good idea to allow that.
>
> 'global' static content (outside of the mapped URI space of JAX-RS)
> such as top level JSPs, CSS, images, JavaScript files should never
> conflict with the regular expression for the root resources; so you'd
> never have to navigate into sub-resource locators?
>
> Or to say that in a different way; if you define your URIs properly so
> that static resources are cleanly separated from your JAX-RS
> resources, you'll have a super fast & efficient filter. If you put
> static resources inside the JAX-RS resource space then you could well
> be in Implicit View terratory so invoking application code for
> sub-resource locators sounds fine to me.
>
> From an end user perspective its a little cleaner if Jersey does the
> heavily lifting to figure out what URIs are outside of the JAX-RS URI
> space to avoid end users having to enumerate regex for static files,
> JSPs and other mapped servlets - though for now I'd be happy to
> specify it by hand :)
>
> Maybe (eventually) having both options configurable might be a good
> idea? i.e. folks might want to restrict what static content & JSP they
> allow to be exposed by specifying them explicitly via regex to
> Jersey's filter?

Yes, i see both approaches being useful.


>
>
>
>> I guess one annoying issue with static content is that it may not
>> be served
>> up using the same constraints as for resource classes. One may
>> require the
>> same auth/access restrictions to the static content. It would also
>> be nice
>> if static content can be associated in the same way as views of a
>> resource
>> class so it could be modular.
>
> Yeah. For textual resources (JS/CSS etc) I guess you could use
> implciti views to serve it - even if its entirely static (though
> performance obsessed folks might wanna avoid that).
>
>
>> P.S. I fully empathize with the 10 week old daughter experience. I am
>> currently experiencing the 16 month old daughter with high fever.
>
> Yikes - hope she gets better soon!
>

Thanks, me too :-)

Paul.