API / Apache Grails Interview questions
What is the difference between an interceptor and a filter in Grails?
Both let code run before and after controller actions across many requests, but they represent two generations of the same idea — interceptors are the current, recommended mechanism, while filters are the older approach they largely replaced.
| Interceptor | Filter (legacy) |
| Defined as a Groovy class implementing a clear interface/convention | Defined via a DSL-heavy Filters artifact |
| Matches controllers/actions/URIs with a simple, explicit matcher API | Matches using nested closures and naming conventions, often less readable |
| Current recommended approach in modern Grails | Considered legacy; interceptors are the direct successor |
| Easier to unit test in isolation | Historically harder to test cleanly |
For anything new, Grails documentation and community practice both point toward interceptors; filters still work in applications that haven't migrated, but new code (authentication checks, logging, request timing) should be written as interceptors rather than continuing the older filters pattern.
Which mechanism is the current recommended approach for running code before/after controller actions in modern Grails?
What is one practical advantage interceptors have over the older filters approach?
More Related questions...
