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. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
