Author: buildbot
Date: Tue Dec 29 00:20:44 2015
New Revision: 976599
Log:
Production update by buildbot for tapestry
Modified:
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/runtime-exceptions.html
Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/tapestry/content/runtime-exceptions.html
==============================================================================
--- websites/production/tapestry/content/runtime-exceptions.html (original)
+++ websites/production/tapestry/content/runtime-exceptions.html Tue Dec 29
00:20:44 2015
@@ -67,7 +67,7 @@
</div>
<div id="content">
- <div id="ConfluenceContent"><p>Feedback is vitally important
when developing an application, and that is one of the areas where Tapestry has
always excelled.</p><p>Especially during development, requests can fail. There
can be errors in templates, broken code in your application, or something
unexpected.</p><p>Tapestry has a built-in exception report page that captures
an amazing wealth of information:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image confluence-content-image-border" width="500"
src="runtime-exceptions.data/Exception_Stack_Trace.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image confluence-content-image-border" width="500"
src="runtime-exceptions.data/Exception_Request.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedde
d-image confluence-content-image-border" height="443" width="500"
src="runtime-exceptions.data/Application_Exception.png"></span></p><p>This
exception report features:</p><ul><li>The full stack of exceptions, top to
bottom.</li><li>All non-null properties of each exception.</li><li>The stack
trace <em>at the deepest
level</em>.</li><li>Key <strong>request</strong> properties, header,
attributes, and
parameters.</li><li>Key <strong>session</strong><em> </em>propertes</li><li>A
break down of the <em>thread</em> in your application</li><li>A listing
of all JVM System properties<br clear="none"><br clear="none"></li></ul><p>In
addition, Tapestry will write a text file for the exception with a similar
level of detail.</p><p>This exception report is also built-in to Tapestry's
Ajax support. When an Ajax request fails, Tapestry's client-side code will
create an <iframe> to present this same information:</p><p><span
class="confluence-embedded-file-wrapper conf
luence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" height="359" width="500"
src="runtime-exceptions.data/Exception_Ajax.png"></span></p><p>In production,
you may want to <a href="overriding-exception-reporting.html">override the
exception report page</a> (but will likely keep the text file output). However,
Tapestry's (from version 5.4) default exception reporter also allows you to
handle specific exception types in a pre-determined manner, similar to how
servlet spec's standard error-page/exception-type configuration option allows
you to map exception types to URLs. At times, it's simpler to just catch
exceptions at the outermost layer of your application instead of carrying a
typed exception through multiple layers of abstractions just so you could show
a sensible error message to the user, especially if you can't do anything more
clever about it anyway. Exception type mapping in Tapestry is much more
powerful than what the servlet
spec dictates. If your email service or an external payment service goes
down, you can't do much more than display an error message to the user, so why
would you need to implement separate pages for each exception? Often, it'd be
nicer if you could just reuse the page template for any fatal exception and
simply display a different error message. In addition to contributing handlers
for specific types of exceptions, you may also provide context for rendering
the same error page template with a different output.</p><p>You can contribute
an error page, mapping it to an exception type:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+ <div id="ConfluenceContent"><p>Feedback is vitally important
when developing an application, and that is one of the areas where Tapestry has
always excelled.</p><p>Especially during development, requests can fail. There
can be errors in templates, broken code in your application, or something
unexpected.</p><p>Tapestry has a built-in exception report page that captures
an amazing wealth of information:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image confluence-content-image-border" width="500"
src="runtime-exceptions.data/Exception_Stack_Trace.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image confluence-content-image-border" width="500"
src="runtime-exceptions.data/Exception_Request.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedde
d-image confluence-content-image-border" height="443" width="500"
src="runtime-exceptions.data/Application_Exception.png"></span></p><p>This
exception report features:</p><ul><li>The full stack of exceptions, top to
bottom.</li><li>All non-null properties of each exception.</li><li>The stack
trace <em>at the deepest
level</em>.</li><li>Key <strong>request</strong> properties, header,
attributes, and
parameters.</li><li>Key <strong>session</strong><em> </em>propertes</li><li>A
break down of the <em>thread</em> in your application</li><li>A listing
of all JVM System properties<br clear="none"><br clear="none"></li></ul><p>In
addition, Tapestry will write a text file for the exception with a similar
level of detail. The default location for the exception files is a relative
directory <em>build/exceptions</em>. You can configure the location by setting
<a class="external-link"
href="http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/SymbolConstants
.html#EXCEPTION_REPORTS_DIR">SymbolConstants.EXCEPTION_REPORTS_DIR</a>.</p><p>This
exception report is also built-in to Tapestry's Ajax support. When an Ajax
request fails, Tapestry's client-side code will create an <iframe> to
present this same information:</p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img
class="confluence-embedded-image confluence-content-image-border" height="359"
width="500" src="runtime-exceptions.data/Exception_Ajax.png"></span></p><p>In
production, you may want to <a
href="overriding-exception-reporting.html">override the exception report
page</a> (but will likely keep the text file output). However, Tapestry's (from
version 5.4) default exception reporter also allows you to handle specific
exception types in a pre-determined manner, similar to how servlet spec's
standard error-page/exception-type configuration option allows you to map
exception types to URLs. At times, it's simpler to just catch exceptions at t
he outermost layer of your application instead of carrying a typed exception
through multiple layers of abstractions just so you could show a sensible error
message to the user, especially if you can't do anything more clever about it
anyway. Exception type mapping in Tapestry is much more powerful than what the
servlet spec dictates. If your email service or an external payment service
goes down, you can't do much more than display an error message to the user, so
why would you need to implement separate pages for each exception? Often, it'd
be nicer if you could just reuse the page template for any fatal exception and
simply display a different error message. In addition to contributing handlers
for specific types of exceptions, you may also provide context for rendering
the same error page template with a different output.</p><p>You can contribute
an error page, mapping it to an exception type:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent pane
lContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> public void
contributeExceptionHandler(MappedConfiguration<Class, Class>
configuration) {
configuration.add(SmtpNotRespondingException.class,
ServiceFailure.class);
}</pre>
