On Aug 26, 2010, at 5:06 PM, Justin Deoliveira wrote: > Hi all, > > I wanted to bring a topic up for some discussion. Currently i am working on > the monitoring community module that uses a top level servlet filter to > control the monitoring process. Historically servlet filters have only been > made active by modifying web.xml of the geoserver instance being deployed. > Unfortunately in this case that does not really work since the monitoring > module is an unstable community module. And even when it becomes an extension > making the user manually edit the web.xml to enable it does not seem very > nice. > > So to remedy this I came up with servlet filter implementation that looks up > other servlet filters in a spring context and delegates to them accordingly. > With this it is possible to plug in servlet filters via the spring context. > For those interested I have attached the class to this jira: > > http://jira.codehaus.org/browse/GEOS-4114 > > So the question is a) is this a good idea? yes :)
> and b) if so should this be constrained to trunk only? don't see why. One (minor) consideration would be that we might better define a separate interface from javax.servlet.Filter. I like the class attached to the issue and agree these spring managed filters don't need the init(ServletContext) method to be called. Being spring beans all the context they might possibly need is the app context and there's a spring way of getting at it, so no need for init(ApplicationContext) neither. A cheaper alternative would be the extension point be an abstract class instead that extends Filter and has it's init(FilterContext) final (though that reminds me of xml's extension by restriction :P ) Another difference with normal servlet filters is that there's no way to declare chain order, so we need to make really explicit that filters implemented this way shall only be used when execution order doesn't matter, and that they'll be applied after all the ones declared in web.xml? 2c.- Gabriel > > Any feedback appreciated. Thanks. > > -Justin > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel Gabriel Roldan [email protected] Expert service straight from the developers ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
