[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:
relation
is related to MAGNOLIA-3566 Cache filter should ignore ClientAbor... Closed
is related to MGNLCACHE-48 Cache filter should rethrow exception... Closed
is related to MAGNOLIA-3552 RenderException is thrown without info Closed
is related to MAGNOLIA-3696 Relax warning when checking for exist... Closed
is related to MAGNOLIA-5113 Generalize/centralize treatment of br... Closed
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).
First points that come to my mind are the rendering filter (expecially when using "strange" renderers, like spring, stripes or others), the cache filter (see MAGNOLIA-3566) and maybe the servlet filter (expecially when using "strange" servlets).
It would also be nice if the exception handling class could be injected by filter configuration.

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 MAGNOLIA-3566 in mind ? What do you think would be simpler/better,

  • having an exception handler, to be configured per filter, implementing with a method like handleException(e) (probably passing a couple more parameters with it, request and response for instance)
  • extract specific exception handling methods in specific filter, at specific key points - letting you overriding these methods.

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).
Maybe another solution would be to just wrap any exception for any filter (except maybe the few that can be resolved in the filter or similar) in a "MagnoliaBubblingException" that just passes the chain until a "DeafultExceptionHandlerFilter", a new filter that should be added near the beginning of the chain.

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
And git branch with implemented proof of concept.

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.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:47:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.