Registering a Servlet Filter

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Registering a Servlet Filter

Vidar Ramdal-2
With regards to https://issues.apache.org/jira/browse/SLING-249, I'm
experimenting with solving that issue using a Servlet Filter.
However, I'm not sure how to register the filter with OSGi/Sling.

As far as I have understood, OSGi does not have a notion of filters. I
see that SlingMainServlet has some logic concerning filters, in
particular the bindFilter method, but it does not seem to be in use
anywhere in the Sling codebase.

I've also read http://incubator.apache.org/sling/site/request-processing.html#RequestProcessing-CoreRequestProcessing
but given that it is currently "out of sync", I'm not sure how much of
it is still current.

So, is there a way to use a servlet filter with Sling?

--
Vidar S. Ramdal <[hidden email]> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Bertrand Delacretaz
On Fri, Mar 28, 2008 at 4:52 PM, Vidar Ramdal <[hidden email]> wrote:
> ... So, is there a way to use a servlet filter with Sling?...

Yes, see the ZipFilter example:

http://svn.apache.org/repos/asf/incubator/sling/trunk/sling/sample/src/main/java/org/apache/sling/sample/filter/ZipFilter.java

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Vidar Ramdal-2
On Fri, Mar 28, 2008 at 9:07 PM, Bertrand Delacretaz
<[hidden email]> wrote:
> On Fri, Mar 28, 2008 at 4:52 PM, Vidar Ramdal <[hidden email]> wrote:
>  > ... So, is there a way to use a servlet filter with Sling?...
>
>  Yes, see the ZipFilter example:
>
>  http://svn.apache.org/repos/asf/incubator/sling/trunk/sling/sample/src/main/java/org/apache/sling/sample/filter/ZipFilter.java

Thanks, I got the filter running. However, in order for it to be
useful, I need to invoke it in a regular servlet container fashion -
that is, BEFORE any servlets get to handle the request.
The Sling (and I assume OSGi?) way is to let a servlet take care of
invoking filters. In Sling's case, that seems to be SlingMainServlet.

Now, this is not what I want, because
SlingMainServlet#service(HttpServletRequest, HttpServletResponse)
resolves the resource before invoking filters. My filter is designed
to manipulate the request so that Sling will resolve to a different
resource (based on the HTTP host header, as outlined in
https://issues.apache.org/jira/browse/SLING-249).

So I would like to let the filter process the request before
SlingMainServlet gets to it. How can I accomplish that (if possible)?


--
Vidar S. Ramdal <[hidden email]> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Bertrand Delacretaz
On Mon, Mar 31, 2008 at 2:34 PM, Vidar Ramdal <[hidden email]> wrote:

> ... So I would like to let the filter process the request before
>  SlingMainServlet gets to it. How can I accomplish that (if possible)?...

The easiest seems to be for your filter to be declared in web.xml.

I'd suggest first patching the launchpad/webapp web.xml to test your
idea, and if that works you could create your own webapp, either by
overlaying your own web.xml using the maven-war-plugin, or creating a
completely new webapp using the launchpad one as an example.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Felix Meschberger-2
Hi,

Am Montag, den 31.03.2008, 14:52 +0200 schrieb Bertrand Delacretaz:

> On Mon, Mar 31, 2008 at 2:34 PM, Vidar Ramdal <[hidden email]> wrote:
>
> > ... So I would like to let the filter process the request before
> >  SlingMainServlet gets to it. How can I accomplish that (if possible)?...
>
> The easiest seems to be for your filter to be declared in web.xml.
>
> I'd suggest first patching the launchpad/webapp web.xml to test your
> idea, and if that works you could create your own webapp, either by
> overlaying your own web.xml using the maven-war-plugin, or creating a
> completely new webapp using the launchpad one as an example.

This is certainly a possibility, but I would not go this route as it
leaves Sling and makes it impossible to be used in the standalone
launchpad/app case... In addition it is impossible to manage, ie
configure and updated the filter.

Rather we might want to find a way on how to get this to really
influence resource resolution.

Given this, it might probably be better enhance the resource resolver to
make it extensible in terms of resource resolution. Currently, we have
two hard coded resolution steps: vanity urls (just mapping the input
path to a nother path) and prefix handling (replacing path prefixes with
other prefixes).

We might amend this to make these steps optional and extensible ... I
could then imagine, that SLING-249 could then be a first use-case.

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Bertrand Delacretaz
On Mon, Mar 31, 2008 at 3:10 PM, Felix Meschberger <[hidden email]> wrote:

>  Am Montag, den 31.03.2008, 14:52 +0200 schrieb Bertrand Delacretaz:
>  >
>  > ...The easiest seems to be for your filter to be declared in web.xml....

>...  This is certainly a possibility, but I would not go this route as it
>  leaves Sling and makes it impossible to be used in the standalone
>  launchpad/app case... In addition it is impossible to manage, ie
>  configure and updated the filter....

Agreed - I was suggesting a "here and now" solution, but I agree that
it is not really integrated with Sling.

As I said before, though, I'm not too enthusiastic about SLING-249, as
httpd's mod_proxy handles that very nicely. I wouldn't add complexity
to Sling to handle that, unless that complexity is cleanly isolated in
a component like a filter.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Vidar Ramdal-2
On Mon, Mar 31, 2008 at 3:25 PM, Bertrand Delacretaz
<[hidden email]> wrote:

> On Mon, Mar 31, 2008 at 3:10 PM, Felix Meschberger <[hidden email]> wrote:
>
>  >  Am Montag, den 31.03.2008, 14:52 +0200 schrieb Bertrand Delacretaz:
>  >  >
>  >  > ...The easiest seems to be for your filter to be declared in web.xml....
>
>  >...  This is certainly a possibility, but I would not go this route as it
>
> >  leaves Sling and makes it impossible to be used in the standalone
>  >  launchpad/app case... In addition it is impossible to manage, ie
>  >  configure and updated the filter....
>
>  Agreed - I was suggesting a "here and now" solution, but I agree that
>  it is not really integrated with Sling.

OK - how about introducing a new filter.scope - e.g. "prerequest", and
alter SlingMainServlet so that it invokes "prerequest" filters before
passing the request to the ResourceResolver?

>  As I said before, though, I'm not too enthusiastic about SLING-249, as
>  httpd's mod_proxy handles that very nicely. I wouldn't add complexity
>  to Sling to handle that, unless that complexity is cleanly isolated in
>  a component like a filter.

Errr, I'm not too enthusiastic about mod_proxy :)
As mod_proxy would have to live outside Sling, it would not be able to
intercept sling.include requests.
So that a request from a browser to http://www.domain.com/path would
yield a different result than sling.include("/path"). In a perfect
world (tm), the host information would still be available for handling
the sling.include request.

--
Vidar S. Ramdal <[hidden email]> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Bertrand Delacretaz
On Mon, Mar 31, 2008 at 3:36 PM, Vidar Ramdal <[hidden email]> wrote:

> ... Errr, I'm not too enthusiastic about mod_proxy :)
>  As mod_proxy would have to live outside Sling, it would not be able to
>  intercept sling.include requests.
>  So that a request from a browser to http://www.domain.com/path would
>  yield a different result than sling.include("/path")....

Good point - I'm starting to be convinced ;-)

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Felix Meschberger-2
In reply to this post by Vidar Ramdal-2
Hi,

Am Montag, den 31.03.2008, 15:36 +0200 schrieb Vidar Ramdal:

> On Mon, Mar 31, 2008 at 3:25 PM, Bertrand Delacretaz
> <[hidden email]> wrote:
> > On Mon, Mar 31, 2008 at 3:10 PM, Felix Meschberger <[hidden email]> wrote:
> >
> >  >  Am Montag, den 31.03.2008, 14:52 +0200 schrieb Bertrand Delacretaz:
> >  >  >
> >  >  > ...The easiest seems to be for your filter to be declared in web.xml....
> >
> >  >...  This is certainly a possibility, but I would not go this route as it
> >
> > >  leaves Sling and makes it impossible to be used in the standalone
> >  >  launchpad/app case... In addition it is impossible to manage, ie
> >  >  configure and updated the filter....
> >
> >  Agreed - I was suggesting a "here and now" solution, but I agree that
> >  it is not really integrated with Sling.
>
> OK - how about introducing a new filter.scope - e.g. "prerequest", and
> alter SlingMainServlet so that it invokes "prerequest" filters before
> passing the request to the ResourceResolver?

Sounds interesting. Such a filter would be defined to get the original
request and response objects from the servlet container. That is they
would be HttpServletRequest/Response and not
SlingHttpServletRequest/Response.

Would that suit your needs ?

An issue with patch, would of course be very welcome ;-)

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Vidar Ramdal-2
On Mon, Mar 31, 2008 at 3:54 PM, Felix Meschberger <[hidden email]> wrote:

