Hi,
another discussion topic for the fry: plugabble web filters.
These things have been an annoyance for quite some time to me
for a very simple reason: they have to be declared in the
web.xml explicitly, thus they are not pluggable and require
some uglier than necessary code to participate in the
Spring context.
I would really like to have those filters be pluggable things
instead, as in declared in the Spring context.
Imho it would make for a number of advantages:
- all the code related to a certain functionality is put
in the same module. For example now we have the security
stuff mixed between main and web-app
- the filters declared this way would be pluggable, no need
to hack the web-app module if you need to add custom
filtering, just drop your jar and be happy
- the filters could get all the dependencies via dependency
injection once
- the filters could be moved into some core module and
wire there, or just declared in web-app but without having
the classes there, so that making an alternate web-app
module becomes a matter of copying the pom and setting
the dependencies (think of a headless web setup with only
restconfig, or a custom pure wfs module, or stuff like that).
Looking in Spring I've found this "DelegatingFilterProxy"
class that allows to register just one bean filter and delegate
it to a bean that implements Filter and it's registered in the app
context.
What I would like to do is to do soemthing along those lines,
a similar class that is registered as the one and only
filter in web.xml, and that:
- scans the Spring context to lookup for pluggable filters
- sort them according to the priority declared via implementation
of the ExtensionPriority interface
- applies them in order. Each filter is responsible to decide
whether to do something on a certain path, or not
(or if you prefer we can keep the path in which the filter
is to be applied)
Thoughts?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
A big +1 here. Now if only we could do the same trick with servlet mapping paths we would be golden 
Andrea Aime wrote:
Hi,
another discussion topic for the fry: plugabble web filters.
These things have been an annoyance for quite some time to me
for a very simple reason: they have to be declared in the
web.xml explicitly, thus they are not pluggable and require
some uglier than necessary code to participate in the
Spring context.
I would really like to have those filters be pluggable things
instead, as in declared in the Spring context.
Imho it would make for a number of advantages:
- all the code related to a certain functionality is put
in the same module. For example now we have the security
stuff mixed between main and web-app
- the filters declared this way would be pluggable, no need
to hack the web-app module if you need to add custom
filtering, just drop your jar and be happy
- the filters could get all the dependencies via dependency
injection once
- the filters could be moved into some core module and
wire there, or just declared in web-app but without having
the classes there, so that making an alternate web-app
module becomes a matter of copying the pom and setting
the dependencies (think of a headless web setup with only
restconfig, or a custom pure wfs module, or stuff like that).
Looking in Spring I've found this "DelegatingFilterProxy"
class that allows to register just one bean filter and delegate
it to a bean that implements Filter and it's registered in the app
context.
What I would like to do is to do soemthing along those lines,
a similar class that is registered as the one and only
filter in web.xml, and that:
- scans the Spring context to lookup for pluggable filters
- sort them according to the priority declared via implementation
of the ExtensionPriority interface
- applies them in order. Each filter is responsible to decide
whether to do something on a certain path, or not
(or if you prefer we can keep the path in which the filter
is to be applied)
Thoughts?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
big +1 here too.
Andrea, could you briefly explain to the list why DelegatingFilterProxy is not up to the task and hence the need for a home made solution?
cheers,
Gabriel
Justin Deoliveira wrote:
A big +1 here. Now if only we could do the same trick with servlet mapping paths we would be golden
Andrea Aime wrote:
Hi,
another discussion topic for the fry: plugabble web filters.
These things have been an annoyance for quite some time to me
for a very simple reason: they have to be declared in the
web.xml explicitly, thus they are not pluggable and require
some uglier than necessary code to participate in the
Spring context.
I would really like to have those filters be pluggable things
instead, as in declared in the Spring context.
Imho it would make for a number of advantages:
- all the code related to a certain functionality is put
in the same module. For example now we have the security
stuff mixed between main and web-app
- the filters declared this way would be pluggable, no need
to hack the web-app module if you need to add custom
filtering, just drop your jar and be happy
- the filters could get all the dependencies via dependency
injection once
- the filters could be moved into some core module and
wire there, or just declared in web-app but without having
the classes there, so that making an alternate web-app
module becomes a matter of copying the pom and setting
the dependencies (think of a headless web setup with only
restconfig, or a custom pure wfs module, or stuff like that).
Looking in Spring I've found this "DelegatingFilterProxy"
class that allows to register just one bean filter and delegate
it to a bean that implements Filter and it's registered in the app
context.
What I would like to do is to do soemthing along those lines,
a similar class that is registered as the one and only
filter in web.xml, and that:
- scans the Spring context to lookup for pluggable filters
- sort them according to the priority declared via implementation
of the ExtensionPriority interface
- applies them in order. Each filter is responsible to decide
whether to do something on a certain path, or not
(or if you prefer we can keep the path in which the filter
is to be applied)
Thoughts?
Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Gabriel Roldan ha scritto:
big +1 here too.
Andrea, could you briefly explain to the list why DelegatingFilterProxy is not up to the task and hence the need for a home made solution?
Sure: the thing takes just one delegate, by name, whilst
we need to delegate to a list, sort it to get proper ordering, and the
list is unknown until startup
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Gabriel Roldan ha scritto:
big +1 here too.
Andrea, could you briefly explain to the list why DelegatingFilterProxy is not up to the task and hence the need for a home made solution?
Sure: the thing takes just one delegate, by name, whilst
we need to delegate to a list, sort it to get proper ordering, and the
list is unknown until startup
thanks
Gabriel
Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.