[MAGNOLIA-6692] Freemarker.runtime errors are not rendered in edit mode when info.magnolia.freemarker.ModeDependentTemplateExceptionHandler is not used Created: 13/Jun/16 Updated: 22/May/17 Resolved: 16/May/17 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Milan Divilek | Assignee: | Federico Grilli |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| 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)
|
||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||
| Sprint: | Basel 96 | ||||||||||||||||||||||||
| Story Points: | 1 | ||||||||||||||||||||||||
| Description |
|
info.magnolia.freemarker.ModeDependentTemplateExceptionHandler was deprecated and replaced by info.magnolia.rendering.engine.ModeDependentRenderExceptionHandler. info.magnolia.rendering.engine.RenderExceptionHandler is not triggered for freemarker.runtime errors, because freemarker.template.Template class doesn't throw the runtime exceptions, so we can't catch them in info.magnolia.rendering.renderer.FreemarkerRenderer#onRender method (same way as we are doing for freemarker.template.TemplateException and java.io.IOException) and rethrow the errors as info.magnolia.rendering.engine.RenderException. |
| Comments |
| Comment by Espen Jervidalo [ 14/Mar/17 ] |
|
It's not just the description of this ticket.. The ticket as such is questionable and the whole exception handling as such is confusing. A short trip down memory-lane: https://jira.magnolia-cms.com/browse/MAGNOLIA-4134 https://jira.magnolia-cms.com/browse/MAGNOLIA-6637 https://jira.magnolia-cms.com/browse/MAGNOLIA-6762 /server/rendering/freemarker/templateExceptionHandler@class the TemplateExceptionHandler which implements *freemarker.template.*TemplateExceptionHandler. /server/rendering/engine@class injects from rendering.xml:
<component>
<type>info.magnolia.rendering.engine.RenderExceptionHandler</type>
<implementation>info.magnolia.rendering.engine.ModeDependentRenderExceptionHandler</implementation>
</component>
<component>
<type>info.magnolia.rendering.context.RenderingContext</type>
<implementation>info.magnolia.rendering.context.AggregationStateBasedRenderingContext</implementation>
</component>
So far my feeling is that, before fixing anything else of this ping-pong-maniac I would verify and tackle |
| Comment by Ilgun Ilgun [ 15/Mar/17 ] |
|
Most likely I will put out the known facts but anyways that might be useful for the next assignee of the issue. Be aware that there are two similarly named ModeDependentExceptionHandlers and both of them are in use currently. info.magnolia.freemarker.setup.FreemarkerSupportModuleVersionHandler is bootstrapping the old one (info.magnolia.freemarker.ModeDependentTemplateExceptionHandler) which is actually handling the Freemarker exceptions correctly. On the other hand, the new one (info.magnolia.rendering.engine.ModeDependentRenderExceptionHandler) is not able to handle those errors since it doesn't implement the interface of (freemarker.template.TemplateExceptionHandler). I see the point of ModeDependentRenderExceptionHandler which I believe was to generify the Exception handling mechanism in Renderers but we should handle the Freemarker case as well in there. Those two methods from the info.magnolia.freemarker.ModeDependentTemplateExceptionHandler explains why it works for debug but not for public case.
protected void inPublicMode(TemplateException te, Environment env, Writer out) throws TemplateException {
TemplateExceptionHandler.IGNORE_HANDLER.handleTemplateException(te, env, out);
}
protected void inEditMode(TemplateException te, Environment env, Writer out) throws TemplateException {
TemplateExceptionHandler.HTML_DEBUG_HANDLER.handleTemplateException(te, env, out);
}
Basically we ignore everything inPublicMode but inEditMode this handler does its job and rethrows those exception and therefore the new one is able to catch those exception and do something with them. There we go with the second solution, although I haven't tried it I am quite sure it will work. Possible solutions:
|