>  > OK - how about introducing a new filter.scope - e.g. "prerequest", and
>  > alter SlingMainServlet so that it invokes "prerequest" filters before
>  > passing the request to the ResourceResolver?
>
>  Sounds interesting. Such a filter would be defined to get the original
>  request and response objects from the servlet container. That is they
>  would be HttpServletRequest/Response and not
>  SlingHttpServletRequest/Response.
>
>  Would that suit your needs ?

Ah ... but this would be a catch 22, wouldn't it, as the sling.include
scenario will still be a problem:

> So that a request from a browser to http://www.domain.com/path would
> yield a different result than sling.include("/path").

Or am I missing something here?

--
Vidar S. Ramdal <[hidden email]> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway

Reply | Threaded
Open this post in threaded view
|

Re: Registering a Servlet Filter

Felix Meschberger-2
Hi,

Am Montag, den 31.03.2008, 16:07 +0200 schrieb Vidar Ramdal:

> On Mon, Mar 31, 2008 at 3:54 PM, Felix Meschberger <[hidden email]> wrote:
>
> >  > OK - how about introducing a new filter.scope - e.g. "prerequest", and
> >  > alter SlingMainServlet so that it invokes "prerequest" filters before
> >  > passing the request to the ResourceResolver?
> >
> >  Sounds interesting. Such a filter would be defined to get the original
> >  request and response objects from the servlet container. That is they
> >  would be HttpServletRequest/Response and not
> >  SlingHttpServletRequest/Response.
> >
> >  Would that suit your needs ?
>
> Ah ... but this would be a catch 22, wouldn't it, as the sling.include
> scenario will still be a problem:
>
> > So that a request from a browser to http://www.domain.com/path would
> > yield a different result than sling.include("/path").
>
> Or am I missing something here?
>

Yes and no ;-)

If you use SlingScriptHelper.include which takes a path, you would
somehow have to guard the ResourceResolver returned from the
SlingHttpServletRequest which is used to resolve the path to a resource.

In this respect, this would have to be considered, yes.

What could also be done to runt the "prerequest" filters with
incompletely setup SlingHttpServletRequest/Response objects. This would
mean the request.getResource() might return null in this stadium. This
would allow a filter to overwrite the
SlingHttpServletRequest.getResourceResolver() method to wrap the
ResourceResolver with some special functionality ...

Regards
Felix