users@jersey.java.net

Re: [Jersey] [PATCH] SpringServlet doesn't quite work with Servlet Filters

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 17 Feb 2009 18:11:26 +0100

On Feb 17, 2009, at 5:59 PM, James Strachan wrote:

> Great stuff - that works like a charm - many thanks Paul!
>
Phew!

Paul.

> 2009/2/17 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>> Hi,
>>
>> I have committed a fix, and added unit tests related to the copying
>> of init
>> params to the resource config. Hopefully this one will work for you.
>>
>> I am in the process of building Camel, but there are an enormous
>> quantity of
>> dependencies :-) so it is taking time...
>>
>> It possible to set the properties on your resource config impl if
>> you wish,
>> and now (with the fix) they will take precedence over init-params
>> in the
>> web.xml (if present).
>>
>> Paul.
>>
>> On Feb 17, 2009, at 3:34 PM, James Strachan wrote:
>>
>>> 2009/2/16 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>>>
>>>> On Feb 16, 2009, at 2:31 PM, James Strachan wrote:
>>>>
>>>>> 2009/2/16 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>>>>>
>>>>>> On Feb 16, 2009, at 11:37 AM, James Strachan wrote:
>>>>>>
>>>>>>> Just a heads up - I spotted this when trying to use
>>>>>>> SpringServlet as a
>>>>>>> Servlet Filter and have submitted a fairly minor patch to fix
>>>>>>> it...
>>>>>>> https://jersey.dev.java.net/issues/show_bug.cgi?id=217
>>>>>>>
>>>>>>> Its a fairly minor issue - mostly due to WebComponent having a
>>>>>>> different ServletContext field to ServletContainer which
>>>>>>> should maybe
>>>>>>> be refactored a little to avoid similar issues surfacing.
>>>>>>>
>>>>>>
>>>>>> Thanks. Doh, that is embarrassing.
>>>>>>
>>>>>> I am going to fix this a long with another issue related to Guice
>>>>>> integration that Gili found [1], which requires that an HTTP
>>>>>> servlet
>>>>>> implementation implement HttpServlet, which IMHO is wrong because
>>>>>> Servlet
>>>>>> is
>>>>>> the contract for invocations not HttpServlet and the latter
>>>>>> IIUC is not
>>>>>> MUST
>>>>>> requirement.
>>>>>>
>>>>>> Given the Guice discussion i doubt the Guice developers will
>>>>>> change
>>>>>> things.
>>>>>> So i am going to make ServletContainer re-implement HttpServlet
>>>>>> and
>>>>>> encapsulate WebComponent.
>>>>>
>>>>> Great stuff thanks!
>>>>>
>>>>> BTW I spotted one more minor issue; when using the SpringServlet
>>>>> as a
>>>>> servlet filter, the regex pattern never seems to be initialised.
>>>>>
>>>>> I had to add this extra if clause into the configure() method of
>>>>> ServletContainer (which takes a FilterConfig)
>>>>>
>>>>> String regex =
>>>>> (String)rc.getProperty(PROPERTY_WEB_PAGE_CONTENT_REGEX);
>>>>> if (regex == null || regex.length() == 0) {
>>>>> regex =
>>>>> fc.getInitParameter(PROPERTY_WEB_PAGE_CONTENT_REGEX);
>>>>> }
>>>>>
>>>>> as the rc.getProperty() was returning null. Not sure if this is
>>>>> evidence of other issues when using servlet filters; e.g. should
>>>>> all
>>>>> the Filter's init parameter values be copied into the
>>>>> ResourceConfig
>>>>> abstraction or something?
>>>>>
>>>>
>>>> Hmm.... i just tested with my re-factored stuff and it works
>>>> fine. I
>>>> temporarily modified the spring-annotations sample to be a filter
>>>> with
>>>> init-param.
>>>
>>> Did you try serving up some static content?
>>>
>>>
>>>> We need some unit tests within the test framework... need to work
>>>> out how
>>>> to
>>>> configure Grizzly to work with filters.
>>>
>>> +1 :)
>>>
>>>
>>>> Not quite sure why it fails for you as the SpringServlet does not
>>>> modify
>>>> that behavior, and the init params should get added if they are
>>>> associated
>>>> with the ServlerConfig or the FilterConfig as abstracted by the
>>>> WebConfig
>>>> instance created for the init of Servlet or Filter respectively,
>>>> the code
>>>> path to add them is the same.
>>>>
>>>> I just committed fixes for issues 217 and 219.
>>>
>>> Great!
>>>
>>> I've tried building a clean checkout of trunk locally and it still
>>> fails for me - but then adding back my previous extra if statement
>>> and
>>> it works again.
>>>
>>> Here's a test case if you wanna experiment with your local build of
>>> jersey...
>>>
>>> If you check out this...
>>>
>>> svn co https://svn.apache.org/repos/asf/camel/trunk/ camel
>>>
>>> and build it locally (this step might not be necessary, just not
>>> sure
>>> if it'd download all the required jars)
>>> mvn -Dtest=false -DfailIfNoTests=false clean install
>>>
>>> then type
>>>
>>> cd components/camel-web
>>> mvn test -Dtest=StaticContentTest
>>>
>>> Without that patch of mine I get this test failing with a 404 when
>>> trying to get /css/site.css as it doesn't recognise the regex in the
>>> web.xml
>>>
>>> https://svn.apache.org/repos/asf/camel/trunk/components/camel-web/src/main/webapp/WEB-INF/web.xml
>>>
>>> I wonder if my issue is related to using more than one filter? I'm
>>> using SiteMesh with this test case to style the HTML output. I've
>>> tried switching them around and the effect is the same - it fails
>>> without my patch but works with it.
>>>
>>> We definitely need more test cases :)
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://fusesource.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
>>
>>
>
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>