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?
> 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!
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/