Hi Paul,
The filter I use is actually from the appfuse project at
http://appfuse.org
called StaticFilter. All it does is, prevents any requests to static content
to reach the Struts 2 filter. This works in that case because Struts 2
actually works by adding a filter and not a servlet mapping, which means you
can over-ride this filter with a higher priority filter.
If you Jersey could be invoked as a Filter as opposed to a Servlet mapping,
this would solve most of my pains.
Paul Sandoz wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> 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-tp794843p2257429.html
Sent from the Jersey mailing list archive at Nabble.com.