Hi all,
Just to add to this thread and get some clarification.
Is the bottom line now that I cannot use Jersey with static resources? I was
hoping to replace Struts 2 (which I mainly use for MVC rather than the
extraneous stuff) with Jersey in a new project and consider my dismay when I
realised that if I set Jersey to map to /* then I could not serve ANY static
resources.
In Struts 2, all I had to do was add a filter before the Struts 2 filter to
just forward to the static resource (JS, CSS, Image) etc.
With Jersey using a servet in web.xml I figured this is not possible at all.
In summary, is there an easy way to have Jersey as my "main" web framework
and have it handle (or not handle and just pass through to Tomcat), requests
for *.js , *.css etc?
Paul Sandoz wrote:
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
--
View this message in context: http://n2.nabble.com/Static-references-from-JSP-tp794843p2249825.html
Sent from the Jersey mailing list archive at Nabble.com.