[BLOSSOM-41] Handler exceptions are not logged and Paragraph-rendering can fail silently - should log which Page/Paragraph that fails Created: 28/Feb/11  Updated: 25/Jul/16  Resolved: 13/Nov/15

Status: Closed
Project: Blossom
Component/s: None
Affects Version/s: 1.2.1
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Kimmo Björnsson Assignee: Tobias Mattsson
Resolution: Obsolete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File BlossomHandlerExceptionResolver.java     Text File BlossomHandlerExceptionResolver.java     Text File BlossomHandlerExceptionResolver.java     Text File BlossomHandlerExceptionResolverTest.java    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

If you don't specify an ExceptionResolver that logs Exceptions from Controllers for example MissingServletRequestParameterException they fail silently.

If Blossom overrided protected processHandlerException in DispatcherServlet and log which Page/Paragraph that fails that would improve bug-searching a lot in both cases (when the exception gets logged and when it doesn't).

Or a BlossomHandlerExceptionResolver could be implemented that logs more magnolia-specific info.

I attached my BlossomHandlerExceptionResolver i created to log JCR-path to help me find my bugs.



 Comments   
Comment by Magnolia International [ 22/Mar/11 ]

Interesting - sounds a bit like MAGNOLIA-3595 too. Tobias, wdyt ?

Comment by Kimmo Björnsson [ 24/Mar/11 ]

Attaching an updated version of the Resolver we use.

I think a Resolver is probably better than overriding in DispatcherServlet after all. I it is very useful in production as well when something goes wrong.

Comment by Tobias Mattsson [ 12/Nov/13 ]

While I like the idea I'm not convinced returning an empty ModelAndView is the right choice for most users. Since the goal here is to enrich the logging another approach would be to extend from DefaultHandlerExceptionResolver and customise the logging it generates. Attaching an example of this.

The test case uses PowerMock to mock static method calls, include it using:

    <dependency>
      <groupId>org.powermock</groupId>
      <artifactId>powermock-module-junit4</artifactId>
      <version>1.4.9</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.powermock</groupId>
      <artifactId>powermock-api-mockito</artifactId>
      <version>1.4.9</version>
      <scope>test</scope>
    </dependency>
Comment by Tobias Mattsson [ 13/Nov/15 ]

The error reporting in the default handling has improved greatly since this ticket was filed. It now includes more details about what was being rendered when the exception was thrown. It should be sufficient for the majority of users. Should it not be enough it is possible to customize the error handling both in Magnolia, and in Spring Web MVC.

Generated at Sun Feb 11 23:29:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.