[MAGNOLIA-3595] Add an exception handler for filters. Created: 11/Mar/11 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core, templating |
| Affects Version/s: | 4.3.8, 4.4.2 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Danilo Ghirardelli | Assignee: | Ondrej Chytil |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | exception, filter, handler | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||
| Description |
|
There are a few points in the Magnolia filter chain in which it would be really useful to be able to configure an exception handler, that can decide which exception should be rethrown, which can be "resolved" there and which can be just logged or simply ignored (if any). I don't know if this is included in the refactoring that you are doing for magnolia 5 or not. |
| Comments |
| Comment by Magnolia International [ 22/Mar/11 ] |
|
Do you have other use-cases than
The former seems more generic, but also more configuration intensive. The latter might be a little more complex (in the sense that you'd need to know exactly what to override and where), but simpler from a configuration and implementation point of view (the specific exception handling method could have different parameters, base on the use-case) I guess finding a good answer will depend on use-cases... thoughts ? |
| Comment by Danilo Ghirardelli [ 22/Mar/11 ] |
|
For example, I used spring security in my site: while rendering some templates/paragraphs, spring may check for user authentication and throws one of its exception if user is not logged. The exception thrown is then catched by spring filter (which is just another filter in the Magnolia chain), that stores the current request and redirects the user to the login page. This spring exception is then perfectly normal and happens quite often, but rendering filter logs it no matter what, filling logs with "normal" exception. I suppose there are other cases in which a filter can handle exceptions from other points of the chain. Anyway I think the first solution you proposed would be better, adding a default exception handler for all filters, because it I'm not mistaken, most of the filters just do nothing or catch, wrap and rethrow. The real problem for me is not the "handling" itself, because it's easy to add another filter that handles the exceptions the way I want, but the "bubbling" of the exception, to avoid unrequested logging and wrapping (or the suppression of the exception). |
| Comment by Jan Haderka [ 14/Jun/13 ] |
|
@Ondrej could you please add link to your concept for solving this issue? |
| Comment by Ondrej Chytil [ 14/Jun/13 ] |
|
http://wiki.magnolia-cms.com/display/DEV/Concept+Filter+exception+handler |
| Comment by Magnolia International [ 11/Aug/14 ] |
|
While looking at the recent CSRF fixes, I figured this could be almost already implemented via the SecurityCallbackFilter and HttpClientCallback. Granted, naming isn't great, and maybe we'd want an additional method, such as boolean accepts(Throwable t) on HttpClientCallback, but the logic is really the same ! |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |