On Feb 2, 2009, at 12:20 PM, sarat.pediredla wrote:
>
> 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.
>
OK.
I thought filters are always invoked before a servlets thus filters
implicitly have a higher priority than a servlet. Is my assumption
wrong?
> If you Jersey could be invoked as a Filter as opposed to a Servlet
> mapping,
> this would solve most of my pains.
>
Yes, we plan to do that. Unfortunately we do not have time to
implement that for the 1.0.2 release but it will be in the 1.0.3-
SNAPSHOT and release.
Paul.
>
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>