Great feedback Gabriel. Thanks. Comments inline.
On Thu, Aug 26, 2010 at 4:16 PM, Gabriel Roldan <[email protected]> wrote:
>
> 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 )
>
Thought about that too and yeah it makes sense. Perhaps an interface called
FilterDelegate that drops the init() method.
>
> 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?
>
Good point, never thought about order. If a filter does need to care about
order the existing ExtensionPriority interface could be used to impose an
ordering. Although it would not be absolute of course but I think could
work.
>
> 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
>
>
--
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
