Hi,
On Jan 31, 2009, at 2:13 PM, sarat.pediredla wrote:
>
> 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.
>
I know :-(
> 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.
>
Did you write this filter yourself? Is the filter independent of any
Struts2 APIs?
If so it should be possible to reuse that filter to occur before the
Jersey servlet, just as you configured the filter to occur before the
Struts 2 filter.
Would you be willing to share the code of such a filter? as it would
help me write/include such a filter for Jersey.
> 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?
>
Currently the easiest approach is to make your base URLs for your
static resources different to that of the Jersey servlet. Namely, in
your web.xml for the Jersey servlet do not use "/*" but use say "/
resources/*".
Paul.
>
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>