Improve error reporting for template rendering in ScriptTemplateView [SPR-13488]

[spring-projects-issues]

chanwook park opened SPR-13488 and commented

ScripTemplateView is rendering in Nashorn ScriptEngine.
This rendering phase is difficult point for debugging (because in JDK Nashorn class...).
Server-side rendering (by Nashorn) is originally weak debugging than client-side rendering. (by browser)

So I hope to some additionally feature and support to debugging.

For example, compiled HTML often helpful debugging way than static template HTML, when developing mobile screen, or debugging for unusual condition(ex. Device fragmentation problem), logged compiled HTML is used to inspection in native browser (Chrome, etc.)

Below comment by Sébastien, I hope to more detailed way.

Indeed logging and debugging are not that great with Nashorn. That said, debugging is still possible using a browser.
For logging, there is perhaps a room for improvement on Spring MVC side, since we currently return the Javascript error message, but in the whole Nashorn stacktrace. Maybe just returning the Javascript error message should be enough depending of the log level...

thanks.

• Discuss item : https://groups.google.com/d/msg/spring-framework-contrib/gsYheHuy9SM/GG2fcZI9DQAJ

---

Affects: 4.2.1

Issue Links:

• Improve error reporting in StandardScriptEvaluator [SPR-13557] #18133 Improve error reporting in StandardScriptEvaluator

Referenced from: commits 1580288

[spring-projects-issues]

Sébastien Deleuze commented

For Spring Framework 4.2.x, I think we can potentially improve 2 points:

1. Print the script error message on the error page
2. Avoid to print the meaningless java stacktrace in the logs, the script error message is enough

[spring-projects-issues]

Sébastien Deleuze commented

Fixed by this commit.

The ScriptRenderException thrown in ScriptTemplateView#renderMergedOutputModel() is wrapped into a ServletException in order to avoid printing 2 times the messages in the logs (throwing directly a ScriptRenderException would make it wrapped in a NestedServletException that contains a getMessage() override not needed in this context).